Signed-off-by: Stefan Bader <email address hidden>
444dd40...
by
Borislav Petkov <email address hidden>
x86/fpu: Fix eager-FPU handling on legacy FPU machines
i486 derived cores like Intel Quark support only the very old,
legacy x87 FPU (FSAVE/FRSTOR, CPUID bit FXSR is not set), and
our FPU code wasn't handling the saving and restoring there
properly in the 'eagerfpu' case.
So after we made eagerfpu the default for all CPU types:
58122bf1d856 x86/fpu: Default eagerfpu=on on all CPUs
these old FPU designs broke. First, Andy Shevchenko reported a splat:
WARNING: CPU: 0 PID: 823 at arch/x86/include/asm/fpu/internal.h:163 fpu__clear+0x8c/0x160
which was us trying to execute FXRSTOR on those machines even though
they don't support it.
After taking care of that, Bryan O'Donoghue reported that a simple FPU
test still failed because we weren't initializing the FPU state properly
on those machines.
(cherry picked from commit 6e6867093de35141f0a76b66ac13f9f2e2c8e77a)
Signed-off-by: Tyler Hicks <email address hidden>
Signed-off-by: Stefan Bader <email address hidden>
8e3790d...
by
Andy Lutomirski <email address hidden>
x86/fpu: Fix math emulation in eager fpu mode
Systems without an FPU are generally old and therefore use lazy FPU
switching. Unsurprisingly, math emulation in eager FPU mode is a
bit buggy. Fix it.
There were two bugs involving kernel code trying to use the FPU
registers in eager mode even if they didn't exist and one BUG_ON()
that was incorrect.
(cherry picked from commit 4ecd16ec7059390b430af34bd8bc3ca2b5dcef9a)
Signed-off-by: Tyler Hicks <email address hidden>
Signed-off-by: Stefan Bader <email address hidden>
0e12511...
by
Andy Lutomirski <email address hidden>
x86/fpu: Fix FNSAVE usage in eagerfpu mode
In eager fpu mode, having deactivated FPU without immediately
reloading some other context is illegal. Therefore, to recover from
FNSAVE, we can't just deactivate the state -- we need to reload it
if we're not actively context switching.
We had this wrong in fpu__save() and fpu__copy(). Fix both.
__kernel_fpu_begin() was fine -- add a comment.
This fixes a warning triggerable with nofxsr eagerfpu=on.
(cherry picked from commit 5ed73f40735c68d8a656b46d09b1885d3b8740ae)
Signed-off-by: Tyler Hicks <email address hidden>
Signed-off-by: Stefan Bader <email address hidden>
5982a1a...
by
Andy Lutomirski <email address hidden>
x86/fpu: Default eagerfpu=on on all CPUs
We have eager and lazy FPU modes, introduced in:
304bceda6a18 ("x86, fpu: use non-lazy fpu restore for processors supporting xsave")
The result is rather messy. There are two code paths in almost all
of the FPU code, and only one of them (the eager case) is tested
frequently, since most kernel developers have new enough hardware
that we use eagerfpu.
It seems that, on any remotely recent hardware, eagerfpu is a win:
glibc uses SSE2, so laziness is probably overoptimistic, and, in any
case, manipulating TS is far slower that saving and restoring the
full state. (Stores to CR0.TS are serializing and are poorly
optimized.)
To try to shake out any latent issues on old hardware, this changes
the default to eager on all CPUs. If no performance or functionality
problems show up, a subsequent patch could remove lazy mode entirely.
This issue is a fallout from the command-line parsing move.
When "eagerfpu=off" is given as a command-line input, the kernel
should disable MPX support. The decision for turning off MPX was
made in fpu__init_system_ctx_switch(), which is after the
selection of the XSAVE format. This patch fixes it by getting
that decision done earlier in fpu__init_system_xstate().
(backported from commit a5fe93a549c54838063d2952dd9643b0b18aa67f)
Signed-off-by: Tyler Hicks <email address hidden>
Signed-off-by: Stefan Bader <email address hidden>
f12c41e...
by
Andy Lutomirski <email address hidden>
x86/fpu: Fix 'no387' regression
After fixing FPU option parsing, we now parse the 'no387' boot option
too early: no387 clears X86_FEATURE_FPU before it's even probed, so
the boot CPU promptly re-enables it.
I suspect it gets even more confused on SMP.
Fix the probing code to leave X86_FEATURE_FPU off if it's been
disabled by setup_clear_cpu_cap().
The function fpu__init_system() is executed before
parse_early_param(). This causes wrong FPU configuration. This
patch fixes this issue by parsing boot_command_line in the
beginning of fpu__init_system().
With all four patches in this series, each parameter disables
features as the following:
