From mboxrd@z Thu Jan 1 00:00:00 1970 From: Konrad Rzeszutek Wilk Subject: Re: [PATCH v4 12/12] xen/arm: initialize virt_timer and phys_timer with the same values on all vcpus Date: Wed, 1 May 2013 09:28:38 -0400 Message-ID: <20130501132838.GA18884@phenom.dumpdata.com> References: <1366990117-8689-12-git-send-email-stefano.stabellini@eu.citrix.com> <1367245070.3142.297.camel@zakaz.uk.xensource.com> <1367311099.3142.413.camel@zakaz.uk.xensource.com> <1367402028.3142.665.camel@zakaz.uk.xensource.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Return-path: Content-Disposition: inline In-Reply-To: <1367402028.3142.665.camel@zakaz.uk.xensource.com> List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org To: Ian Campbell Cc: Julien Grall , "xen-devel@lists.xensource.com" , "Tim (Xen.org)" , Stefano Stabellini List-Id: xen-devel@lists.xenproject.org On Wed, May 01, 2013 at 10:53:48AM +0100, Ian Campbell wrote: > On Tue, 2013-04-30 at 17:37 +0100, Stefano Stabellini wrote: > > > But then > > > it ticks along at the same rate as phys time with no accounting for > > > stolen or lost time etc? TBH I'm not even sure what stolen/lost time > > > would be like for a clock which is supposed to be consistent across all > > > VCPUs, or maybe that restriction is only for physical and hypervisor > > > timers. > > > > Right, no accounting. I don't know how the lost time accounting would > > look like either. > > I've added this to the ARM_TODO wiki. > > I wonder if the right answer, by analogy with PV time on x86, will be > something like: > > Reading the ARM Physical timer == Raw read of x86 TSC, i.e. you get a > raw host system time. > > Reading the ARM virtual timer == The x86 PV clock protocol (e.g. the > tsc*factor+offset), i.e. you get a time source which does not include > stolen time and which ticks only when the guest is running (I think this > is the x86 semantics, not 100% sure though). > > We also need to figure out whether we expect virtual time to remain in > step across the domain -- if yes (this is what the physical timers do > for example) then we need to understand what this means when VCPU0 runs > but VCPU1 doesn't. I don't know what x86 does here... It uses the VCPU_vcpuruntime to figure out whether it was "offline" and add that to the 'stolen' or what not delta. The arch/x86/xen/time.c has do_stolen_accounting which does some of this. > > Ideally we would have a scheme which didn't require us to emulate either > virtual or physical time in the common case (e.g. migration among like > systems). > > Ian. > > > _______________________________________________ > Xen-devel mailing list > Xen-devel@lists.xen.org > http://lists.xen.org/xen-devel >