Re: [PATCH] KVM: x86: synthesize TSA CPUID bits via SCATTERED_F()
From: Borislav Petkov
Date: Mon Feb 09 2026 - 12:48:20 EST
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.
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.
The end goal of having the user not care about which macro to use would be the
ultimate, super-duper thing tho.
I'd say.
Thx.
--
Regards/Gruss,
Boris.
https://people.kernel.org/tglx/notes-about-netiquette