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

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.

I'll take another look.