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

[Stefano Stabellini <stefano.stabellini@xxxxxxxxxxxxx>]

On Wed, 1 May 2013, 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).

there is another problem there: the "factor" is not available or
configurable on ARM, so it can cause problems on VM migration.


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

I am thinking that we might have to enable the PV timer on ARM after
all.

_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxx
http://lists.xen.org/xen-devel