> I don't really see why wallclock time is any of Xen's business.
While I agree in principal, I ran across a case recently where
it could/would be very useful: Recent Linux kernels running
on very latest processors use the TSC as a clocksource. VMware
can and does support this, even across save/restore/migration.
Supporting it across migration requires the hypervisor to
have some equivalent of wallclock time that can be synchronized
across machines in a "migration pool". I *think* VMware
can use NTP to do this (because their hypervisor is closer
to a full OS than Xen is).
Without this, Xen cannot allow an OS to select the TSC as
a clocksource unless it disallows save/restore/migration.
(Thus the "no_migrate" flag recently added in Xen.) The
result is a small but not insignificant performance
advantage for VMware on some benchmarks, which may appear
in upcoming 2.6.32-based distros.
Of course, it may also be possible to get this from dom0
but for performance reasons some concept of wallclock "offset"
must reside in the hypervisor.
> -----Original Message-----
> From: Jeremy Fitzhardinge [mailto:jeremy@xxxxxxxx]
> Sent: Thursday, February 18, 2010 4:44 PM
> To: Stefano Stabellini
> Cc: Ian Campbell; xen-devel@xxxxxxxxxxxxxxxxxxx
> Subject: [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
_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel
|
Home