On Fri, 2025-08-29 at 11:08 +0000, Durrant, Paul wrote: > On 29/08/2025, 10:51, "David Woodhouse" <dwmw2@xxxxxxxxxxxxx <mailto:dwmw2@xxxxxxxxxxxxx>> wrote: > [snip] > > • Declare that we don't care that it's strictly an ABI change, and > > VMMs which used to just populate the leaf and let KVM fill it in > > for Xen guests now *have* to use the new API. > > > > > > I'm actually OK with that, even the last one, because I've just noticed > > that KVM is updating the *wrong* Xen leaf. 0x40000x03/2 EAX is supposed > > to be the *host* TSC frequency, and the guest frequency is supposed to > > be in 0x40000x03/0 ECX. And Linux as a Xen guest doesn't even use it > > anyway, AFAICT > > > > Paul, it was your code originally; are you happy with removing it? > > Yes, if it is incorrect then please fix it. I must have become > confused whilst reading the original Xen code. The proposal is not to *fix* it but just to rip it out entirely and provide userspace with some way of knowing the effective TSC frequency. This does mean userspace would have to set the vCPU's TSC frequency and then query the kernel before setting up its CPUID. And in the absence of scaling, this KVM API would report the hardware TSC frequency. I guess the API would have to return -EHARDWARETOOSTUPID if the TSC frequency *isn't* the same across all CPUs and all power states, etc.
Attachment:
smime.p7s
Description: S/MIME cryptographic signature
