|
|
|
|
|
|
|
|
|
|
xen-devel
[Xen-devel] Re: [PATCH] [PVOPS] dom0 sync xen wallclock
On Fri, 2010-02-19 at 23:05 +0000, Jeremy Fitzhardinge wrote:
>
> > Unfortunately there is an existing large installed base of guests
> which
> > use the dependent wallclock mode since it is the default in oldstyle
> Xen
> > kernels.
> >
>
> Sure. I'm not suggesting that we remove the existing hypercall. I
> just don't think we should extend it or encourage its use.
We currently have a large installed base of guests which use dependent
wallclock and therefore expect the Xen wallclock to be correct when they
start and to be remain roughly in sync thereafter (and these guests cope
with the sawtoothing this implies).
I think the first half of that behaviour (correct when they start) is
most crucial here. As it stands the Xen wallclock time doesn't get
updated for several minutes after boot because ntpdate doesn't cause a
sync to the hypervisor nor hardware RTC and ntpd takes ages to decide it
has syncd which means that any PV guests which start in that interval
and use dependent wallclock (which is currently most) will see a large
time discontinuity whenever ntpd in domain 0 is happy enough to actually
sync the RTC (which as a side-effect pushes a new time into Xen) not to
mention they will be running with some bogus time for that entire
interval. Hooking clock_was_set fixes this issue
If we choose not to include the timer aspect which keeps the hypervisor
wallclock roughly in sync we need to communicate this change to. They
now need to run ntpd in their guest where previously we advised the
opposite (for example in
http://wiki.xensource.com/xenwiki/InstallationNotes but this also
impacts distro documentation and google-fu).
Ian.
_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel
|
<Prev in Thread] |
Current Thread |
[Next in Thread> |
- Re: [Xen-devel] Re: [PATCH] [PVOPS] dom0 sync xen wallclock, (continued)
|
|
|
|
|