When inspecting the vcpu info on a local PV guest and a EC2 guest provided by
Joe, I found that:
time = {
version = 33456,
pad0 = 0,
tsc_timestamp = 86813831140545,
system_time = 37805107510066,
tsc_to_system_mul = 3743284562,
tsc_shift = -1 '\377',
flags = 0 '\000',
pad = "\000"
}
So system_time in both cases seems to be the uptime in nanoseconds of
the Xen host. My machine was up for about 10hrs. In the PV guest the
dmesg timestamps however are somehow corrected to be in agreement of the
guests uptime.
time = {
version = 19934,
pad0 = 0,
tsc_timestamp = 8365090813767560,
system_time = 4647273524058147,
tsc_to_system_mul = 2386093295,
tsc_shift = 0 '\000',
flags = 0 '\000',
pad = "\000"
}
The structure on the ec2 instance also seems to contain the uptime of
the Xen host (which is around 53 days). Though here, the timestamps in
dmesg and the value of system_time are the same. So the guest suddenly
got the uptime of the Xen host.
The only way this makes sense is that the delta (which is calculated
from (rdtsc - tsc_timestamp) with the shift and mul values should
normally be offset host to guest. Not sure how yet. Oh and one piece of
information from the irc conversation: apparently this may not happen on
first boot but on reboot, but once it happened it will always happen. So
far only observed with Intel CPUs.
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1349883
Title:
dmesg time wildly incorrect on paravirtual EC2 instances.
To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1349883/+subscriptions
--
ubuntu-bugs mailing list
ubuntu-bugs@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
