linux-kernel - Re: [PATCH] KVM: x86: synthesize TSA CPUID bits via SCATTERED

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: <aYymNqGGnan7Ga1D@google.com>
Date: Wed, 11 Feb 2026 07:54:30 -0800
From: Sean Christopherson <seanjc@...gle.com>
To: Borislav Petkov <bp@...en8.de>
Cc: "Carlos López" <clopez@...e.de>, Jim Mattson <jmattson@...gle.com>, kvm@...r.kernel.org, 
	Paolo Bonzini <pbonzini@...hat.com>, Thomas Gleixner <tglx@...nel.org>, Ingo Molnar <mingo@...hat.com>, 
	Dave Hansen <dave.hansen@...ux.intel.com>, 
	"maintainer:X86 ARCHITECTURE (32-BIT AND 64-BIT)" <x86@...nel.org>, "H. Peter Anvin" <hpa@...or.com>, 
	"open list:X86 ARCHITECTURE (32-BIT AND 64-BIT)" <linux-kernel@...r.kernel.org>, Babu Moger <bmoger@....com>
Subject: Re: [PATCH] KVM: x86: synthesize TSA CPUID bits via SCATTERED_F()

On Wed, Feb 11, 2026, Borislav Petkov wrote:
> On Tue, Feb 10, 2026 at 03:48:56PM -0800, Sean Christopherson wrote:
> > See above regarding scattered.  As for synthesized, KVM is paranoid and so by
> > default, requires features to be supported by the host kernel *and* present in
> > raw CPUID in order to advertise support to the guest.
> 
> Yes, it will check for X86_FEATURE to be and then look at CPUID.
> 
> > Because IMO, that would be a huge net negative.  I have zero desire to go lookup
> > a table to figure out KVM's rules for supporting a given feature, and even less
> > desire to have to route KVM-internal changes through a giant shared table.  I'm
> > also skeptical that a table would provide as many safeguards as the macro magic,
> > at least not without a lot more development.
> 
> Lemme cut to the chase because it seems to me like my point is not coming
> across:

I understand what the goal is, I just don't want to buy what you're selling.

> We're changing how CPUID is handled on baremetal. Consider how much trouble
> there was and is between how the baremetal kernel handles CPUID features and
> how KVM wants to handle them and how those should be independent but they
> aren't and if we change baremetal handling - i.e., unscatter a leaf - we break
> KVM, yadda yadda, and all the friction over the years.

Those problems are _entirely_ limited to the fact that the kernel's feature tracking
isn't 100% comprehensive.  It's completely orthogonal to KVM's enumeration of its
supported feature.

> Now we have the chance to define that cleanly and also accomodate KVM's needs.
> 
> As in, you add a CPUID flag in baremetal and then in the representation of
> that flag in our internal structures, there are KVM-specific attributes which
> are used by it to do that feature flag's representation to guests.
> 
> The new scheme will get rid of the scattered crap as it is not needed anymore
> - we'll have the *whole* CPUID leaf hierarchy. Now wouldn't it be lovely to
> have a
> 
> 	.kvm_flags = EMULATED_F | X86_64_F ... RUNTIME_F
> 
> which is per CPUID feature bit and which KVM code queries?

No, it honestly sounds rather awful.

> SCATTERED_F, SYNTHESIZED_F, PASSTHROUGH_F become obsolete.

SCATTERED_F will become obsolete, SYNTHESIZED_F and PASSTHROUGH_F will not.  They
cannot.  It's impossible to express three states with one bit.  

                SYNTHESIZED_F     PASSTHROUGH_F     F
raw CPUID           DONT_CARE                 Y     Y
kernel caps                 Y         DONT_CARE     Y


If the kernel tracks both raw CPUID *and* kernel caps, then KVM can use the
table without having to (re)do CPUID when configuring KVM's feature set.  But
KVM would still need to have processing for SYNTHESIZED_F, PASSTHROUGH_F, and F,
to derive the correct state from the raw+kernel tables.

> No need for those macros, adding new CPUID feature flags would mean simply
> adding those .kvm_flags things which denote what KVM does with the feature.
> Not how it is defined internally.
> 
> And then everything JustWorks(tm) naturally without having to deal with those
> macros.
> 
> And you'd get rid of the KVM-only CPUID leafs too because everything will be
> in one central place.

Again, that's achieved purely by tracking the full CPUID hierarchy.  It has nothing
to do with EMULATED_F, X86_64_F, RUNTIME_F, SYNTHESIZED_F, PASSTHROUGH_F, etc. 

> Now why wouldn't you want that wonderful and charming thing?!

Because from my perspective, centralizing *everything* is all pain, no gain.  It
would bleed KVM details into the broader kernel, unnecessarily limit KVM's ability
to change how KVM emulates/virtualizes features, and require querying a lookaside
table to understand KVM's rules/handling.  No thanks.