[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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



On 02/11/2010 03:24 AM, Stefano Stabellini wrote:
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.

If you're making the assumption that a guest will query the Xen wallclock time precisely once, then I guess that will work OK. But if you expect them to query it more than once, then you need to add a notion of drift correction to Xen's system clock so that you can warp it in a continuous fashion. But that complicates things because dom0 itself is using the Xen system clock as its own timebase which it is also applying drift correction to. So to make that work you either need to introduce distinct notions of corrected and uncorrected Xen clocks and make domains query them appropriately, or more deeply PV time in the domains so they directly use/adjust the Xen drift factor rather than maintaining their own.


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.

I don't really see why wallclock time is any of Xen's business. It seems like something that could be completely dropped with no loss of functionality. It's somewhat useful for domains to be able to fetch an approximately correct wallclock time early in boot, but aside from that its fairly useless.

I would prefer to see:

   * dom0 gets time of day from CMOS or whatever hardware mechanism it
     wants
   * PV domUs get a rough time of day at boot either from a simple
     "seconds since 1970" in the startup info put there by the domain
     builder from dom0's clock (so there's no illusion that it is
     anything other than a one-time start time for the domain)
   * HVM domains similarly get an emulated CMOS implemented in qemu
   * anyone who wants continuously tracked accurate time needs to run ntp

and deprecate any notion of wallclock time from Xen.

    J


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


 


Rackspace

Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.