Re: [PATCH v2 0/3] Support "generic" CPUID timing leaf as KVM guest and host

[David Woodhouse <dwmw2@infradead.org>]

[-- Attachment #1: Type: text/plain, Size: 1396 bytes --]

On Fri, 2025-08-29 at 11:08 +0000, Durrant, Paul wrote:
> On 29/08/2025, 10:51, "David Woodhouse" <dwmw2@infradead.org <mailto:dwmw2@infradead.org>> 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 #2: smime.p7s --]
[-- Type: application/pkcs7-signature, Size: 5069 bytes --]