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

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <caf7b1ea18eb25e817af5ea907b2f6ea31ecc3e1.camel@infradead.org>
Date: Fri, 29 Aug 2025 12:19:53 +0100
From: David Woodhouse <dwmw2@...radead.org>
To: "Durrant, Paul" <pdurrant@...zon.co.uk>, Sean Christopherson
	 <seanjc@...gle.com>, "Griffoul, Fred" <fgriffo@...zon.co.uk>
Cc: Colin Percival <cperciva@...snap.com>, Paolo Bonzini
 <pbonzini@...hat.com>,  Thomas Gleixner <tglx@...utronix.de>, Ingo Molnar
 <mingo@...hat.com>, Borislav Petkov <bp@...en8.de>, Dave Hansen
 <dave.hansen@...ux.intel.com>, "x86@...nel.org" <x86@...nel.org>, "H. Peter
 Anvin" <hpa@...or.com>, Vitaly Kuznetsov <vkuznets@...hat.com>,
 "kvm@...r.kernel.org" <kvm@...r.kernel.org>, "linux-kernel@...r.kernel.org"
 <linux-kernel@...r.kernel.org>, "Graf (AWS), Alexander" <graf@...zon.de>, 
 Ajay Kaher <ajay.kaher@...adcom.com>, Alexey Makhalov
 <alexey.makhalov@...adcom.com>
Subject: Re: [PATCH v2 0/3] Support "generic" CPUID timing leaf as KVM guest
 and host

On Fri, 2025-08-29 at 11:08 +0000, Durrant, Paul wrote:
> On 29/08/2025, 10:51, "David Woodhouse" <dwmw2@...radead.org <mailto:dwmw2@...radead.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.

Download attachment "smime.p7s" of type "application/pkcs7-signature" (5069 bytes)