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: Windows password security audit tool. GUI, reports in PDF.

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

Message-ID: <3268e953e14004d1786bf07c76ae52d98d0f8259.camel@infradead.org>
Date: Tue, 02 Sep 2025 19:23:06 +0100
From: David Woodhouse <dwmw2@...radead.org>
To: Sean Christopherson <seanjc@...gle.com>
Cc: Paul Durrant <pdurrant@...zon.co.uk>, Fred Griffoul
 <fgriffo@...zon.co.uk>,  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 Tue, 2025-09-02 at 10:49 -0700, Sean Christopherson wrote:
> 
> > So even if a VMM has set the TSC frequency VM-wide with KVM_SET_TSC_KHZ
> > instead of doing it the old per- vCPU way, how can it get the results for a
> > specific VM?
> 
> I don't see any need for userspace to query per-VM support.  What I'm proposing
> is that KVM advertise the feature if the bare metal TSC is constant and the CPU
> supports TSC scaling.  Beyond that, _KVM_ doesn't need to do anything to ensure
> the guest sees a constant frequency, it's userspace's responsibility to provide
> a sane configuration.
> 
> And strictly speaking, CPUID is per-CPU, i.e. it's architecturally legal to set
> per-vCPU frequencies and then advertise a different frequency in CPUID for each
> vCPU.  That's all but guaranteed to break guests as most/all kernels assume that
> TSC operates at the same frequency on all CPUs, but as above, that's userspace's
> responsibility to not screw up.

Sure, but doesn't that make this whole thing orthogonal to the original
problem being solved? Because userspace still doesn't *know* the actual
effective TSC frequency, whether it's scaled or not.

Or are you suggesting that we add the leaf (with unscaled values) in
KVM_GET_SUPPORTED_CPUID and *also* 'correct' the values if userspace
does pass that leaf to its guests, as I had originally proposed?

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