Re: [PATCH v10 21/21] KVM: x86: Use kernel timekeeping snapshot to get walltime+TSC

[Sean Christopherson]

On Fri, Aug 28, 2026, David Woodhouse wrote:
> On Wed, 2026-08-26 at 21:49 +0000, sashiko-bot@xxxxxxxxxx wrote:
> > [Severity: High]
> > Does removing KVM's local TSC clamping expose guests to mismatched time pairs?
> > 
> > When establishing the guest's PV clock, KVM provides a master clock
> > snapshot pairing a host TSC with a system time. The previous read_tsc()
> > logic explicitly clamped the TSC to cycle_last to maintain mathematical
> > consistency.
> 
> I think this is basically the same class of issue I brought up in
> https://lore.kernel.org/all/87v7beb7s3.ffs@fw13/ and Thomas said the
> right thing is just to ignore it?
>
> If the discrepancy was more than a few cycles, we shouldn't be in
> masterclock mode anyway, should we?

Agreed.  If a host CPU really has a TSC that is observably behind others, KVM
will mark the TSC unstable when loading a vCPU on that pCPU.

		s64 tsc_delta = !vcpu->arch.last_host_tsc ? 0 :
				rdtsc() - vcpu->arch.last_host_tsc;
		if (tsc_delta < 0)
			mark_tsc_unstable("KVM discovered backwards TSC");

And as Thomas pointed out, the discrepancy will show up at some point.  E.g. even
if the kernel provided a perfect pair, RDTSC from the guest would read a too-low
value since KVM has historically required identical offsets to use masterclock,
i.e. the guest would still be able to observe time going backwards if a vCPU did
__pvclock_clocksource_read() with a TSC that is behind the masterclock reference.