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

On Mon, Jul 27, 2026 at 10:27:27PM -0700, Borislav Petkov wrote:

quoted

@@ -812,12 +829,14 @@ void __init fpu__init_system_xstate(unsigned int legacy_size)
 
 	if (!boot_cpu_has(X86_FEATURE_FPU)) {
 		pr_info("x86/fpu: No FPU detected\n");
+		clear_cpu_caps_with_missing_xfeatures(0);
 		return;
 	}
 
 	if (!boot_cpu_has(X86_FEATURE_XSAVE)) {
 		pr_info("x86/fpu: x87 FPU will use %s\n",
 			boot_cpu_has(X86_FEATURE_FXSR) ? "FXSAVE" : "FSAVE");
+		clear_cpu_caps_with_missing_xfeatures(0);

Also, I'm not really clear on the usage here: if the CPU doesn't have FPU or
XSAVE, we pass in xfeature 0 which is XFEATURE_FP in both cases. And then we
clear AVX and AVX-512.

The 0 is basically forcing the checks in the function to match, i.e., it looks
to me like we're defining a new interface but then we're misusing it so that
those basic CPU flags are cleared.

*xfeatures* 0, not *xfeature* 0.  It's a bitmask.

What are we even protecting against here?

AVX and AVX-512 code needs to check whether it has FPU and XSAVE support?

I.e., we're protecting against some weird guests?

I wanna say, we should not protect but let them crash'n'burn in big big flames
which can be seen from a mile away.

Or do you have a sensible use case in mind which we really wanna protect
against and this all actually makes sense?

Hypervisors that set AVX CPUID bits without their prerequisite
xfeatures.  Or the host OS, in the case of the UML patch.

There are about 25 sites where kernel code is checking for this.  This
is just checking it at the architectural level instead.

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?

- Eric