Re: [PATCH v6 05/36] KVM: x86: Add KVM_[GS]ET_CLOCK_GUEST for accurate KVM clock migration

[David Woodhouse <dwmw2@infradead.org>]

[-- Attachment #1: Type: text/plain, Size: 4283 bytes --]

On Fri, 2026-07-24 at 14:17 -0700, Sean Christopherson wrote:
> On Fri, Jul 03, 2026, David Woodhouse wrote:
> > From: Jack Allister <jalliste@amazon.com>
> > 
> > In the common case (where kvm->arch.use_master_clock is true), the KVM
> > clock is defined as a simple arithmetic function of the guest TSC, based
> > on a reference point stored in kvm->arch.master_kernel_ns and
> > kvm->arch.master_cycle_now.
> > 
> > The existing KVM_[GS]ET_CLOCK functionality does not allow for this
> > relationship to be precisely saved and restored by userspace. All it can
> > currently do is set the KVM clock at a given UTC reference time, which
> > is necessarily imprecise.
> > 
> > So on live update, the guest TSC can remain cycle accurate at precisely
> > the same offset from the host TSC, but there is no way for userspace to
> > restore the KVM clock accurately.
> > 
> > Even on live migration to a new host, where the accuracy of the guest
> > time-keeping is fundamentally limited by the accuracy of wallclock
> > synchronization between the source and destination hosts, the clock jump
> > experienced by the guest's TSC and its KVM clock should at least be
> > *consistent*. Even when the guest TSC suffers a discontinuity, its KVM
> > clock should still remain the *same* arithmetic function of the guest
> > TSC, and not suffer an *additional* discontinuity.
> > 
> > To allow for accurate migration of the KVM clock, add per-vCPU ioctls
> > which save and restore the actual PV clock info in
> > pvclock_vcpu_time_info.
> > 
> > The restoration in KVM_SET_CLOCK_GUEST works by creating a new reference
> > point in time just as kvm_update_masterclock() does, and calculating the
> > corresponding guest TSC value. This guest TSC value is then passed
> > through the user-provided pvclock structure to generate the *intended*
> > KVM clock value at that point in time, and through the *actual* KVM
> > clock calculation. Then kvm->arch.kvmclock_offset is adjusted to
> > eliminate the difference.
> > 
> > Where kvm->arch.use_master_clock is false (because the host TSC is
> > unreliable, or the guest TSCs are configured strangely), the KVM clock
> > is *not* defined as a function of the guest TSC so KVM_GET_CLOCK_GUEST
> > returns an error. In this case, as documented, userspace shall use the
> > legacy KVM_GET_CLOCK ioctl. The loss of precision is acceptable in this
> > case since the clocks are imprecise in this mode anyway.
> > 
> > On *restoration*, if kvm->arch.use_master_clock is false, an error is
> > returned for similar reasons and userspace shall fall back to using
> > KVM_SET_CLOCK. This does mean that, as documented, userspace needs to
> > use *both* KVM_GET_CLOCK_GUEST and KVM_GET_CLOCK and send both results
> > with the migration data (unless the intent is to refuse to resume on a
> > host with bad TSC).
> 
> Please post this as a standalone mini-series.  AFAICT, the only dependency of
> any kind is a minor conflict with the s/hw_tsc_khz/hw_tsc_hz change, and that's
> trivial to sort out later on.

Hm? The calculations in kvm_vcpu_ioctl_set_clock_guest() are all Hz-
based, not kHz. This *was* the start of the series (Jack posted it on
its own in 2024), and I thought I'd moved the khz/hz thing to live
before it on purpose?

The kvm_xen_shared_info_init() one could be later, I guess. But is also
trivial (and its commit message sets the stage for a bunch of the
cleanups by analysing the various *different* ways that kvmclock gets
derived). 

I confess I'm not stunningly keen on breaking the series up. How about
we just do it in stages? Merge patch 1 as it's fairly trivial, and then
I can use its commit ID when I refer to its taxonomy later. Then we can
do patches 2-6 which are the KVM_[GS]ET_CLOCK_GUEST support. And I can
repost the remainder on top of that?

> > +4.145 KVM_GET_CLOCK_GUEST
> > +----------------------------
> > +
> > +:Capability: none
> 
> Why not add a CAP?  The check in the subsequent selftest is quite gross.

Because nobody would ever use it in practice anyway. Even if the ioctl
is present, you *still* have to try it and fall back to the old method
because there are ways that a *guest* can force master clock mode off.

[-- Attachment #2: smime.p7s --]
[-- Type: application/pkcs7-signature, Size: 6179 bytes --]