[Xen-devel] Re: [PATCH] [PVOPS] dom0 sync xen wallclock

[Stefano Stabellini <stefano.stabellini@xxxxxxxxxxxxx>]

On Wed, 10 Feb 2010, Jeremy Fitzhardinge wrote:
> I'm not sure this is the right thing to do.  We have a set_wallclock 
> pvop, which Xen currently implements as a no-op, but it should do the 
> appropriate hypercall to set Xen's time if privileged enough.
> 
> Conceptually the Xen persistent time is the same as the platform CMOS 
> clock, so I don't think we should update it any differently.  Your patch 
> may make sense, but it should also address the native case.   At the 
> moment it happens via sync_cmos_clock(), which is called periodically (I 
> think) independently of whether the clock has actually been changed.
> 
> There is one big difference between the Xen clock and the CMOS clock, 
> which is that the Xen clock is being concurrently accessed by other 
> domains.  If it is being updated periodically, then there will be 
> discontinuities in time which may affect other domains.  But since 
> there's no time-warp ABI to Xen, I don't think this can really be 
> avoided; anyone reading periodically the Xen clock needs to be able to 
> deal with any discontinuities.  pvops kernels only inspect it at boot 
> time, and so won't see any subsequent time adjustments anyway.
> 

Linux 2.6.18 does consider xen persistent time as the platform
CMOS clock, but I don't think this is what we actually want: if we run
ntpd in dom0 we probably want to sync xen time with dom0 time more often
than linux usually update the CMOS clock.
In particular we want that as soon as ntpd in dom0 set the right time,
it gets propagated in xen so that all the PV guests created after that
moment can read the right wallclock at boot.
I think that the right approach to achieve that is to break the
assumption that xen persistent time is like the CMOS and treat it more
like xtime instead.


_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel