Tag Archives: pvclock

KVM pvclock

A short article on how KVM’s paravirtualized clock source works (mostly adapted from Glauber’s notes here).

kvmclock or KVM pvclock lets guests read the host’s wall clock time. It’s really very simple: the guest sets aside a page of its RAM and asks the host to write time into that page (using an MSR). The host writes a structure containing the current time to this page — in theory the host updates this page constantly, but in reality that would be wasteful and the structure is only updated just before reentering the guest after some VM event.

The structure that is written contains the time at the moment it was written, plus the guest’s TSC at that moment, plus the current scale of TSC to real time (which can change). The guest can read its own TSC a little bit later, work out the difference between TSC now and TSC when the host measured it, scale that to seconds, and add that to the time in the struct to get an estimate of wall clock time. As long as the host doesn’t allow too much time to pass between updates, and doesn’t do something like scale the CPU speed or migrate the guest without updating the struct, the guest can get an estimate for wall clock time without involving the hypervisor at all.

struct pvclock_vcpu_time_info {
        u32   version;
        u32   pad0;
        u64   tsc_timestamp;
        u64   system_time;
        u32   tsc_to_system_mul;
        s8    tsc_shift;
        u8    flags;
        u8    pad[2];
} __attribute__((__packed__));

Finally, how do you find out if your Linux guests are using KVM pvclock? Ask the kernel like this:

$ cat /sys/devices/system/clocksource/clocksource0/current_clocksource


Filed under Uncategorized

Half-baked ideas: Accelerated testing for VMs

For more half-baked ideas, see my ideas tag

When manufacturers build consumer hardware it is often subjected to so-called “accelerated aging” or “accelerated testing”. For example, the life of an aircraft is not measured in years, but in pressurization cycles. Aircraft are repeatedly pressurized in tanks, and shaken (“fatigue testing”) to find out when they will fail.

So here’s the idea: Apply accelerated testing to virtual machines. Modify pvclock so it runs 100 or 1000 times faster than normal. Daily and weekly cron jobs accelerated, and so are daemons, so we rapidly find if they slowly leak memory or disk space, or have some other time-related failure. How will the guest behave after it has been running for a year, or 10 years? How about applications? Now we can find out, and not need to wait that long.


Filed under Uncategorized