Re: [PATCH] [PVOPS] dom0 sync xen wallclock

[Jeremy Fitzhardinge <jeremy@goop.org>]

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