Re: [PATCH v7 17/36] KVM: x86: Allow KVM master clock mode when TSCs are offset from each other

On Tue, 2026-08-11 at 07:33 -0700, Sean Christopherson wrote:
> 
> Actually, why are KVM_{G,S}ET_CLOCK_GUEST vCPU-scoped?  Per the documentation,
> the API "Sets the KVM clock (for the whole VM) in terms of the vCPU TSC".  If
> the APIs are VM-scoped instead of vCPU-scoped, then KVM can simply save/restore
> what's in the per-VM masterclock state, no?

They're vCPU-scoped because they need to be tied to a guest TSC (on
live migration, neither ka->master_cycle_now nor ka->master_kernel_ns
are useful — those are the "per-VM masterclock state").

Theoretically, guest TSCs can be different on each vCPU (different
offset, different *rate* even. Not that we allow KVM_[GS]ET_CLOCK_GUEST
at different rates, I concede).

So they operate in the context of a given vCPU, and *its* TSC.

And I think I'm going to defend that 'theoretical they can be
different', because I *would* like to eliminate the ways that a *guest*
can force non-masterclock mode, and that does mean allowing the offset-
TSC case.

FWIW in my local tree I've just extended the pvclock_migration_test to
test precisely the thing you were concerned about: three vCPUs with
divergent TSC offsets, migrated by setting each vCPU's TSC and then
invoking KVM_SET_CLOCK_GUEST once, through vCPU0. Masterclock stays
active, TSC_STABLE_BIT is correctly clear, and all three vCPUs'
pvclocks (and KVM_GET_CLOCK) agree to within a nanosecond afterwards.
I'll include that in the next spin.

> That would also help address my concerns about sanity checking the TSC frequency
> against the kvmclock frequency, as the APIs are much more blatantly about saving
> and restoring masterclock state.  For whatever reason, it feels more natural for
> me to say that KVM_SET_CLOCK_GUEST will fail if the target frequency doesn't
> (fuzzily?) match the frequency at which the masterclock is already configured.
> Probably because use_master_clock directly gates that information?  Whereas the
> vCPU's frequency is independently configured but obviously influences masterclock
> mode.

I am perfectly happy to say that the *existing* check as I have coded
it, is matching against the frequency at which the masterclock is
configured. Because we can't *get* there if the guest is not in
masterclock mode, and it can't be in masterclock mode unless all its
vCPUs are running at the same rate, which *is* the master clock rate.
:)

I guess I could even concede to change the actual code rather than just
the comment... (untested)

Still needs the *offset* of the vCPU though.

--- a/arch/x86/kvm/x86.c
+++ b/arch/x86/kvm/x86.c
@@ -3595,15 +3595,15 @@ static int kvm_vcpu_ioctl_set_clock_guest(struct kvm_vcpu *v, void __user *argp

 	if (kvm_caps.has_tsc_control)
 		curr_tsc_hz = kvm_scale_tsc(curr_tsc_hz,
-					    v->arch.l1_tsc_scaling_ratio);
+					    ka->master_tsc_scaling_ratio);

 	/*
 	 * The mul/shift in the provided pvclock structure encode the guest
 	 * TSC frequency at which it was generated. Sanity-check that it is
-	 * consistent with this vCPU's effective TSC frequency, allowing a
-	 * discrepancy of 1 kHz either way since independently calibrated
-	 * hosts will not measure precisely the same value even for the
-	 * same nominal frequency.
+	 * consistent with the frequency at which the masterclock is
+	 * configured, allowing a discrepancy of 1 kHz either way since
+	 * independently calibrated hosts will not measure precisely the
+	 * same value even for the same nominal frequency.
 	 */
 	if (user_tsc_hz < curr_tsc_hz - 1000 ||
 	    user_tsc_hz > curr_tsc_hz + 1000) {