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) {
smime.p7s
Description: S/MIME cryptographic signature
