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

[Ian Campbell <Ian.Campbell@xxxxxxxxxx>]

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...

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@xxxxxxxxxxxxx
http://lists.xen.org/xen-devel