Re: What time is it kvm-clock?

[Marcelo Tosatti <mtosatti@redhat.com>]

On Tue, Feb 23, 2016 at 06:31:59PM -0800, Owen Hofmann wrote:
> 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. 

Design goals of what interface? KVM_GET_CLOCK / KVM_SET_CLOCK? 

The interfaces have been introduced to fix a bug.

> The (later) thread in (3) claims that synchronizing with
> host time is *not* a goal of kvm-clock.

It is not.

> 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.

Documentation/virtual/kvm/timekeeping.txt