Bug#534978: clock drift in Xen domU with clocksource=xen
severity 534978 normal
thanks
I've made some more progress in understanding this behaviour, and have now
figured out a workaround. I find the documentation at
http://wiki.debian.org/Xen very misleading in several respects.
The domU kernel is receiving time info from the hypervisor as it should. My
earlier suspicion that the vcpu_info wasn't being updated turned out to be
both unfounded (I had missed the significance of "vcpu_info placement") and
irrelevant (even without the vcpu_info updates the time as computed by
pvclock_read_wallclock() drifts several orders of magnitude more slowly
than observed).
Linux' generic time code (in kernel/time/timekeeping.c), however, doesn't
use the value from pvclock_read_wallclock() directly; instead, it uses the
clocksource (xen_clocksource in this case) to compute an increment to the
xtime kernel variable. For some reason I haven't fully worked out, this
results in the drift I observed. I still suspect there is a bug here (the
accuracy of the time calculation ought to be better than this) so I'm
downgrading the severity to "normal" rather than "wishlist".
The good news is that the NTP support code can correct for this. My workaround
is therefore to run NTP in the domU. It is neither possible nor necessary to
set xen.independent_wallclock=1 (that parameter is only supported by the
featureset=xen kernels, which include the SuSE patch), and it is neither
necessary nor desirable to change the domU clocksource to jiffies (I tried
that and found that the time accuracy got much worse).
I had been led to expect (again, by the wiki page, but also by common sense)
that the domU was meant to get its clock from Xen and didn't need to run NTP.
This appears to only be the case when the domU kernel includes the SuSE patch,
not for the pv_ops-based approach.
I would very much appreciate being relieved of the need to run NTP in each and
every domU: that seems wasteful.
Reply to: