> 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".
Thanks for the analysis Sebastian. Makes sense.
This would likely work, but I think I would rather just remove the option.
-Andi
>
> The commit for this patch in mainline
> (ccb18db2ab9d923df07e7495123fe5fb02329713) causes the kernel to hang on
> boot when passing the "nofxsr" option:
Thanks.
Hmm, I'm not sure nofxsr ever worked on 64bit. Certainly SSE cannot be
saved/restored in any other way during the context switch.
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_
On 10/5/17 11:52 PM, Andi Kleen wrote:
From: Andi Kleen
Before enabling XSAVE, not only check the XSAVE specific CPUID bits,
but also the base CPUID features of the respective XSAVE feature.
This allows to disable individual XSAVE states using the existing
clearcpuid= option, which can be use
From: Andi Kleen
Before enabling XSAVE, not only check the XSAVE specific CPUID bits,
but also the base CPUID features of the respective XSAVE feature.
This allows to disable individual XSAVE states using the existing
clearcpuid= option, which can be useful for performance testing
and debugging,
5 matches
Mail list logo
