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

Sean Christopherson <[email protected]>
Newsgroups org.kernel.vger.linux-doc,org.kernel.vger.kvm,org.kernel.vger.linux-kernel,org.kernel.vger.linux-kselftest,org.xenproject.lists.xen-devel
Message-ID <[email protected]>
On Mon, Aug 10, 2026, David Woodhouse wrote:
> On Mon, 2026-08-10 at 10:47 -0700, Sean Christopherson wrote:
> >  
> > > But when the vCPUs merely have a different TSC *offset*, that's not a
> > > problem. The offset is applied to that vCPU's kvmclock->tsc_timestamp
> > > field, and it all comes out in the wash.
> > 
> > It's not though?  The value stored in kvmclock->tsc_timestamp is per-VM, not
> > per-vCPU, when using the master clock.  It's a little easier to see once the
> > master clock TSC isn't shoved into host_tsc:
> > 
> > 	do {
> > 		seq = read_seqcount_begin(&ka->pvclock_sc);
> > 		use_master_clock = ka->use_master_clock;
> > 		if (!use_master_clock)
> > 			continue;
> > 
> > 		if (!kvm_get_time_and_clockread(&kernel_ns, &host_tsc)) {
> > 			use_master_clock = false;
> > 			continue;
> > 		}
> > 
> > 		master_tsc = ka->master_cycle_now;
> > 		master_ns = ka->master_kernel_ns;
> > 	} while (read_seqcount_retry(&ka->pvclock_sc, seq));
> > 
> > 	...
> > 
> > 	if (use_master_clock) {
> > 		hv_clock.tsc_timestamp = kvm_read_l1_tsc(v, master_tsc);
> > 		hv_clock.system_time = master_ns + v->kvm->arch.kvmclock_offset;
> > 	} else {
> > 		hv_clock.tsc_timestamp = tsc_timestamp;
> > 		hv_clock.system_time = kernel_ns + v->kvm->arch.kvmclock_offset;
> > 	}
> 
> Meh. I shall have to build a better test case for that one. Thanks.
> 
> > 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.
lmpx.com only provides a reader for public news (NNTP) servers. It is not affiliated with the servers or forums shown here and is not responsible for the content of articles, which is written by their respective authors.