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

[Sean Christopherson <seanjc@google.com>]

On Tue, Aug 11, 2026, Sean Christopherson wrote:
> On Mon, Aug 10, 2026, David Woodhouse wrote:
> > On Mon, 2026-08-10 at 13:56 -0700, Sean Christopherson wrote:
> > >  
> > > > > To allow different offsets, KVM would need to track a per-vCPU offset to the
> > > > > master clock and apply that in kvm_guest_time_update() (and maybe other places?).
> > > > > Which is doable, but it's not clear to me why we'd want to support that (though
> > > > > I haven't fully processed the back half ot his series, so it's very possible I'm
> > > > > missing something obvious).
> > > > 
> > > > Because I want to reduce the number of cases where we have to fall back
> > > > to non-masterclock mode. Especially the ones which are driven by
> > > > *guests* rather than weird choices on the VMM's part.
> > > 
> > > But why though?  What is the harm to the host or guest?  E.g. does it make it more
> > > difficult to accurately migrate the VM?  I'm not opposed to allowing master-clock
> > > mode with diverging offsets, just trying to understand why it matters.
> > 
> > Accurate migration without masterclock is hard, yes. The
> > KVM_SET_CLOCK_GUEST thing relies on it (because the principle is that
> > you get the *TSC* right, then the KVM clock is just a fixed
> > mathematical function of that).
> > 
> > That *shouldn't* be difficult with offsets between vCPUs. Just use the
> > TSC of vCPU0 as the reference for KVM_SET_CLOCK_GUEST and let the
> > others just have their offset from that.
> 
> Yeah, my only (quite mild) concern is that we would introduce fragility by adding
> yet another variable that needs to be accounted for, but AFAICT it's literally
> just the tsc_timestamp in the shared data structure that consumes the per-vCPU
> offset.

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?

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.