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