2012-02-22 05:19:22 +08:00
|
|
|
/*
|
|
|
|
* Copyright (C) 1994 Linus Torvalds
|
|
|
|
*
|
|
|
|
* Pentium III FXSR, SSE support
|
|
|
|
* General FPU state handling cleanups
|
|
|
|
* Gareth Hughes <gareth@valinux.com>, May 2000
|
|
|
|
* x86-64 work by Andi Kleen 2002
|
|
|
|
*/
|
|
|
|
|
2015-04-24 08:54:44 +08:00
|
|
|
#ifndef _ASM_X86_FPU_INTERNAL_H
|
|
|
|
#define _ASM_X86_FPU_INTERNAL_H
|
2012-02-22 05:19:22 +08:00
|
|
|
|
2012-07-25 07:05:27 +08:00
|
|
|
#include <linux/compat.h>
|
2015-04-26 22:56:05 +08:00
|
|
|
#include <linux/sched.h>
|
2012-02-22 05:19:22 +08:00
|
|
|
#include <linux/slab.h>
|
2015-04-22 16:58:10 +08:00
|
|
|
|
2012-02-22 05:19:22 +08:00
|
|
|
#include <asm/user.h>
|
2015-04-24 08:46:00 +08:00
|
|
|
#include <asm/fpu/api.h>
|
2015-04-28 14:41:33 +08:00
|
|
|
#include <asm/fpu/xstate.h>
|
2012-02-22 05:19:22 +08:00
|
|
|
|
2015-04-24 09:06:56 +08:00
|
|
|
#define MXCSR_DEFAULT 0x1f80
|
|
|
|
|
x86, fpu: Unify signal handling code paths for x86 and x86_64 kernels
Currently for x86 and x86_32 binaries, fpstate in the user sigframe is copied
to/from the fpstate in the task struct.
And in the case of signal delivery for x86_64 binaries, if the fpstate is live
in the CPU registers, then the live state is copied directly to the user
sigframe. Otherwise fpstate in the task struct is copied to the user sigframe.
During restore, fpstate in the user sigframe is restored directly to the live
CPU registers.
Historically, different code paths led to different bugs. For example,
x86_64 code path was not preemption safe till recently. Also there is lot
of code duplication for support of new features like xsave etc.
Unify signal handling code paths for x86 and x86_64 kernels.
New strategy is as follows:
Signal delivery: Both for 32/64-bit frames, align the core math frame area to
64bytes as needed by xsave (this where the main fpu/extended state gets copied
to and excludes the legacy compatibility fsave header for the 32-bit [f]xsave
frames). If the state is live, copy the register state directly to the user
frame. If not live, copy the state in the thread struct to the user frame. And
for 32-bit [f]xsave frames, construct the fsave header separately before
the actual [f]xsave area.
Signal return: As the 32-bit frames with [f]xstate has an additional
'fsave' header, copy everything back from the user sigframe to the
fpstate in the task structure and reconstruct the fxstate from the 'fsave'
header (Also user passed pointers may not be correctly aligned for
any attempt to directly restore any partial state). At the next fpstate usage,
everything will be restored to the live CPU registers.
For all the 64-bit frames and the 32-bit fsave frame, restore the state from
the user sigframe directly to the live CPU registers. 64-bit signals always
restored the math frame directly, so we can expect the math frame pointer
to be correctly aligned. For 32-bit fsave frames, there are no alignment
requirements, so we can restore the state directly.
"lat_sig catch" microbenchmark numbers (for x86, x86_64, x86_32 binaries) are
with in the noise range with this change.
Signed-off-by: Suresh Siddha <suresh.b.siddha@intel.com>
Link: http://lkml.kernel.org/r/1343171129-2747-4-git-send-email-suresh.b.siddha@intel.com
[ Merged in compilation fix ]
Link: http://lkml.kernel.org/r/1344544736.8326.17.camel@sbsiddha-desk.sc.intel.com
Signed-off-by: H. Peter Anvin <hpa@linux.intel.com>
2012-07-25 07:05:29 +08:00
|
|
|
extern unsigned int mxcsr_feature_mask;
|
2012-02-22 05:19:22 +08:00
|
|
|
|
2015-04-30 23:15:32 +08:00
|
|
|
extern union fpregs_state init_fpstate;
|
2015-04-30 17:07:06 +08:00
|
|
|
|
2015-04-30 02:35:33 +08:00
|
|
|
extern void fpu__init_cpu(void);
|
2015-04-25 12:26:36 +08:00
|
|
|
extern void fpu__init_system_xstate(void);
|
|
|
|
extern void fpu__init_cpu_xstate(void);
|
2015-04-26 21:07:18 +08:00
|
|
|
extern void fpu__init_system(struct cpuinfo_x86 *c);
|
2015-04-25 12:26:36 +08:00
|
|
|
|
2015-04-30 23:15:32 +08:00
|
|
|
extern void fpstate_init(union fpregs_state *state);
|
2015-04-30 16:08:36 +08:00
|
|
|
#ifdef CONFIG_MATH_EMULATION
|
2015-04-30 23:15:32 +08:00
|
|
|
extern void fpstate_init_soft(struct swregs_state *soft);
|
2015-04-30 16:08:36 +08:00
|
|
|
#else
|
2015-04-30 23:15:32 +08:00
|
|
|
static inline void fpstate_init_soft(struct swregs_state *soft) {}
|
2015-04-30 16:08:36 +08:00
|
|
|
#endif
|
2015-04-30 23:15:32 +08:00
|
|
|
static inline void fpstate_init_fxstate(struct fxregs_state *fx)
|
2015-04-30 16:08:36 +08:00
|
|
|
{
|
|
|
|
fx->cwd = 0x37f;
|
|
|
|
fx->mxcsr = MXCSR_DEFAULT;
|
|
|
|
}
|
2015-04-26 22:56:05 +08:00
|
|
|
|
2015-04-30 15:29:38 +08:00
|
|
|
extern int dump_fpu(struct pt_regs *, struct user_i387_struct *);
|
|
|
|
extern int fpu__exception_code(struct fpu *fpu, int trap_nr);
|
2015-04-30 02:24:14 +08:00
|
|
|
|
|
|
|
/*
|
|
|
|
* High level FPU state handling functions:
|
|
|
|
*/
|
2015-04-30 18:59:30 +08:00
|
|
|
extern void fpu__activate_curr(struct fpu *fpu);
|
|
|
|
extern void fpu__activate_stopped(struct fpu *fpu);
|
2015-04-30 02:24:14 +08:00
|
|
|
extern void fpu__save(struct fpu *fpu);
|
2015-05-04 17:49:58 +08:00
|
|
|
extern void fpu__restore(struct fpu *fpu);
|
2015-04-30 03:09:18 +08:00
|
|
|
extern int fpu__restore_sig(void __user *buf, int ia32_frame);
|
2015-04-30 02:24:14 +08:00
|
|
|
extern void fpu__drop(struct fpu *fpu);
|
|
|
|
extern int fpu__copy(struct fpu *dst_fpu, struct fpu *src_fpu);
|
2015-04-30 02:35:33 +08:00
|
|
|
extern void fpu__clear(struct fpu *fpu);
|
2015-04-30 02:24:14 +08:00
|
|
|
|
2015-04-26 22:56:05 +08:00
|
|
|
extern void fpu__init_check_bugs(void);
|
|
|
|
extern void fpu__resume_cpu(void);
|
|
|
|
|
2015-05-05 17:34:49 +08:00
|
|
|
/*
|
|
|
|
* Debugging facility:
|
|
|
|
*/
|
|
|
|
#ifdef CONFIG_X86_DEBUG_FPU
|
|
|
|
# define WARN_ON_FPU(x) WARN_ON_ONCE(x)
|
|
|
|
#else
|
|
|
|
# define WARN_ON_FPU(x) ({ 0; })
|
|
|
|
#endif
|
|
|
|
|
2015-04-23 18:18:28 +08:00
|
|
|
DECLARE_PER_CPU(struct fpu *, fpu_fpregs_owner_ctx);
|
2012-02-22 05:19:22 +08:00
|
|
|
|
2015-02-07 04:02:01 +08:00
|
|
|
/*
|
2015-04-23 18:18:28 +08:00
|
|
|
* Must be run with preemption disabled: this clears the fpu_fpregs_owner_ctx,
|
2015-02-07 04:02:01 +08:00
|
|
|
* on this CPU.
|
|
|
|
*
|
|
|
|
* This will disable any lazy FPU state restore of the current FPU state,
|
|
|
|
* but if the current thread owns the FPU, it will still be saved by.
|
|
|
|
*/
|
|
|
|
static inline void __cpu_disable_lazy_restore(unsigned int cpu)
|
|
|
|
{
|
2015-04-23 18:18:28 +08:00
|
|
|
per_cpu(fpu_fpregs_owner_ctx, cpu) = NULL;
|
2015-02-07 04:02:01 +08:00
|
|
|
}
|
|
|
|
|
2015-04-23 23:25:44 +08:00
|
|
|
static inline int fpu_want_lazy_restore(struct fpu *fpu, unsigned int cpu)
|
2015-02-07 04:02:01 +08:00
|
|
|
{
|
2015-04-23 23:25:44 +08:00
|
|
|
return fpu == this_cpu_read_stable(fpu_fpregs_owner_ctx) && cpu == fpu->last_cpu;
|
2015-02-07 04:02:01 +08:00
|
|
|
}
|
|
|
|
|
2012-02-22 05:19:22 +08:00
|
|
|
#define X87_FSW_ES (1 << 7) /* Exception Summary */
|
|
|
|
|
2012-09-07 05:58:52 +08:00
|
|
|
static __always_inline __pure bool use_eager_fpu(void)
|
|
|
|
{
|
2014-03-28 06:10:40 +08:00
|
|
|
return static_cpu_has_safe(X86_FEATURE_EAGER_FPU);
|
2012-09-07 05:58:52 +08:00
|
|
|
}
|
|
|
|
|
2012-02-22 05:19:22 +08:00
|
|
|
static __always_inline __pure bool use_xsaveopt(void)
|
|
|
|
{
|
2014-03-28 06:10:40 +08:00
|
|
|
return static_cpu_has_safe(X86_FEATURE_XSAVEOPT);
|
2012-02-22 05:19:22 +08:00
|
|
|
}
|
|
|
|
|
|
|
|
static __always_inline __pure bool use_xsave(void)
|
|
|
|
{
|
2014-03-28 06:10:40 +08:00
|
|
|
return static_cpu_has_safe(X86_FEATURE_XSAVE);
|
2012-02-22 05:19:22 +08:00
|
|
|
}
|
|
|
|
|
|
|
|
static __always_inline __pure bool use_fxsr(void)
|
|
|
|
{
|
2014-03-28 06:10:40 +08:00
|
|
|
return static_cpu_has_safe(X86_FEATURE_FXSR);
|
2012-02-22 05:19:22 +08:00
|
|
|
}
|
|
|
|
|
2015-04-28 17:25:02 +08:00
|
|
|
extern void fpstate_sanitize_xstate(struct fpu *fpu);
|
2012-02-22 05:19:22 +08:00
|
|
|
|
2012-09-22 08:18:44 +08:00
|
|
|
#define user_insn(insn, output, input...) \
|
|
|
|
({ \
|
|
|
|
int err; \
|
|
|
|
asm volatile(ASM_STAC "\n" \
|
|
|
|
"1:" #insn "\n\t" \
|
|
|
|
"2: " ASM_CLAC "\n" \
|
|
|
|
".section .fixup,\"ax\"\n" \
|
|
|
|
"3: movl $-1,%[err]\n" \
|
|
|
|
" jmp 2b\n" \
|
|
|
|
".previous\n" \
|
|
|
|
_ASM_EXTABLE(1b, 3b) \
|
|
|
|
: [err] "=r" (err), output \
|
|
|
|
: "0"(0), input); \
|
|
|
|
err; \
|
|
|
|
})
|
|
|
|
|
2012-07-25 07:05:28 +08:00
|
|
|
#define check_insn(insn, output, input...) \
|
|
|
|
({ \
|
|
|
|
int err; \
|
|
|
|
asm volatile("1:" #insn "\n\t" \
|
|
|
|
"2:\n" \
|
|
|
|
".section .fixup,\"ax\"\n" \
|
|
|
|
"3: movl $-1,%[err]\n" \
|
|
|
|
" jmp 2b\n" \
|
|
|
|
".previous\n" \
|
|
|
|
_ASM_EXTABLE(1b, 3b) \
|
|
|
|
: [err] "=r" (err), output \
|
|
|
|
: "0"(0), input); \
|
|
|
|
err; \
|
|
|
|
})
|
|
|
|
|
2015-04-30 23:15:32 +08:00
|
|
|
static inline int copy_fregs_to_user(struct fregs_state __user *fx)
|
2012-02-22 05:19:22 +08:00
|
|
|
{
|
2012-09-22 08:18:44 +08:00
|
|
|
return user_insn(fnsave %[fx]; fwait, [fx] "=m" (*fx), "m" (*fx));
|
2012-02-22 05:19:22 +08:00
|
|
|
}
|
|
|
|
|
2015-04-30 23:15:32 +08:00
|
|
|
static inline int copy_fxregs_to_user(struct fxregs_state __user *fx)
|
2012-02-22 05:19:22 +08:00
|
|
|
{
|
2012-07-25 07:05:28 +08:00
|
|
|
if (config_enabled(CONFIG_X86_32))
|
2012-09-22 08:18:44 +08:00
|
|
|
return user_insn(fxsave %[fx], [fx] "=m" (*fx), "m" (*fx));
|
2012-07-25 07:05:28 +08:00
|
|
|
else if (config_enabled(CONFIG_AS_FXSAVEQ))
|
2012-09-22 08:18:44 +08:00
|
|
|
return user_insn(fxsaveq %[fx], [fx] "=m" (*fx), "m" (*fx));
|
2012-02-22 05:19:22 +08:00
|
|
|
|
2015-04-30 17:34:09 +08:00
|
|
|
/* See comment in copy_fxregs_to_kernel() below. */
|
2012-09-22 08:18:44 +08:00
|
|
|
return user_insn(rex64/fxsave (%[fx]), "=m" (*fx), [fx] "R" (fx));
|
2012-02-22 05:19:22 +08:00
|
|
|
}
|
|
|
|
|
2015-04-30 23:15:32 +08:00
|
|
|
static inline int copy_kernel_to_fxregs(struct fxregs_state *fx)
|
2012-02-22 05:19:22 +08:00
|
|
|
{
|
2012-07-25 07:05:28 +08:00
|
|
|
if (config_enabled(CONFIG_X86_32))
|
|
|
|
return check_insn(fxrstor %[fx], "=m" (*fx), [fx] "m" (*fx));
|
|
|
|
else if (config_enabled(CONFIG_AS_FXSAVEQ))
|
|
|
|
return check_insn(fxrstorq %[fx], "=m" (*fx), [fx] "m" (*fx));
|
2012-02-22 05:19:22 +08:00
|
|
|
|
2015-04-30 17:34:09 +08:00
|
|
|
/* See comment in copy_fxregs_to_kernel() below. */
|
2012-07-25 07:05:28 +08:00
|
|
|
return check_insn(rex64/fxrstor (%[fx]), "=m" (*fx), [fx] "R" (fx),
|
|
|
|
"m" (*fx));
|
2012-02-22 05:19:22 +08:00
|
|
|
}
|
|
|
|
|
2015-04-30 23:15:32 +08:00
|
|
|
static inline int copy_user_to_fxregs(struct fxregs_state __user *fx)
|
2012-09-26 06:42:18 +08:00
|
|
|
{
|
|
|
|
if (config_enabled(CONFIG_X86_32))
|
|
|
|
return user_insn(fxrstor %[fx], "=m" (*fx), [fx] "m" (*fx));
|
|
|
|
else if (config_enabled(CONFIG_AS_FXSAVEQ))
|
|
|
|
return user_insn(fxrstorq %[fx], "=m" (*fx), [fx] "m" (*fx));
|
|
|
|
|
2015-04-30 17:34:09 +08:00
|
|
|
/* See comment in copy_fxregs_to_kernel() below. */
|
2012-09-26 06:42:18 +08:00
|
|
|
return user_insn(rex64/fxrstor (%[fx]), "=m" (*fx), [fx] "R" (fx),
|
|
|
|
"m" (*fx));
|
|
|
|
}
|
|
|
|
|
2015-04-30 23:15:32 +08:00
|
|
|
static inline int copy_kernel_to_fregs(struct fregs_state *fx)
|
2012-02-22 05:19:22 +08:00
|
|
|
{
|
2012-07-25 07:05:28 +08:00
|
|
|
return check_insn(frstor %[fx], "=m" (*fx), [fx] "m" (*fx));
|
2012-09-26 06:42:18 +08:00
|
|
|
}
|
|
|
|
|
2015-04-30 23:15:32 +08:00
|
|
|
static inline int copy_user_to_fregs(struct fregs_state __user *fx)
|
2012-09-26 06:42:18 +08:00
|
|
|
{
|
|
|
|
return user_insn(frstor %[fx], "=m" (*fx), [fx] "m" (*fx));
|
2012-02-22 05:19:22 +08:00
|
|
|
}
|
|
|
|
|
2015-04-30 17:34:09 +08:00
|
|
|
static inline void copy_fxregs_to_kernel(struct fpu *fpu)
|
2012-02-22 05:19:22 +08:00
|
|
|
{
|
2012-07-25 07:05:28 +08:00
|
|
|
if (config_enabled(CONFIG_X86_32))
|
x86/fpu: Simplify FPU handling by embedding the fpstate in task_struct (again)
So 6 years ago we made the FPU fpstate dynamically allocated:
aa283f49276e ("x86, fpu: lazy allocation of FPU area - v5")
61c4628b5386 ("x86, fpu: split FPU state from task struct - v5")
In hindsight this was a mistake:
- it complicated context allocation failure handling, such as:
/* kthread execs. TODO: cleanup this horror. */
if (WARN_ON(fpstate_alloc_init(fpu)))
force_sig(SIGKILL, tsk);
- it caused us to enable irqs in fpu__restore():
local_irq_enable();
/*
* does a slab alloc which can sleep
*/
if (fpstate_alloc_init(fpu)) {
/*
* ran out of memory!
*/
do_group_exit(SIGKILL);
return;
}
local_irq_disable();
- it (slightly) slowed down task creation/destruction by adding
slab allocation/free pattens.
- it made access to context contents (slightly) slower by adding
one more pointer dereference.
The motivation for the dynamic allocation was two-fold:
- reduce memory consumption by non-FPU tasks
- allocate and handle only the necessary amount of context for
various XSAVE processors that have varying hardware frame
sizes.
These days, with glibc using SSE memcpy by default and GCC optimizing
for SSE/AVX by default, the scope of FPU using apps on an x86 system is
much larger than it was 6 years ago.
For example on a freshly installed Fedora 21 desktop system, with a
recent kernel, all non-kthread tasks have used the FPU shortly after
bootup.
Also, even modern embedded x86 CPUs try to support the latest vector
instruction set - so they'll too often use the larger xstate frame
sizes.
So remove the dynamic allocation complication by embedding the FPU
fpstate in task_struct again. This should make the FPU a lot more
accessible to all sorts of atomic contexts.
We could still optimize for the xstate frame size in the future,
by moving the state structure to the last element of task_struct,
and allocating only a part of that.
This change is kept minimal by still keeping the ctx_alloc()/free()
routines (that now do nothing substantial) - we'll remove them in
the following patches.
Reviewed-by: Borislav Petkov <bp@alien8.de>
Cc: Andy Lutomirski <luto@amacapital.net>
Cc: Dave Hansen <dave.hansen@linux.intel.com>
Cc: Fenghua Yu <fenghua.yu@intel.com>
Cc: H. Peter Anvin <hpa@zytor.com>
Cc: Linus Torvalds <torvalds@linux-foundation.org>
Cc: Oleg Nesterov <oleg@redhat.com>
Cc: Peter Zijlstra <peterz@infradead.org>
Cc: Thomas Gleixner <tglx@linutronix.de>
Signed-off-by: Ingo Molnar <mingo@kernel.org>
2015-04-27 10:19:39 +08:00
|
|
|
asm volatile( "fxsave %[fx]" : [fx] "=m" (fpu->state.fxsave));
|
2012-07-25 07:05:28 +08:00
|
|
|
else if (config_enabled(CONFIG_AS_FXSAVEQ))
|
x86/fpu: Simplify FPU handling by embedding the fpstate in task_struct (again)
So 6 years ago we made the FPU fpstate dynamically allocated:
aa283f49276e ("x86, fpu: lazy allocation of FPU area - v5")
61c4628b5386 ("x86, fpu: split FPU state from task struct - v5")
In hindsight this was a mistake:
- it complicated context allocation failure handling, such as:
/* kthread execs. TODO: cleanup this horror. */
if (WARN_ON(fpstate_alloc_init(fpu)))
force_sig(SIGKILL, tsk);
- it caused us to enable irqs in fpu__restore():
local_irq_enable();
/*
* does a slab alloc which can sleep
*/
if (fpstate_alloc_init(fpu)) {
/*
* ran out of memory!
*/
do_group_exit(SIGKILL);
return;
}
local_irq_disable();
- it (slightly) slowed down task creation/destruction by adding
slab allocation/free pattens.
- it made access to context contents (slightly) slower by adding
one more pointer dereference.
The motivation for the dynamic allocation was two-fold:
- reduce memory consumption by non-FPU tasks
- allocate and handle only the necessary amount of context for
various XSAVE processors that have varying hardware frame
sizes.
These days, with glibc using SSE memcpy by default and GCC optimizing
for SSE/AVX by default, the scope of FPU using apps on an x86 system is
much larger than it was 6 years ago.
For example on a freshly installed Fedora 21 desktop system, with a
recent kernel, all non-kthread tasks have used the FPU shortly after
bootup.
Also, even modern embedded x86 CPUs try to support the latest vector
instruction set - so they'll too often use the larger xstate frame
sizes.
So remove the dynamic allocation complication by embedding the FPU
fpstate in task_struct again. This should make the FPU a lot more
accessible to all sorts of atomic contexts.
We could still optimize for the xstate frame size in the future,
by moving the state structure to the last element of task_struct,
and allocating only a part of that.
This change is kept minimal by still keeping the ctx_alloc()/free()
routines (that now do nothing substantial) - we'll remove them in
the following patches.
Reviewed-by: Borislav Petkov <bp@alien8.de>
Cc: Andy Lutomirski <luto@amacapital.net>
Cc: Dave Hansen <dave.hansen@linux.intel.com>
Cc: Fenghua Yu <fenghua.yu@intel.com>
Cc: H. Peter Anvin <hpa@zytor.com>
Cc: Linus Torvalds <torvalds@linux-foundation.org>
Cc: Oleg Nesterov <oleg@redhat.com>
Cc: Peter Zijlstra <peterz@infradead.org>
Cc: Thomas Gleixner <tglx@linutronix.de>
Signed-off-by: Ingo Molnar <mingo@kernel.org>
2015-04-27 10:19:39 +08:00
|
|
|
asm volatile("fxsaveq %[fx]" : [fx] "=m" (fpu->state.fxsave));
|
2012-07-25 07:05:28 +08:00
|
|
|
else {
|
|
|
|
/* Using "rex64; fxsave %0" is broken because, if the memory
|
|
|
|
* operand uses any extended registers for addressing, a second
|
|
|
|
* REX prefix will be generated (to the assembler, rex64
|
|
|
|
* followed by semicolon is a separate instruction), and hence
|
|
|
|
* the 64-bitness is lost.
|
|
|
|
*
|
|
|
|
* Using "fxsaveq %0" would be the ideal choice, but is only
|
|
|
|
* supported starting with gas 2.16.
|
|
|
|
*
|
|
|
|
* Using, as a workaround, the properly prefixed form below
|
|
|
|
* isn't accepted by any binutils version so far released,
|
|
|
|
* complaining that the same type of prefix is used twice if
|
|
|
|
* an extended register is needed for addressing (fix submitted
|
|
|
|
* to mainline 2005-11-21).
|
|
|
|
*
|
x86/fpu: Simplify FPU handling by embedding the fpstate in task_struct (again)
So 6 years ago we made the FPU fpstate dynamically allocated:
aa283f49276e ("x86, fpu: lazy allocation of FPU area - v5")
61c4628b5386 ("x86, fpu: split FPU state from task struct - v5")
In hindsight this was a mistake:
- it complicated context allocation failure handling, such as:
/* kthread execs. TODO: cleanup this horror. */
if (WARN_ON(fpstate_alloc_init(fpu)))
force_sig(SIGKILL, tsk);
- it caused us to enable irqs in fpu__restore():
local_irq_enable();
/*
* does a slab alloc which can sleep
*/
if (fpstate_alloc_init(fpu)) {
/*
* ran out of memory!
*/
do_group_exit(SIGKILL);
return;
}
local_irq_disable();
- it (slightly) slowed down task creation/destruction by adding
slab allocation/free pattens.
- it made access to context contents (slightly) slower by adding
one more pointer dereference.
The motivation for the dynamic allocation was two-fold:
- reduce memory consumption by non-FPU tasks
- allocate and handle only the necessary amount of context for
various XSAVE processors that have varying hardware frame
sizes.
These days, with glibc using SSE memcpy by default and GCC optimizing
for SSE/AVX by default, the scope of FPU using apps on an x86 system is
much larger than it was 6 years ago.
For example on a freshly installed Fedora 21 desktop system, with a
recent kernel, all non-kthread tasks have used the FPU shortly after
bootup.
Also, even modern embedded x86 CPUs try to support the latest vector
instruction set - so they'll too often use the larger xstate frame
sizes.
So remove the dynamic allocation complication by embedding the FPU
fpstate in task_struct again. This should make the FPU a lot more
accessible to all sorts of atomic contexts.
We could still optimize for the xstate frame size in the future,
by moving the state structure to the last element of task_struct,
and allocating only a part of that.
This change is kept minimal by still keeping the ctx_alloc()/free()
routines (that now do nothing substantial) - we'll remove them in
the following patches.
Reviewed-by: Borislav Petkov <bp@alien8.de>
Cc: Andy Lutomirski <luto@amacapital.net>
Cc: Dave Hansen <dave.hansen@linux.intel.com>
Cc: Fenghua Yu <fenghua.yu@intel.com>
Cc: H. Peter Anvin <hpa@zytor.com>
Cc: Linus Torvalds <torvalds@linux-foundation.org>
Cc: Oleg Nesterov <oleg@redhat.com>
Cc: Peter Zijlstra <peterz@infradead.org>
Cc: Thomas Gleixner <tglx@linutronix.de>
Signed-off-by: Ingo Molnar <mingo@kernel.org>
2015-04-27 10:19:39 +08:00
|
|
|
* asm volatile("rex64/fxsave %0" : "=m" (fpu->state.fxsave));
|
2012-07-25 07:05:28 +08:00
|
|
|
*
|
|
|
|
* This, however, we can work around by forcing the compiler to
|
|
|
|
* select an addressing mode that doesn't require extended
|
|
|
|
* registers.
|
|
|
|
*/
|
|
|
|
asm volatile( "rex64/fxsave (%[fx])"
|
x86/fpu: Simplify FPU handling by embedding the fpstate in task_struct (again)
So 6 years ago we made the FPU fpstate dynamically allocated:
aa283f49276e ("x86, fpu: lazy allocation of FPU area - v5")
61c4628b5386 ("x86, fpu: split FPU state from task struct - v5")
In hindsight this was a mistake:
- it complicated context allocation failure handling, such as:
/* kthread execs. TODO: cleanup this horror. */
if (WARN_ON(fpstate_alloc_init(fpu)))
force_sig(SIGKILL, tsk);
- it caused us to enable irqs in fpu__restore():
local_irq_enable();
/*
* does a slab alloc which can sleep
*/
if (fpstate_alloc_init(fpu)) {
/*
* ran out of memory!
*/
do_group_exit(SIGKILL);
return;
}
local_irq_disable();
- it (slightly) slowed down task creation/destruction by adding
slab allocation/free pattens.
- it made access to context contents (slightly) slower by adding
one more pointer dereference.
The motivation for the dynamic allocation was two-fold:
- reduce memory consumption by non-FPU tasks
- allocate and handle only the necessary amount of context for
various XSAVE processors that have varying hardware frame
sizes.
These days, with glibc using SSE memcpy by default and GCC optimizing
for SSE/AVX by default, the scope of FPU using apps on an x86 system is
much larger than it was 6 years ago.
For example on a freshly installed Fedora 21 desktop system, with a
recent kernel, all non-kthread tasks have used the FPU shortly after
bootup.
Also, even modern embedded x86 CPUs try to support the latest vector
instruction set - so they'll too often use the larger xstate frame
sizes.
So remove the dynamic allocation complication by embedding the FPU
fpstate in task_struct again. This should make the FPU a lot more
accessible to all sorts of atomic contexts.
We could still optimize for the xstate frame size in the future,
by moving the state structure to the last element of task_struct,
and allocating only a part of that.
This change is kept minimal by still keeping the ctx_alloc()/free()
routines (that now do nothing substantial) - we'll remove them in
the following patches.
Reviewed-by: Borislav Petkov <bp@alien8.de>
Cc: Andy Lutomirski <luto@amacapital.net>
Cc: Dave Hansen <dave.hansen@linux.intel.com>
Cc: Fenghua Yu <fenghua.yu@intel.com>
Cc: H. Peter Anvin <hpa@zytor.com>
Cc: Linus Torvalds <torvalds@linux-foundation.org>
Cc: Oleg Nesterov <oleg@redhat.com>
Cc: Peter Zijlstra <peterz@infradead.org>
Cc: Thomas Gleixner <tglx@linutronix.de>
Signed-off-by: Ingo Molnar <mingo@kernel.org>
2015-04-27 10:19:39 +08:00
|
|
|
: "=m" (fpu->state.fxsave)
|
|
|
|
: [fx] "R" (&fpu->state.fxsave));
|
2012-07-25 07:05:28 +08:00
|
|
|
}
|
2012-02-22 05:19:22 +08:00
|
|
|
}
|
|
|
|
|
|
|
|
/*
|
|
|
|
* These must be called with preempt disabled. Returns
|
x86/fpu: Rename fpu_save_init() to copy_fpregs_to_fpstate()
So fpu_save_init() is a historic name that got its name when the only
way the FPU state was FNSAVE, which cleared (well, destroyed) the FPU
state after saving it.
Nowadays the name is misleading, because ever since the introduction of
FXSAVE (and more modern FPU saving instructions) the 'we need to reload
the FPU state' part is only true if there's a pending FPU exception [*],
which is almost never the case.
So rename it to copy_fpregs_to_fpstate() to make it clear what's
happening. Also add a few comments about why we cannot keep registers
in certain cases.
Also clean up the control flow a bit, to make it more apparent when
we are dropping/keeping FP registers, and to optimize the common
case (of keeping fpregs) some more.
[*] Probably not true anymore, modern instructions always leave the FPU
state intact, even if exceptions are pending: because pending FP
exceptions are posted on the next FP instruction, not asynchronously.
They were truly asynchronous back in the IRQ13 case, and we had to
synchronize with them, but that code is not working anymore: we don't
have IRQ13 mapped in the IDT anymore.
But a cleanup patch is obviously not the place to change subtle behavior.
Reviewed-by: Borislav Petkov <bp@alien8.de>
Cc: Andy Lutomirski <luto@amacapital.net>
Cc: Dave Hansen <dave.hansen@linux.intel.com>
Cc: Fenghua Yu <fenghua.yu@intel.com>
Cc: H. Peter Anvin <hpa@zytor.com>
Cc: Linus Torvalds <torvalds@linux-foundation.org>
Cc: Oleg Nesterov <oleg@redhat.com>
Cc: Peter Zijlstra <peterz@infradead.org>
Cc: Thomas Gleixner <tglx@linutronix.de>
Signed-off-by: Ingo Molnar <mingo@kernel.org>
2015-04-27 08:53:16 +08:00
|
|
|
* 'true' if the FPU state is still intact and we can
|
|
|
|
* keep registers active.
|
|
|
|
*
|
|
|
|
* The legacy FNSAVE instruction cleared all FPU state
|
|
|
|
* unconditionally, so registers are essentially destroyed.
|
|
|
|
* Modern FPU state can be kept in registers, if there are
|
x86/fpu: Optimize copy_fpregs_to_fpstate() by removing the FNCLEX synchronization with FP exceptions
So we have the following ancient code in copy_fpregs_to_fpstate():
if (unlikely(fpu->state->fxsave.swd & X87_FSW_ES)) {
asm volatile("fnclex");
goto drop_fpregs;
}
which clears pending FPU exceptions and then drops registers, which
causes the next FP instruction of the saved context to re-load the
saved FPU state, with all pending exceptions marked properly, and
will re-start the exception handling mechanism in the hardware.
Since FPU exceptions are always issued on instruction boundaries,
in particular on the next FP instruction following the exception
generating instruction, there's no fear of getting an FP exception
asynchronously.
They were truly asynchronous back in the IRQ13 days, when the FPU was
a weird and expensive co-processor that did its own processing, and we
had to synchronize with them, but that code is not working anymore:
we don't have IRQ13 mapped in the IDT anymore.
With the introduction of optimized XSAVE support there's a new
complication: if the xstate features bit indicates that a particular
state component is unused (in 'init state'), then the hardware does
not guarantee that the XSAVE (et al) instruction keeps the underlying
FPU state image in memory valid and current. In practice this means
that the hardware won't write it, and the exceptions flag in the
state might be an older version, with it still being set. This
meant that we had to check the xfeatures flag as well, adding
another memory load and branch to a critical hot path of the scheduler.
So optimize all this by removing both the old quirk and the new check,
and straight-line optimizing the most common cases with likely()
hints. Quite a bit of code gets removed this way:
arch/x86/kernel/process_64.o:
text data bss dec filename
5484 8 0 5492 process_64.o.before
5416 8 0 5424 process_64.o.after
Now there's also a chance that some weird behavior or erratum was
masked by our IRQ13 handling quirk (or that I misunderstood the
nature of the quirk), and that this change triggers some badness.
There's no real good way to protect against that possibility other
than keeping this change well isolated, well commented and well
bisectable. If you bisect a weird (or not so weird) breakage to
this commit then please let us know!
Reviewed-by: Borislav Petkov <bp@alien8.de>
Cc: Andy Lutomirski <luto@amacapital.net>
Cc: Dave Hansen <dave.hansen@linux.intel.com>
Cc: Fenghua Yu <fenghua.yu@intel.com>
Cc: H. Peter Anvin <hpa@zytor.com>
Cc: Linus Torvalds <torvalds@linux-foundation.org>
Cc: Oleg Nesterov <oleg@redhat.com>
Cc: Peter Zijlstra <peterz@infradead.org>
Cc: Thomas Gleixner <tglx@linutronix.de>
Signed-off-by: Ingo Molnar <mingo@kernel.org>
2015-04-27 09:32:18 +08:00
|
|
|
* no pending FP exceptions.
|
2012-02-22 05:19:22 +08:00
|
|
|
*/
|
x86/fpu: Rename fpu_save_init() to copy_fpregs_to_fpstate()
So fpu_save_init() is a historic name that got its name when the only
way the FPU state was FNSAVE, which cleared (well, destroyed) the FPU
state after saving it.
Nowadays the name is misleading, because ever since the introduction of
FXSAVE (and more modern FPU saving instructions) the 'we need to reload
the FPU state' part is only true if there's a pending FPU exception [*],
which is almost never the case.
So rename it to copy_fpregs_to_fpstate() to make it clear what's
happening. Also add a few comments about why we cannot keep registers
in certain cases.
Also clean up the control flow a bit, to make it more apparent when
we are dropping/keeping FP registers, and to optimize the common
case (of keeping fpregs) some more.
[*] Probably not true anymore, modern instructions always leave the FPU
state intact, even if exceptions are pending: because pending FP
exceptions are posted on the next FP instruction, not asynchronously.
They were truly asynchronous back in the IRQ13 case, and we had to
synchronize with them, but that code is not working anymore: we don't
have IRQ13 mapped in the IDT anymore.
But a cleanup patch is obviously not the place to change subtle behavior.
Reviewed-by: Borislav Petkov <bp@alien8.de>
Cc: Andy Lutomirski <luto@amacapital.net>
Cc: Dave Hansen <dave.hansen@linux.intel.com>
Cc: Fenghua Yu <fenghua.yu@intel.com>
Cc: H. Peter Anvin <hpa@zytor.com>
Cc: Linus Torvalds <torvalds@linux-foundation.org>
Cc: Oleg Nesterov <oleg@redhat.com>
Cc: Peter Zijlstra <peterz@infradead.org>
Cc: Thomas Gleixner <tglx@linutronix.de>
Signed-off-by: Ingo Molnar <mingo@kernel.org>
2015-04-27 08:53:16 +08:00
|
|
|
static inline int copy_fpregs_to_fpstate(struct fpu *fpu)
|
2012-02-22 05:19:22 +08:00
|
|
|
{
|
x86/fpu: Optimize copy_fpregs_to_fpstate() by removing the FNCLEX synchronization with FP exceptions
So we have the following ancient code in copy_fpregs_to_fpstate():
if (unlikely(fpu->state->fxsave.swd & X87_FSW_ES)) {
asm volatile("fnclex");
goto drop_fpregs;
}
which clears pending FPU exceptions and then drops registers, which
causes the next FP instruction of the saved context to re-load the
saved FPU state, with all pending exceptions marked properly, and
will re-start the exception handling mechanism in the hardware.
Since FPU exceptions are always issued on instruction boundaries,
in particular on the next FP instruction following the exception
generating instruction, there's no fear of getting an FP exception
asynchronously.
They were truly asynchronous back in the IRQ13 days, when the FPU was
a weird and expensive co-processor that did its own processing, and we
had to synchronize with them, but that code is not working anymore:
we don't have IRQ13 mapped in the IDT anymore.
With the introduction of optimized XSAVE support there's a new
complication: if the xstate features bit indicates that a particular
state component is unused (in 'init state'), then the hardware does
not guarantee that the XSAVE (et al) instruction keeps the underlying
FPU state image in memory valid and current. In practice this means
that the hardware won't write it, and the exceptions flag in the
state might be an older version, with it still being set. This
meant that we had to check the xfeatures flag as well, adding
another memory load and branch to a critical hot path of the scheduler.
So optimize all this by removing both the old quirk and the new check,
and straight-line optimizing the most common cases with likely()
hints. Quite a bit of code gets removed this way:
arch/x86/kernel/process_64.o:
text data bss dec filename
5484 8 0 5492 process_64.o.before
5416 8 0 5424 process_64.o.after
Now there's also a chance that some weird behavior or erratum was
masked by our IRQ13 handling quirk (or that I misunderstood the
nature of the quirk), and that this change triggers some badness.
There's no real good way to protect against that possibility other
than keeping this change well isolated, well commented and well
bisectable. If you bisect a weird (or not so weird) breakage to
this commit then please let us know!
Reviewed-by: Borislav Petkov <bp@alien8.de>
Cc: Andy Lutomirski <luto@amacapital.net>
Cc: Dave Hansen <dave.hansen@linux.intel.com>
Cc: Fenghua Yu <fenghua.yu@intel.com>
Cc: H. Peter Anvin <hpa@zytor.com>
Cc: Linus Torvalds <torvalds@linux-foundation.org>
Cc: Oleg Nesterov <oleg@redhat.com>
Cc: Peter Zijlstra <peterz@infradead.org>
Cc: Thomas Gleixner <tglx@linutronix.de>
Signed-off-by: Ingo Molnar <mingo@kernel.org>
2015-04-27 09:32:18 +08:00
|
|
|
if (likely(use_xsave())) {
|
2015-04-30 17:34:09 +08:00
|
|
|
copy_xregs_to_kernel(&fpu->state.xsave);
|
x86/fpu: Optimize copy_fpregs_to_fpstate() by removing the FNCLEX synchronization with FP exceptions
So we have the following ancient code in copy_fpregs_to_fpstate():
if (unlikely(fpu->state->fxsave.swd & X87_FSW_ES)) {
asm volatile("fnclex");
goto drop_fpregs;
}
which clears pending FPU exceptions and then drops registers, which
causes the next FP instruction of the saved context to re-load the
saved FPU state, with all pending exceptions marked properly, and
will re-start the exception handling mechanism in the hardware.
Since FPU exceptions are always issued on instruction boundaries,
in particular on the next FP instruction following the exception
generating instruction, there's no fear of getting an FP exception
asynchronously.
They were truly asynchronous back in the IRQ13 days, when the FPU was
a weird and expensive co-processor that did its own processing, and we
had to synchronize with them, but that code is not working anymore:
we don't have IRQ13 mapped in the IDT anymore.
With the introduction of optimized XSAVE support there's a new
complication: if the xstate features bit indicates that a particular
state component is unused (in 'init state'), then the hardware does
not guarantee that the XSAVE (et al) instruction keeps the underlying
FPU state image in memory valid and current. In practice this means
that the hardware won't write it, and the exceptions flag in the
state might be an older version, with it still being set. This
meant that we had to check the xfeatures flag as well, adding
another memory load and branch to a critical hot path of the scheduler.
So optimize all this by removing both the old quirk and the new check,
and straight-line optimizing the most common cases with likely()
hints. Quite a bit of code gets removed this way:
arch/x86/kernel/process_64.o:
text data bss dec filename
5484 8 0 5492 process_64.o.before
5416 8 0 5424 process_64.o.after
Now there's also a chance that some weird behavior or erratum was
masked by our IRQ13 handling quirk (or that I misunderstood the
nature of the quirk), and that this change triggers some badness.
There's no real good way to protect against that possibility other
than keeping this change well isolated, well commented and well
bisectable. If you bisect a weird (or not so weird) breakage to
this commit then please let us know!
Reviewed-by: Borislav Petkov <bp@alien8.de>
Cc: Andy Lutomirski <luto@amacapital.net>
Cc: Dave Hansen <dave.hansen@linux.intel.com>
Cc: Fenghua Yu <fenghua.yu@intel.com>
Cc: H. Peter Anvin <hpa@zytor.com>
Cc: Linus Torvalds <torvalds@linux-foundation.org>
Cc: Oleg Nesterov <oleg@redhat.com>
Cc: Peter Zijlstra <peterz@infradead.org>
Cc: Thomas Gleixner <tglx@linutronix.de>
Signed-off-by: Ingo Molnar <mingo@kernel.org>
2015-04-27 09:32:18 +08:00
|
|
|
return 1;
|
|
|
|
}
|
2012-02-22 05:19:22 +08:00
|
|
|
|
x86/fpu: Optimize copy_fpregs_to_fpstate() by removing the FNCLEX synchronization with FP exceptions
So we have the following ancient code in copy_fpregs_to_fpstate():
if (unlikely(fpu->state->fxsave.swd & X87_FSW_ES)) {
asm volatile("fnclex");
goto drop_fpregs;
}
which clears pending FPU exceptions and then drops registers, which
causes the next FP instruction of the saved context to re-load the
saved FPU state, with all pending exceptions marked properly, and
will re-start the exception handling mechanism in the hardware.
Since FPU exceptions are always issued on instruction boundaries,
in particular on the next FP instruction following the exception
generating instruction, there's no fear of getting an FP exception
asynchronously.
They were truly asynchronous back in the IRQ13 days, when the FPU was
a weird and expensive co-processor that did its own processing, and we
had to synchronize with them, but that code is not working anymore:
we don't have IRQ13 mapped in the IDT anymore.
With the introduction of optimized XSAVE support there's a new
complication: if the xstate features bit indicates that a particular
state component is unused (in 'init state'), then the hardware does
not guarantee that the XSAVE (et al) instruction keeps the underlying
FPU state image in memory valid and current. In practice this means
that the hardware won't write it, and the exceptions flag in the
state might be an older version, with it still being set. This
meant that we had to check the xfeatures flag as well, adding
another memory load and branch to a critical hot path of the scheduler.
So optimize all this by removing both the old quirk and the new check,
and straight-line optimizing the most common cases with likely()
hints. Quite a bit of code gets removed this way:
arch/x86/kernel/process_64.o:
text data bss dec filename
5484 8 0 5492 process_64.o.before
5416 8 0 5424 process_64.o.after
Now there's also a chance that some weird behavior or erratum was
masked by our IRQ13 handling quirk (or that I misunderstood the
nature of the quirk), and that this change triggers some badness.
There's no real good way to protect against that possibility other
than keeping this change well isolated, well commented and well
bisectable. If you bisect a weird (or not so weird) breakage to
this commit then please let us know!
Reviewed-by: Borislav Petkov <bp@alien8.de>
Cc: Andy Lutomirski <luto@amacapital.net>
Cc: Dave Hansen <dave.hansen@linux.intel.com>
Cc: Fenghua Yu <fenghua.yu@intel.com>
Cc: H. Peter Anvin <hpa@zytor.com>
Cc: Linus Torvalds <torvalds@linux-foundation.org>
Cc: Oleg Nesterov <oleg@redhat.com>
Cc: Peter Zijlstra <peterz@infradead.org>
Cc: Thomas Gleixner <tglx@linutronix.de>
Signed-off-by: Ingo Molnar <mingo@kernel.org>
2015-04-27 09:32:18 +08:00
|
|
|
if (likely(use_fxsr())) {
|
2015-04-30 17:34:09 +08:00
|
|
|
copy_fxregs_to_kernel(fpu);
|
x86/fpu: Optimize copy_fpregs_to_fpstate() by removing the FNCLEX synchronization with FP exceptions
So we have the following ancient code in copy_fpregs_to_fpstate():
if (unlikely(fpu->state->fxsave.swd & X87_FSW_ES)) {
asm volatile("fnclex");
goto drop_fpregs;
}
which clears pending FPU exceptions and then drops registers, which
causes the next FP instruction of the saved context to re-load the
saved FPU state, with all pending exceptions marked properly, and
will re-start the exception handling mechanism in the hardware.
Since FPU exceptions are always issued on instruction boundaries,
in particular on the next FP instruction following the exception
generating instruction, there's no fear of getting an FP exception
asynchronously.
They were truly asynchronous back in the IRQ13 days, when the FPU was
a weird and expensive co-processor that did its own processing, and we
had to synchronize with them, but that code is not working anymore:
we don't have IRQ13 mapped in the IDT anymore.
With the introduction of optimized XSAVE support there's a new
complication: if the xstate features bit indicates that a particular
state component is unused (in 'init state'), then the hardware does
not guarantee that the XSAVE (et al) instruction keeps the underlying
FPU state image in memory valid and current. In practice this means
that the hardware won't write it, and the exceptions flag in the
state might be an older version, with it still being set. This
meant that we had to check the xfeatures flag as well, adding
another memory load and branch to a critical hot path of the scheduler.
So optimize all this by removing both the old quirk and the new check,
and straight-line optimizing the most common cases with likely()
hints. Quite a bit of code gets removed this way:
arch/x86/kernel/process_64.o:
text data bss dec filename
5484 8 0 5492 process_64.o.before
5416 8 0 5424 process_64.o.after
Now there's also a chance that some weird behavior or erratum was
masked by our IRQ13 handling quirk (or that I misunderstood the
nature of the quirk), and that this change triggers some badness.
There's no real good way to protect against that possibility other
than keeping this change well isolated, well commented and well
bisectable. If you bisect a weird (or not so weird) breakage to
this commit then please let us know!
Reviewed-by: Borislav Petkov <bp@alien8.de>
Cc: Andy Lutomirski <luto@amacapital.net>
Cc: Dave Hansen <dave.hansen@linux.intel.com>
Cc: Fenghua Yu <fenghua.yu@intel.com>
Cc: H. Peter Anvin <hpa@zytor.com>
Cc: Linus Torvalds <torvalds@linux-foundation.org>
Cc: Oleg Nesterov <oleg@redhat.com>
Cc: Peter Zijlstra <peterz@infradead.org>
Cc: Thomas Gleixner <tglx@linutronix.de>
Signed-off-by: Ingo Molnar <mingo@kernel.org>
2015-04-27 09:32:18 +08:00
|
|
|
return 1;
|
2012-02-22 05:19:22 +08:00
|
|
|
}
|
|
|
|
|
|
|
|
/*
|
x86/fpu: Optimize copy_fpregs_to_fpstate() by removing the FNCLEX synchronization with FP exceptions
So we have the following ancient code in copy_fpregs_to_fpstate():
if (unlikely(fpu->state->fxsave.swd & X87_FSW_ES)) {
asm volatile("fnclex");
goto drop_fpregs;
}
which clears pending FPU exceptions and then drops registers, which
causes the next FP instruction of the saved context to re-load the
saved FPU state, with all pending exceptions marked properly, and
will re-start the exception handling mechanism in the hardware.
Since FPU exceptions are always issued on instruction boundaries,
in particular on the next FP instruction following the exception
generating instruction, there's no fear of getting an FP exception
asynchronously.
They were truly asynchronous back in the IRQ13 days, when the FPU was
a weird and expensive co-processor that did its own processing, and we
had to synchronize with them, but that code is not working anymore:
we don't have IRQ13 mapped in the IDT anymore.
With the introduction of optimized XSAVE support there's a new
complication: if the xstate features bit indicates that a particular
state component is unused (in 'init state'), then the hardware does
not guarantee that the XSAVE (et al) instruction keeps the underlying
FPU state image in memory valid and current. In practice this means
that the hardware won't write it, and the exceptions flag in the
state might be an older version, with it still being set. This
meant that we had to check the xfeatures flag as well, adding
another memory load and branch to a critical hot path of the scheduler.
So optimize all this by removing both the old quirk and the new check,
and straight-line optimizing the most common cases with likely()
hints. Quite a bit of code gets removed this way:
arch/x86/kernel/process_64.o:
text data bss dec filename
5484 8 0 5492 process_64.o.before
5416 8 0 5424 process_64.o.after
Now there's also a chance that some weird behavior or erratum was
masked by our IRQ13 handling quirk (or that I misunderstood the
nature of the quirk), and that this change triggers some badness.
There's no real good way to protect against that possibility other
than keeping this change well isolated, well commented and well
bisectable. If you bisect a weird (or not so weird) breakage to
this commit then please let us know!
Reviewed-by: Borislav Petkov <bp@alien8.de>
Cc: Andy Lutomirski <luto@amacapital.net>
Cc: Dave Hansen <dave.hansen@linux.intel.com>
Cc: Fenghua Yu <fenghua.yu@intel.com>
Cc: H. Peter Anvin <hpa@zytor.com>
Cc: Linus Torvalds <torvalds@linux-foundation.org>
Cc: Oleg Nesterov <oleg@redhat.com>
Cc: Peter Zijlstra <peterz@infradead.org>
Cc: Thomas Gleixner <tglx@linutronix.de>
Signed-off-by: Ingo Molnar <mingo@kernel.org>
2015-04-27 09:32:18 +08:00
|
|
|
* Legacy FPU register saving, FNSAVE always clears FPU registers,
|
|
|
|
* so we have to mark them inactive:
|
2012-02-22 05:19:22 +08:00
|
|
|
*/
|
x86/fpu: Simplify FPU handling by embedding the fpstate in task_struct (again)
So 6 years ago we made the FPU fpstate dynamically allocated:
aa283f49276e ("x86, fpu: lazy allocation of FPU area - v5")
61c4628b5386 ("x86, fpu: split FPU state from task struct - v5")
In hindsight this was a mistake:
- it complicated context allocation failure handling, such as:
/* kthread execs. TODO: cleanup this horror. */
if (WARN_ON(fpstate_alloc_init(fpu)))
force_sig(SIGKILL, tsk);
- it caused us to enable irqs in fpu__restore():
local_irq_enable();
/*
* does a slab alloc which can sleep
*/
if (fpstate_alloc_init(fpu)) {
/*
* ran out of memory!
*/
do_group_exit(SIGKILL);
return;
}
local_irq_disable();
- it (slightly) slowed down task creation/destruction by adding
slab allocation/free pattens.
- it made access to context contents (slightly) slower by adding
one more pointer dereference.
The motivation for the dynamic allocation was two-fold:
- reduce memory consumption by non-FPU tasks
- allocate and handle only the necessary amount of context for
various XSAVE processors that have varying hardware frame
sizes.
These days, with glibc using SSE memcpy by default and GCC optimizing
for SSE/AVX by default, the scope of FPU using apps on an x86 system is
much larger than it was 6 years ago.
For example on a freshly installed Fedora 21 desktop system, with a
recent kernel, all non-kthread tasks have used the FPU shortly after
bootup.
Also, even modern embedded x86 CPUs try to support the latest vector
instruction set - so they'll too often use the larger xstate frame
sizes.
So remove the dynamic allocation complication by embedding the FPU
fpstate in task_struct again. This should make the FPU a lot more
accessible to all sorts of atomic contexts.
We could still optimize for the xstate frame size in the future,
by moving the state structure to the last element of task_struct,
and allocating only a part of that.
This change is kept minimal by still keeping the ctx_alloc()/free()
routines (that now do nothing substantial) - we'll remove them in
the following patches.
Reviewed-by: Borislav Petkov <bp@alien8.de>
Cc: Andy Lutomirski <luto@amacapital.net>
Cc: Dave Hansen <dave.hansen@linux.intel.com>
Cc: Fenghua Yu <fenghua.yu@intel.com>
Cc: H. Peter Anvin <hpa@zytor.com>
Cc: Linus Torvalds <torvalds@linux-foundation.org>
Cc: Oleg Nesterov <oleg@redhat.com>
Cc: Peter Zijlstra <peterz@infradead.org>
Cc: Thomas Gleixner <tglx@linutronix.de>
Signed-off-by: Ingo Molnar <mingo@kernel.org>
2015-04-27 10:19:39 +08:00
|
|
|
asm volatile("fnsave %[fx]; fwait" : [fx] "=m" (fpu->state.fsave));
|
x86/fpu: Rename fpu_save_init() to copy_fpregs_to_fpstate()
So fpu_save_init() is a historic name that got its name when the only
way the FPU state was FNSAVE, which cleared (well, destroyed) the FPU
state after saving it.
Nowadays the name is misleading, because ever since the introduction of
FXSAVE (and more modern FPU saving instructions) the 'we need to reload
the FPU state' part is only true if there's a pending FPU exception [*],
which is almost never the case.
So rename it to copy_fpregs_to_fpstate() to make it clear what's
happening. Also add a few comments about why we cannot keep registers
in certain cases.
Also clean up the control flow a bit, to make it more apparent when
we are dropping/keeping FP registers, and to optimize the common
case (of keeping fpregs) some more.
[*] Probably not true anymore, modern instructions always leave the FPU
state intact, even if exceptions are pending: because pending FP
exceptions are posted on the next FP instruction, not asynchronously.
They were truly asynchronous back in the IRQ13 case, and we had to
synchronize with them, but that code is not working anymore: we don't
have IRQ13 mapped in the IDT anymore.
But a cleanup patch is obviously not the place to change subtle behavior.
Reviewed-by: Borislav Petkov <bp@alien8.de>
Cc: Andy Lutomirski <luto@amacapital.net>
Cc: Dave Hansen <dave.hansen@linux.intel.com>
Cc: Fenghua Yu <fenghua.yu@intel.com>
Cc: H. Peter Anvin <hpa@zytor.com>
Cc: Linus Torvalds <torvalds@linux-foundation.org>
Cc: Oleg Nesterov <oleg@redhat.com>
Cc: Peter Zijlstra <peterz@infradead.org>
Cc: Thomas Gleixner <tglx@linutronix.de>
Signed-off-by: Ingo Molnar <mingo@kernel.org>
2015-04-27 08:53:16 +08:00
|
|
|
|
|
|
|
return 0;
|
2012-02-22 05:19:22 +08:00
|
|
|
}
|
|
|
|
|
2015-04-30 02:10:43 +08:00
|
|
|
static inline int __copy_fpstate_to_fpregs(struct fpu *fpu)
|
2012-02-22 05:19:22 +08:00
|
|
|
{
|
|
|
|
if (use_xsave())
|
2015-04-30 17:34:09 +08:00
|
|
|
return copy_kernel_to_xregs(&fpu->state.xsave, -1);
|
2012-07-25 07:05:28 +08:00
|
|
|
else if (use_fxsr())
|
2015-04-30 17:34:09 +08:00
|
|
|
return copy_kernel_to_fxregs(&fpu->state.fxsave);
|
2012-02-22 05:19:22 +08:00
|
|
|
else
|
2015-04-30 17:34:09 +08:00
|
|
|
return copy_kernel_to_fregs(&fpu->state.fsave);
|
2012-02-22 05:19:22 +08:00
|
|
|
}
|
|
|
|
|
2015-04-30 02:10:43 +08:00
|
|
|
static inline int copy_fpstate_to_fpregs(struct fpu *fpu)
|
2012-02-22 05:19:22 +08:00
|
|
|
{
|
2014-12-21 22:02:23 +08:00
|
|
|
/*
|
|
|
|
* AMD K7/K8 CPUs don't save/restore FDP/FIP/FOP unless an exception is
|
|
|
|
* pending. Clear the x87 state here by setting it to fixed values.
|
|
|
|
* "m" is a random variable that should be in L1.
|
|
|
|
*/
|
2014-06-18 06:06:23 +08:00
|
|
|
if (unlikely(static_cpu_has_bug_safe(X86_BUG_FXSAVE_LEAK))) {
|
2014-01-12 11:15:52 +08:00
|
|
|
asm volatile(
|
|
|
|
"fnclex\n\t"
|
|
|
|
"emms\n\t"
|
|
|
|
"fildl %P[addr]" /* set F?P to defined value */
|
2015-04-24 20:19:26 +08:00
|
|
|
: : [addr] "m" (fpu->fpregs_active));
|
2014-01-12 11:15:52 +08:00
|
|
|
}
|
2012-02-22 05:19:22 +08:00
|
|
|
|
2015-04-30 02:10:43 +08:00
|
|
|
return __copy_fpstate_to_fpregs(fpu);
|
2012-02-22 05:19:22 +08:00
|
|
|
}
|
|
|
|
|
2015-04-27 14:58:45 +08:00
|
|
|
/*
|
|
|
|
* Wrap lazy FPU TS handling in a 'hw fpregs activation/deactivation'
|
|
|
|
* idiom, which is then paired with the sw-flag (fpregs_active) later on:
|
|
|
|
*/
|
|
|
|
|
|
|
|
static inline void __fpregs_activate_hw(void)
|
|
|
|
{
|
|
|
|
if (!use_eager_fpu())
|
|
|
|
clts();
|
|
|
|
}
|
|
|
|
|
|
|
|
static inline void __fpregs_deactivate_hw(void)
|
|
|
|
{
|
|
|
|
if (!use_eager_fpu())
|
|
|
|
stts();
|
|
|
|
}
|
|
|
|
|
|
|
|
/* Must be paired with an 'stts' (fpregs_deactivate_hw()) after! */
|
2015-04-24 20:28:01 +08:00
|
|
|
static inline void __fpregs_deactivate(struct fpu *fpu)
|
2012-02-22 05:19:22 +08:00
|
|
|
{
|
2015-05-05 17:34:49 +08:00
|
|
|
WARN_ON_FPU(!fpu->fpregs_active);
|
|
|
|
|
2015-04-24 20:19:26 +08:00
|
|
|
fpu->fpregs_active = 0;
|
2015-04-23 18:18:28 +08:00
|
|
|
this_cpu_write(fpu_fpregs_owner_ctx, NULL);
|
2012-02-22 05:19:22 +08:00
|
|
|
}
|
|
|
|
|
2015-04-27 14:58:45 +08:00
|
|
|
/* Must be paired with a 'clts' (fpregs_activate_hw()) before! */
|
2015-04-24 20:26:47 +08:00
|
|
|
static inline void __fpregs_activate(struct fpu *fpu)
|
2012-02-22 05:19:22 +08:00
|
|
|
{
|
2015-05-05 17:34:49 +08:00
|
|
|
WARN_ON_FPU(fpu->fpregs_active);
|
|
|
|
|
2015-04-24 20:19:26 +08:00
|
|
|
fpu->fpregs_active = 1;
|
2015-04-23 18:24:59 +08:00
|
|
|
this_cpu_write(fpu_fpregs_owner_ctx, fpu);
|
2012-02-22 05:19:22 +08:00
|
|
|
}
|
|
|
|
|
2015-04-26 22:56:05 +08:00
|
|
|
/*
|
|
|
|
* The question "does this thread have fpu access?"
|
|
|
|
* is slightly racy, since preemption could come in
|
|
|
|
* and revoke it immediately after the test.
|
|
|
|
*
|
|
|
|
* However, even in that very unlikely scenario,
|
|
|
|
* we can just assume we have FPU access - typically
|
|
|
|
* to save the FP state - we'll just take a #NM
|
|
|
|
* fault and get the FPU access back.
|
|
|
|
*/
|
2015-04-28 18:28:08 +08:00
|
|
|
static inline int fpregs_active(void)
|
2015-04-26 22:56:05 +08:00
|
|
|
{
|
|
|
|
return current->thread.fpu.fpregs_active;
|
|
|
|
}
|
|
|
|
|
2012-02-22 05:19:22 +08:00
|
|
|
/*
|
|
|
|
* Encapsulate the CR0.TS handling together with the
|
|
|
|
* software flag.
|
|
|
|
*
|
|
|
|
* These generally need preemption protection to work,
|
|
|
|
* do try to avoid using these on their own.
|
|
|
|
*/
|
2015-04-24 20:31:27 +08:00
|
|
|
static inline void fpregs_activate(struct fpu *fpu)
|
2012-02-22 05:19:22 +08:00
|
|
|
{
|
2015-04-27 14:58:45 +08:00
|
|
|
__fpregs_activate_hw();
|
2015-04-24 20:31:27 +08:00
|
|
|
__fpregs_activate(fpu);
|
2012-02-22 05:19:22 +08:00
|
|
|
}
|
|
|
|
|
2015-04-24 20:31:27 +08:00
|
|
|
static inline void fpregs_deactivate(struct fpu *fpu)
|
2012-02-22 05:19:22 +08:00
|
|
|
{
|
2015-04-24 20:31:27 +08:00
|
|
|
__fpregs_deactivate(fpu);
|
2015-04-27 14:58:45 +08:00
|
|
|
__fpregs_deactivate_hw();
|
2012-02-22 05:19:22 +08:00
|
|
|
}
|
|
|
|
|
2015-04-28 16:56:54 +08:00
|
|
|
/*
|
|
|
|
* Definitions for the eXtended Control Register instructions
|
|
|
|
*/
|
|
|
|
|
|
|
|
#define XCR_XFEATURE_ENABLED_MASK 0x00000000
|
|
|
|
|
|
|
|
static inline u64 xgetbv(u32 index)
|
|
|
|
{
|
|
|
|
u32 eax, edx;
|
|
|
|
|
|
|
|
asm volatile(".byte 0x0f,0x01,0xd0" /* xgetbv */
|
|
|
|
: "=a" (eax), "=d" (edx)
|
|
|
|
: "c" (index));
|
|
|
|
return eax + ((u64)edx << 32);
|
|
|
|
}
|
|
|
|
|
|
|
|
static inline void xsetbv(u32 index, u64 value)
|
|
|
|
{
|
|
|
|
u32 eax = value;
|
|
|
|
u32 edx = value >> 32;
|
|
|
|
|
|
|
|
asm volatile(".byte 0x0f,0x01,0xd1" /* xsetbv */
|
|
|
|
: : "a" (eax), "d" (edx), "c" (index));
|
|
|
|
}
|
|
|
|
|
2012-02-22 05:19:22 +08:00
|
|
|
/*
|
|
|
|
* FPU state switching for scheduling.
|
|
|
|
*
|
|
|
|
* This is a two-stage process:
|
|
|
|
*
|
|
|
|
* - switch_fpu_prepare() saves the old state and
|
|
|
|
* sets the new state of the CR0.TS bit. This is
|
|
|
|
* done within the context of the old process.
|
|
|
|
*
|
|
|
|
* - switch_fpu_finish() restores the new state as
|
|
|
|
* necessary.
|
|
|
|
*/
|
|
|
|
typedef struct { int preload; } fpu_switch_t;
|
|
|
|
|
2015-04-23 23:39:04 +08:00
|
|
|
static inline fpu_switch_t
|
|
|
|
switch_fpu_prepare(struct fpu *old_fpu, struct fpu *new_fpu, int cpu)
|
2012-02-22 05:19:22 +08:00
|
|
|
{
|
|
|
|
fpu_switch_t fpu;
|
|
|
|
|
2012-08-25 05:13:02 +08:00
|
|
|
/*
|
|
|
|
* If the task has used the math, pre-load the FPU on xsave processors
|
|
|
|
* or if the past 5 consecutive context-switches used math.
|
|
|
|
*/
|
2015-04-23 18:49:20 +08:00
|
|
|
fpu.preload = new_fpu->fpstate_active &&
|
2015-04-23 23:39:04 +08:00
|
|
|
(use_eager_fpu() || new_fpu->counter > 5);
|
2015-02-07 04:02:03 +08:00
|
|
|
|
2015-04-24 20:19:26 +08:00
|
|
|
if (old_fpu->fpregs_active) {
|
x86/fpu: Rename fpu_save_init() to copy_fpregs_to_fpstate()
So fpu_save_init() is a historic name that got its name when the only
way the FPU state was FNSAVE, which cleared (well, destroyed) the FPU
state after saving it.
Nowadays the name is misleading, because ever since the introduction of
FXSAVE (and more modern FPU saving instructions) the 'we need to reload
the FPU state' part is only true if there's a pending FPU exception [*],
which is almost never the case.
So rename it to copy_fpregs_to_fpstate() to make it clear what's
happening. Also add a few comments about why we cannot keep registers
in certain cases.
Also clean up the control flow a bit, to make it more apparent when
we are dropping/keeping FP registers, and to optimize the common
case (of keeping fpregs) some more.
[*] Probably not true anymore, modern instructions always leave the FPU
state intact, even if exceptions are pending: because pending FP
exceptions are posted on the next FP instruction, not asynchronously.
They were truly asynchronous back in the IRQ13 case, and we had to
synchronize with them, but that code is not working anymore: we don't
have IRQ13 mapped in the IDT anymore.
But a cleanup patch is obviously not the place to change subtle behavior.
Reviewed-by: Borislav Petkov <bp@alien8.de>
Cc: Andy Lutomirski <luto@amacapital.net>
Cc: Dave Hansen <dave.hansen@linux.intel.com>
Cc: Fenghua Yu <fenghua.yu@intel.com>
Cc: H. Peter Anvin <hpa@zytor.com>
Cc: Linus Torvalds <torvalds@linux-foundation.org>
Cc: Oleg Nesterov <oleg@redhat.com>
Cc: Peter Zijlstra <peterz@infradead.org>
Cc: Thomas Gleixner <tglx@linutronix.de>
Signed-off-by: Ingo Molnar <mingo@kernel.org>
2015-04-27 08:53:16 +08:00
|
|
|
if (!copy_fpregs_to_fpstate(old_fpu))
|
2015-04-23 23:39:04 +08:00
|
|
|
old_fpu->last_cpu = -1;
|
2015-02-07 04:02:03 +08:00
|
|
|
else
|
2015-04-23 23:39:04 +08:00
|
|
|
old_fpu->last_cpu = cpu;
|
2015-02-07 04:02:03 +08:00
|
|
|
|
2015-04-23 18:18:28 +08:00
|
|
|
/* But leave fpu_fpregs_owner_ctx! */
|
2015-04-24 20:19:26 +08:00
|
|
|
old_fpu->fpregs_active = 0;
|
2012-02-22 05:19:22 +08:00
|
|
|
|
|
|
|
/* Don't change CR0.TS if we just switch! */
|
|
|
|
if (fpu.preload) {
|
2015-04-23 23:39:04 +08:00
|
|
|
new_fpu->counter++;
|
2015-04-24 20:26:47 +08:00
|
|
|
__fpregs_activate(new_fpu);
|
x86/fpu: Simplify FPU handling by embedding the fpstate in task_struct (again)
So 6 years ago we made the FPU fpstate dynamically allocated:
aa283f49276e ("x86, fpu: lazy allocation of FPU area - v5")
61c4628b5386 ("x86, fpu: split FPU state from task struct - v5")
In hindsight this was a mistake:
- it complicated context allocation failure handling, such as:
/* kthread execs. TODO: cleanup this horror. */
if (WARN_ON(fpstate_alloc_init(fpu)))
force_sig(SIGKILL, tsk);
- it caused us to enable irqs in fpu__restore():
local_irq_enable();
/*
* does a slab alloc which can sleep
*/
if (fpstate_alloc_init(fpu)) {
/*
* ran out of memory!
*/
do_group_exit(SIGKILL);
return;
}
local_irq_disable();
- it (slightly) slowed down task creation/destruction by adding
slab allocation/free pattens.
- it made access to context contents (slightly) slower by adding
one more pointer dereference.
The motivation for the dynamic allocation was two-fold:
- reduce memory consumption by non-FPU tasks
- allocate and handle only the necessary amount of context for
various XSAVE processors that have varying hardware frame
sizes.
These days, with glibc using SSE memcpy by default and GCC optimizing
for SSE/AVX by default, the scope of FPU using apps on an x86 system is
much larger than it was 6 years ago.
For example on a freshly installed Fedora 21 desktop system, with a
recent kernel, all non-kthread tasks have used the FPU shortly after
bootup.
Also, even modern embedded x86 CPUs try to support the latest vector
instruction set - so they'll too often use the larger xstate frame
sizes.
So remove the dynamic allocation complication by embedding the FPU
fpstate in task_struct again. This should make the FPU a lot more
accessible to all sorts of atomic contexts.
We could still optimize for the xstate frame size in the future,
by moving the state structure to the last element of task_struct,
and allocating only a part of that.
This change is kept minimal by still keeping the ctx_alloc()/free()
routines (that now do nothing substantial) - we'll remove them in
the following patches.
Reviewed-by: Borislav Petkov <bp@alien8.de>
Cc: Andy Lutomirski <luto@amacapital.net>
Cc: Dave Hansen <dave.hansen@linux.intel.com>
Cc: Fenghua Yu <fenghua.yu@intel.com>
Cc: H. Peter Anvin <hpa@zytor.com>
Cc: Linus Torvalds <torvalds@linux-foundation.org>
Cc: Oleg Nesterov <oleg@redhat.com>
Cc: Peter Zijlstra <peterz@infradead.org>
Cc: Thomas Gleixner <tglx@linutronix.de>
Signed-off-by: Ingo Molnar <mingo@kernel.org>
2015-04-27 10:19:39 +08:00
|
|
|
prefetch(&new_fpu->state);
|
2015-04-27 14:58:45 +08:00
|
|
|
} else {
|
|
|
|
__fpregs_deactivate_hw();
|
|
|
|
}
|
2012-02-22 05:19:22 +08:00
|
|
|
} else {
|
2015-04-23 23:39:04 +08:00
|
|
|
old_fpu->counter = 0;
|
|
|
|
old_fpu->last_cpu = -1;
|
2012-02-22 05:19:22 +08:00
|
|
|
if (fpu.preload) {
|
2015-04-23 23:39:04 +08:00
|
|
|
new_fpu->counter++;
|
2015-04-23 23:25:44 +08:00
|
|
|
if (fpu_want_lazy_restore(new_fpu, cpu))
|
2012-02-22 05:19:22 +08:00
|
|
|
fpu.preload = 0;
|
|
|
|
else
|
x86/fpu: Simplify FPU handling by embedding the fpstate in task_struct (again)
So 6 years ago we made the FPU fpstate dynamically allocated:
aa283f49276e ("x86, fpu: lazy allocation of FPU area - v5")
61c4628b5386 ("x86, fpu: split FPU state from task struct - v5")
In hindsight this was a mistake:
- it complicated context allocation failure handling, such as:
/* kthread execs. TODO: cleanup this horror. */
if (WARN_ON(fpstate_alloc_init(fpu)))
force_sig(SIGKILL, tsk);
- it caused us to enable irqs in fpu__restore():
local_irq_enable();
/*
* does a slab alloc which can sleep
*/
if (fpstate_alloc_init(fpu)) {
/*
* ran out of memory!
*/
do_group_exit(SIGKILL);
return;
}
local_irq_disable();
- it (slightly) slowed down task creation/destruction by adding
slab allocation/free pattens.
- it made access to context contents (slightly) slower by adding
one more pointer dereference.
The motivation for the dynamic allocation was two-fold:
- reduce memory consumption by non-FPU tasks
- allocate and handle only the necessary amount of context for
various XSAVE processors that have varying hardware frame
sizes.
These days, with glibc using SSE memcpy by default and GCC optimizing
for SSE/AVX by default, the scope of FPU using apps on an x86 system is
much larger than it was 6 years ago.
For example on a freshly installed Fedora 21 desktop system, with a
recent kernel, all non-kthread tasks have used the FPU shortly after
bootup.
Also, even modern embedded x86 CPUs try to support the latest vector
instruction set - so they'll too often use the larger xstate frame
sizes.
So remove the dynamic allocation complication by embedding the FPU
fpstate in task_struct again. This should make the FPU a lot more
accessible to all sorts of atomic contexts.
We could still optimize for the xstate frame size in the future,
by moving the state structure to the last element of task_struct,
and allocating only a part of that.
This change is kept minimal by still keeping the ctx_alloc()/free()
routines (that now do nothing substantial) - we'll remove them in
the following patches.
Reviewed-by: Borislav Petkov <bp@alien8.de>
Cc: Andy Lutomirski <luto@amacapital.net>
Cc: Dave Hansen <dave.hansen@linux.intel.com>
Cc: Fenghua Yu <fenghua.yu@intel.com>
Cc: H. Peter Anvin <hpa@zytor.com>
Cc: Linus Torvalds <torvalds@linux-foundation.org>
Cc: Oleg Nesterov <oleg@redhat.com>
Cc: Peter Zijlstra <peterz@infradead.org>
Cc: Thomas Gleixner <tglx@linutronix.de>
Signed-off-by: Ingo Molnar <mingo@kernel.org>
2015-04-27 10:19:39 +08:00
|
|
|
prefetch(&new_fpu->state);
|
2015-04-24 20:30:38 +08:00
|
|
|
fpregs_activate(new_fpu);
|
2012-02-22 05:19:22 +08:00
|
|
|
}
|
|
|
|
}
|
|
|
|
return fpu;
|
|
|
|
}
|
|
|
|
|
|
|
|
/*
|
|
|
|
* By the time this gets called, we've already cleared CR0.TS and
|
|
|
|
* given the process the FPU if we are going to preload the FPU
|
|
|
|
* state - all we need to do is to conditionally restore the register
|
|
|
|
* state itself.
|
|
|
|
*/
|
2015-04-23 23:43:27 +08:00
|
|
|
static inline void switch_fpu_finish(struct fpu *new_fpu, fpu_switch_t fpu_switch)
|
2012-02-22 05:19:22 +08:00
|
|
|
{
|
2015-04-23 23:43:27 +08:00
|
|
|
if (fpu_switch.preload) {
|
2015-05-05 17:34:49 +08:00
|
|
|
if (unlikely(copy_fpstate_to_fpregs(new_fpu))) {
|
|
|
|
WARN_ON_FPU(1);
|
2015-04-30 13:12:46 +08:00
|
|
|
fpu__clear(new_fpu);
|
2015-05-05 17:34:49 +08:00
|
|
|
}
|
2012-02-22 05:19:22 +08:00
|
|
|
}
|
|
|
|
}
|
|
|
|
|
|
|
|
/*
|
|
|
|
* Signal frame handlers...
|
|
|
|
*/
|
2015-04-28 17:35:20 +08:00
|
|
|
extern int copy_fpstate_to_sigframe(void __user *buf, void __user *fx, int size);
|
2012-02-22 05:19:22 +08:00
|
|
|
|
|
|
|
/*
|
2015-03-12 01:34:09 +08:00
|
|
|
* Needs to be preemption-safe.
|
2012-02-22 05:19:22 +08:00
|
|
|
*
|
2012-08-25 05:12:58 +08:00
|
|
|
* NOTE! user_fpu_begin() must be used only immediately before restoring
|
2015-03-12 01:34:09 +08:00
|
|
|
* the save state. It does not do any saving/restoring on its own. In
|
|
|
|
* lazy FPU mode, it is just an optimization to avoid a #NM exception,
|
|
|
|
* the task can lose the FPU right after preempt_enable().
|
2012-02-22 05:19:22 +08:00
|
|
|
*/
|
|
|
|
static inline void user_fpu_begin(void)
|
|
|
|
{
|
2015-04-23 18:31:17 +08:00
|
|
|
struct fpu *fpu = ¤t->thread.fpu;
|
|
|
|
|
2012-02-22 05:19:22 +08:00
|
|
|
preempt_disable();
|
2015-04-28 18:28:08 +08:00
|
|
|
if (!fpregs_active())
|
2015-04-24 20:30:38 +08:00
|
|
|
fpregs_activate(fpu);
|
2012-02-22 05:19:22 +08:00
|
|
|
preempt_enable();
|
|
|
|
}
|
|
|
|
|
2015-04-24 08:54:44 +08:00
|
|
|
#endif /* _ASM_X86_FPU_INTERNAL_H */
|