Specifically, what underlying source of time should be exposed through kvm-clock and other paravirtual ABIs like the HyperV reference tsc page? Recently a couple of threads on kvm-list, along with attempts to produce reliable behavior from kvm-clock on our systems have highlighted a tension between the current implementation of kvm-clock and potentially diverging goals for paravirt time. Here are a few: 1) kvmclock doesn't work, help?: http://www.spinics.net/lists/kvm/msg125039.html 2) kvmclock: improve accuracy: http://www.spinics.net/lists/kvm/msg127215.html 3) KVM-clock: http://www.spinics.net/lists/kvm/msg127774.html This question is mostly in regards to kvm-clock in masterclock mode (with PVCLOCK_TSC_STABLE set). In this mode, is kvm-clock intended to expose a source of time that is more 'true' than the underlying TSC? For example, by passing through NTP correction from the host. For the current implementation, the answer seems to be... why not both? Once programmed, kvm-clock or the HyperV TSC page will advance with the TSC multiplied by the frequency specified by kvm. On the other hand, KVM_GET_CLOCK, KVM_SET_CLOCK, and the Windows reference counter MSR are measured against corrected time from the host. A guest reading its pvclock gets a very different result from a host KVM_GET_CLOCK if the guest has run long enough to for TSC to diverge from NTP time. A VMM using these ioctls to save and restore clock state can produce wild time jumps from the guest's perspective. The patches in (2) address this mismatch by plumbing updates to clock frequency through kvm-clock to the guest. This seems like an important design choice for kvm-clock, and IMO deserves at least a clear statement of the goals for this interface, if not some more discussion. The (later) thread in (3) claims that synchronizing with host time is *not* a goal of kvm-clock. To me, kvm-clock and the HyperV TSC page are extremely effective as simply a more enlightened path to the host TSC. Maintaining a high-performance path to the TSC in the face of updates is tricky - see the extended comment in pvclock_update_vm_gtod_copy, or the discussion on the patchset in (2). Is the cost of auditing that the path from host gettimeofday update -> kvm -> guest pvclock -> guest gettimeofday both tracks host time correctly and does not produce any backwards warps worth the added value, if it exists? As an alternative, implementing KVM_GET_CLOCK or the reference time MSR as a function of the last update to kvm-clock or the reference TSC page, respectively, sounds very straightforward. (Outside of masterclock mode, the requirement that the client synchronizes across cpus for montonicity smoothes over a lot of complexity - periodically updating kvm-clock to the current time is simple and works.) Regardless of my opinion, I think that a clear statement of the design goals for kvm-clock (and kvm's implementation of the reference TSC page) would be valuable. -- To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
