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

[Eric Biggers <ebiggers@kernel.org>]

On Tue, Jul 28, 2026 at 11:20:07AM -0700, Borislav Petkov wrote:
> 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.

The argument is the bitmask of xfeatures that are present.  0 is an
empty bitmask, i.e. no xfeatures are present.

I can rename it to xfeatures_present and/or document the argument
explicitly in the function comment, if that would help.

> > 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?

I'm not sure what this question is asking, but UML indeed doesn't
implement cpu_has_xfeatures().  Currently most of the AVX optimized code
isn't enabled on UML, which avoids this limitation.  The RAID code is
different though, as it's enabled on UML.

> > 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?

First, the code being added *is* to fpu__init_system_xstate().  Do you
think it needs to be moved later in the function, and if so why?

Second, clearing xfeatures is the opposite of what's needed.

(It's also already there.  See loop with the comment
"Clear XSAVE features that are disabled in the normal CPUID".)

What's needed is clearing X86_FEATURE_* flags based on missing
xfeatures.

- Eric