Comment 13 for bug 1349883

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.