Re: [PATCH] KVM: x86: synthesize TSA CPUID bits via SCATTERED_F()

[Borislav Petkov]

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:

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.

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?

SCATTERED_F, SYNTHESIZED_F, PASSTHROUGH_F become obsolete.

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.

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

:-)

-- 
Regards/Gruss,
    Boris.

https://people.kernel.org/tglx/notes-about-netiquette