Bug#534978: clock drift in Xen domU with clocksource=xen
I think I've made some progress towards figuring out what's going on here.
First I looked at the Xen mini-os kernel, which keeps time correctly.
I added a few printk()s to getttimeofday() and saw that of the values
in the HYPERVISOR_shared_info structure, the vcpu_info data change often
(never more than a handful of seconds between version increments) while
the wallclock timestamp is updated more rarely.
Then I hacked together a Linux kernel module that adds support for
/proc/xeninfo, exposing (if I did it right) the contents of the
shared_info structure. What I'm seeing is the same occasional updating
of the wallclock timestamp (the values are consistent with what I see
in the mini-os domU) but the vcpu_info (for virtual CPU 0; data for the
other VCPUs are all zeros throughout, as I believe is normal for a
single-processor VM) remains stuck at version 2.
A caveat here is that while I'm confident (based on the data; the shift
value is also right, the multiplier is in the right ballpark) that I've
found a shared_info structure I'm not sure I got the right one. The kernel
doesn't seem to export all the symbols needed to find its
HYPERVISOR_shared_info structure, and it needs to be mapped into memory
in a special way; it's conceivable that I did something wrong here, even
though I tried to reuse/imitate existing kernel code as much as I could.
Anyway, the secular clock drift this bug is about seems consistent with a
failure to receive updates to the vcpu_info data. Is the hypervisor somehow
discriminating against Linux domU's by not updating the data, or does the
domU kernel need to do something more in order to see the updates?
The problem is also reproducible with the 2.6.30-bpo.1 kernel (source code
from backports.org, recompiled locally), by the way.
Reply to: