Re: [PATCH v8 4/5] x86/xsave: Make XSAVE check the base CPUID features before enabling

[Sebastian Andrzej Siewior]

On 2019-06-29 17:22:59 [+0200], Vegard Nossum wrote:
> The commit for this patch in mainline
> (ccb18db2ab9d923df07e7495123fe5fb02329713) causes the kernel to hang on
> boot when passing the "nofxsr" option:

as a result of nofxsr we do:
[0]	setup_clear_cpu_cap(X86_FEATURE_FXSR);
[1]	setup_clear_cpu_cap(X86_FEATURE_FXSR_OPT);
[2]	setup_clear_cpu_cap(X86_FEATURE_XMM);


the commit in question removes then XFEATURE_MASK_SSE from
`xfeatures_mask'.
Boot stops in fpu__init_cpu_xstate() / xsetbv() due to #GP:
|If an attempt is made to set XCR0[2:1] to 10b.
(from Vol. 2C).

[1] is "harmless". Dropping [2] does not fix the issue because [0]
still clears all three flags due to 
| static const struct cpuid_dep cpuid_deps[] = {
â
|      { X86_FEATURE_XMM,              X86_FEATURE_FXSR      },

Clearing additionally XMM2 (and adding the missing bits to
xsave_cpuid_features/xfeature_names) would boot further.
Later it crashes in raid6 while probing for AVX/2 codeâ

Disabling XMM+XMM2 in order get (and fixing it up for AVX+AVX2) would
give use XSAVE instead of FSAVE.
This won't work on 64bit userland because it expects SSE to be around
(and FXSR to save the SSE bits).
Even my 32bit Debian Wheezy doesn't work because it wants FXSR :)

So if it is unlikely to have XSAVE but no FXSR I would suggest to add
"fpu__xstate_clear_all_cpu_caps()" to nofxsr and behave like "nofxsr
noxsave".

Sebastian