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.
