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 Wed, 2013-05-01 at 11:28 +0100, Stefano Stabellini wrote:
> > 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.
> 
> Yes, that was what I was getting at with the common case for avoiding
> being migration among like systems, IOW if you migrate to a system with
> a different factor (which really == clock frequency, I think) then you
> need to emulate :-(
> 
> > > 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.
> 
> It wouldn't be the *end* of the world and by making use of the
> availability of both physical and virtual time we may be able to come up
> with something even better? On x86 we share the pvclock algorithmn with
> KVM -- this would be something interesting to discuss with them on ARM
> too I think.
> 
> Or I suppose we have some PV mechanism to reset the kernels idea of the
> clock frequency?

I think it is possible: if we exposed the "factor" to the guest and
accounted for the stolen ticks in the vtimer offset, the guest would
have everything it needs to calculate the time.

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