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

[Jim Mattson]

On Sun, Feb 8, 2026 at 1:14 PM Borislav Petkov <bp@xxxxxxxxx> wrote:
>
> On Sun, Feb 08, 2026 at 12:50:18PM -0800, Jim Mattson wrote:
> > > /*
> > >  * Synthesized Feature - For features that are synthesized into boot_cpu_data,
> > >  * i.e. may not be present in the raw CPUID, but can still be advertised to
> > >  * userspace.  Primarily used for mitigation related feature flags.
> > >                ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
> > >  */
> > > #define SYNTHESIZED_F(name)
> > >
> > > > +             SCATTERED_F(TSA_SQ_NO),
> > > > +             SCATTERED_F(TSA_L1_NO),
> > >
> > > And scattered are of the same type.
> > >
> > > Sean, what's the subtle difference here?
> >
> > SYNTHESIZED_F() sets the bit unconditionally. SCATTERED_F() propagates
> > the bit (if set) from the host's cpufeature flags.
>
> Yah, and I was hinting at the scarce documentation.
>
> SYNTHESIZED_F() is "Primarily used for mitigation related feature flags."
> SCATTERED_F() is "For features that are scattered by cpufeatures.h."

Ugh. I have to rescind my Reviewed-by. IIUC, SCATTERED_F() implies a
logical and with hardware CPUID, which means that the current proposal
will never set the ITS_NO bits.

I clearly don't have any idea how the new infrastructure works, and
there's too much CPP nonsense for me to care. I'll just defer to Sean.

> And frankly, I don't understand why there needs to be a difference whether the
> feature is scattered or synthesized. If the flag is set on baremetal, then it
> is and it being set, denotes what it means. And if it is not set, then it
> means the absence of that feature.
>
> It is that simple.
>
> Then it becomes a decision of the hypervisor whether to expose it to the guest
> or not.
>
> Not whether it is synthesized or scattered.
>
> But maybe I'm missing an aspect which is important for virt...
>
> --
> Regards/Gruss,
>     Boris.
>
> https://people.kernel.org/tglx/notes-about-netiquette