On Thu, 2010-02-11 at 11:24 +0000, 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.
> 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 agree, guests which have a dependent wallclock are reading this
variable from the hypervisor as their xtime, not their CMOS RTC. Having
domain 0 write it as if it were the CMOS seems asymmetric with this
approach.
Any explicit setting of the time in domain 0 should be immediately
propagated through to the hypervisor, with all the usual caveats that
calling settimeofday has on any normal Linux system, but it appears it
is necessary for the same reasons we usually allow ntpd (or ntpdate) to
step the time once at start of day. Without this we have to wait some
time after boot for the time setting to be propagated, this delay is
often long enough to have started several VMs which will now be running
with the wrong time and/or see even worse discontinuities when the time
is eventually set.
As for propagating variations derived from the ntp drift calculations a
drift based interface to the hypervisor would be an improvement but I
think what Stefano proposes is basically inline with historical domain 0
behaviour. Guests which have a dependent wallclock already handle any
discontinuities by adding their own monotonicity checks.
One tricky issue with pushing drift parameters into the hypervisor is
that presumably ntp would need to calculate them based on the
hypervisor's idea of time, calculating based on domain 0's idea of time
when the two are allowed to drift seems like it would simply lead to
using the wrong drift paramters and making things worse for the
hypervisor.
Ian.
_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel
|
Home