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

[Eric Biggers]

On Wed, Aug 12, 2026 at 10:48:26AM -0700, Borislav Petkov wrote:
> On Tue, Jul 28, 2026 at 04:47:26PM -0700, Borislav Petkov wrote:
> > On Tue, Jul 28, 2026 at 04:34:30PM -0700, Eric Biggers wrote:
> > > I don't know what your suggestion is.  Are you still asking for the
> > > function to be renamed to clear_cpu_caps_xft()?  Note that the
> > > abbreviation "xft" doesn't appear anywhere else in arch/x86/.  Maybe you
> > > want the argument inverted?  I don't know what you want, sorry.
> > 
> > That's fine - I'll take a look at the final version after having gone through
> > the whole pile and then holler if I still see a need.
> 
> Ok, here's something ontop of yours. It is tested only in a guest but it
> should show the intention.
> 
> The first call in:
> 
> 	if (!boot_cpu_has(X86_FEATURE_FPU)) {
> 
> is not needed because that is caught earlier:
> 
> [    0.553199] x86/fpu: Giving up, no FPU found and no math emulation present
> 
> and we stop there.

Interesting, so the !boot_cpu_has(X86_FEATURE_FPU) check is dead code
since ab05214025ee ("x86/fpu: Remove MATH_EMULATION and related glue
code").  Sure, there's no need to add anything to there then, though we
should do a separate patch that removes it.

> The second one can then simply do:
> 
>                 /* Disable all dependent flags too */
>                 setup_clear_cpu_cap(X86_FEATURE_XSAVE);
> 
> because that'll clear all dependent flags and we should be good there:

Sure, that works.  I'm not sure it's actually easier to understand than
what I proposed; it's kind of contradictory to call
"setup_clear_cpu_cap(X86_FEATURE_XSAVE)" when we just verified it is
clear.  But the comment mentioning that it's actually for clearing
dependent flags helps.  If you prefer this way, let's do this.

> and then the rest is streamlined into fpu__init_system_xstate() where all
> sanity checking should be performed, as I mentioned intially.

It's functionally equivalent, but yes we can write it this way if you
prefer.  Is it okay if I fold your diff (minus the pr_info()) into this
patch?  (I'll also add FW_BUG to the error messages as Thomas
requested.)

- Eric