On Sat, 2026-05-09 at 23:46 +0100, David Woodhouse wrote: > From: David Woodhouse <[email protected]> > > Add a read-only per-vCPU attribute that reports the effective TSC and > APIC bus frequencies as seen by the guest, after hardware TSC scaling > is applied. > > This allows userspace to populate CPUID leaf 0x40000010 (the "generic" > timing information leaf used by FreeBSD, XNU, and VMware) with correct > values, without KVM needing to modify guest CPUID at runtime. > > The effective TSC frequency differs from what userspace requested via > KVM_SET_TSC_KHZ due to the granularity of hardware scaling and the > host kernel's measurement of its own TSC frequency.
As I do another pass on this series, I don't think I can stand by that claim. Even on AMD where we only have a 32-bit shift for TSC scaling, that's still 0.23 PPM, or about half a Hz precision when scaling a 2400MHz TSC. And this API was returning kHz anyway! So it was as likely to be *introducing* inaccuracy by returning 2299999kHz when userspace had actually asked for 2300000 and the real rate ended up being 2399999.9995. I think I'll drop it; and userspace should just use KVM_GET_TSC_KHZ. That does leave userspace still needing a way to get the APIC bus frequency, to populate CPUID. So maybe I'll just make an attribute which returns that as a single value. Or *maybe* KVM should just populate leaf 0x40000010 in its default template? I thought we decided not to do that though, as unsuspecting userspace might pass it through uncorrected from the default values? We could put *zero* in the TSC part, but that just seems like it's another potential weirdness for the guest to see.
smime.p7s
Description: S/MIME cryptographic signature
