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

[Sean Christopherson <seanjc@google.com>]

On Mon, Feb 09, 2026, Borislav Petkov wrote:
> On Mon, Feb 09, 2026 at 08:29:36AM -0800, Sean Christopherson wrote:
> > Nope.  KVM cares about what KVM can virtualize/emulate, and about helping userspace
> > accurately represent the virtual CPU that will be enumerated to the guest.
> 
> So why don't you key on that in those macros instead of how they're defined?
> 
> 	EXPOSE_TO_GUEST_F()
> 
> and then underneath we can figure out how to expose them.

Huh?  That's what the macros do, they describe KVM's handling of the associated
feature.  SYNTHESIZED is a bit weird because it bleeds some kernel details into
KVM, but ultimately it's still KVM decision as to whether or not "forced" features
can be synthesized for the guest.

> We could have a helper table which determines what each feature is and how it
> should interact with raw host CPUID or something slicker.
> 
> >   F               : Features that must be present in boot_cpu_data and raw CPUID
> >   SCATTERED_F     : Same as F(), but are scattered by the kernel
> >   X86_64_F        : Same as F(), but are restricted to 64-bit kernels
> >   EMULATED_F      : Always supported; the feature is unconditionally emulated in software
> >   SYNTHESIZED_F   : Features that must be present in boot_cpu_data, but may or
> >                     may not be in raw CPUID.  May also be scattered.
> >   PASSTHROUGH_F   : Features that must be present in raw CPUID, but may or may
> >                     not be present in boot_cpu_data
> >   ALIASED_1_EDX_F : Features in 0x8000_0001.EDX that are duplicates of identical 0x1.EDX features
> >   VENDOR_F        : Features that are controlled by vendor code, often because
> >                     they are guarded by a vendor specific module param.  Rules
> >                     vary, but typically they are handled like basic F() features
> >   RUNTIME_F       : Features that KVM dynamically sets/clears at runtime, but that
> >                     are never adveristed to userspace.  E.g. OSXSAVE and OSPKE.
> 
> And for the time being, I'd love if this were somewhere in
> arch/x86/kvm/cpuid.c so that it is clear how one should use those macros.

I'll a patch with the above and more guidance.

> The end goal of having the user not care about which macro to use would be the
> ultimate, super-duper thing tho.

And impossible, for all intents and purposes.  The user/contributor/developer
needs to define KVM's handling semantics *somehwere*.  Sure, we could to that in
a big array or something, but that's just a different way of dressing up the same
pig.  All of this very much is an ugly pig, but it's the concepts and mechanics
that are ugly and convoluted.

E.g. if we define a giant array or table, the contributor will need to map the
feature to one of the above macros.

In other words, kvm_initialize_cpu_caps() _is_ the helper table.  If someone wants
to try and do better, by all means, have at it.  But I won't hold my breath.