Re: [PATCH v4 12/12] xen/arm: initialize virt_timer and phys_timer with the same values on all vcpus

[Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>]

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
>