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

Ian.


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