On Fri, May 15, 2026, [email protected] wrote: > > diff --git a/arch/x86/kernel/kvmclock.c b/arch/x86/kernel/kvmclock.c > > index 62c8ea2e67691..7607920ae386e 100644 > > --- a/arch/x86/kernel/kvmclock.c > > +++ b/arch/x86/kernel/kvmclock.c > > @@ -190,6 +190,20 @@ void kvmclock_cpu_action(enum kvm_guest_cpu_action > > action) > > } > > } > > > > +static unsigned long kvm_get_cpu_khz(void) > > +{ > > + unsigned int cpu_khz; > > + > > + /* > > + * Prefer CPUID over kvmclock when possible, as the base CPU frequency > > + * isn't necessarily the same as the kvmlock "TSC" frequency. > > + */ > > + if (!cpuid_get_cpu_freq(&cpu_khz)) > > + return cpu_khz; > > + > > + return pvclock_tsc_khz(this_cpu_pvti()); > > Before this patch, both calibrate_cpu and calibrate_tsc used > kvm_get_tsc_khz(), which checks kvm_para_tsc_khz() to get the exact TSC > frequency from KVM's PV CPUID timing leaf, and only falls back to > pvclock_tsc_khz() if it is unavailable. > > Does the fallback path in kvm_get_cpu_khz() bypass kvm_para_tsc_khz() > entirely? For VMs that expose KVM's PV CPUID timing leaf but not > CPUID.0x16, it looks like cpu_khz will now be reverse-calculated from > pvclock multipliers instead of using the exact hypervisor-provided value. > > Could this introduce a precision regression due to truncation loss, causing > cpu_khz and tsc_khz to needlessly diverge on the fallback path?
David pointed this out too, I'll fix in the next version.
