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. -- To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
