[PATCH v2 1/8] x86/fpu: Check for missing AVX and AVX-512 xstate bits

[Borislav Petkov]

On Mon, Jul 27, 2026 at 10:45:32PM -0700, Eric Biggers wrote:
> *xfeatures* 0, not *xfeature* 0.  It's a bitmask.

That doesn't make it more clear. It does "clear cpu caps with missing
xfeatures 0". I can't parse that code, maybe I don't see it yet.

> Hypervisors that set AVX CPUID bits without their prerequisite
> xfeatures. 

Yeah, those are the ones I don't care about.

> Or the host OS, in the case of the UML patch.

That was because UML didn't have cpu_has_xfeatures(), right?
 
> There are about 25 sites where kernel code is checking for this.  This
> is just checking it at the architectural level instead.

So tglx mentioned another case - firmware. Apparently we can have firmware
which fumbles the configuration of those bits and I can very much see that
happening - it is firmware, doh, ofc.

> We could try taking the position that this is not supported at all and
> just delete all the cpu_has_xfeatures() checks without replacing them
> with anything, and see what bug reports we receive (other than all the
> AI ones which we'd need to just ignore).  This would mean just taking
> patches 3-8.  Is that what you'd prefer?

I had another idea this morning: towards the end of fpu__init_system_xstate(),
we have figured out everything we support, components, buffer sizes, etc.
There we also do a paranoia check on the xfeatures mask.

How about we go through the final xfeatures mask and then clear bits which are
wrong?

This way we'll have all the checking done in one place, if checks pass we can
say the machine is ok to do xstate handling and then we can drop all other
checks around the tree.

How does that sound?

Thx.

-- 
Regards/Gruss,
    Boris.

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