linux/arch/mips/include/asm/fpu.h

333 lines
7.3 KiB
C
Raw Normal View History

/*
* Copyright (C) 2002 MontaVista Software Inc.
* Author: Jun Sun, jsun@mvista.com or jsun@junsun.net
*
* This program is free software; you can redistribute it and/or modify it
* under the terms of the GNU General Public License as published by the
* Free Software Foundation; either version 2 of the License, or (at your
* option) any later version.
*/
#ifndef _ASM_FPU_H
#define _ASM_FPU_H
#include <linux/sched.h>
#include <linux/sched/task_stack.h>
#include <linux/ptrace.h>
#include <linux/thread_info.h>
#include <linux/bitops.h>
#include <asm/mipsregs.h>
#include <asm/cpu.h>
#include <asm/cpu-features.h>
#include <asm/fpu_emulator.h>
#include <asm/hazards.h>
#include <asm/ptrace.h>
#include <asm/processor.h>
#include <asm/current.h>
#include <asm/msa.h>
#ifdef CONFIG_MIPS_MT_FPAFF
#include <asm/mips_mt.h>
#endif
/*
* This enum specifies a mode in which we want the FPU to operate, for cores
MIPS: Support for hybrid FPRs Hybrid FPRs is a scheme where scalar FP registers are 64b wide, but accesses to odd indexed single registers use bits 63:32 of the preceeding even indexed 64b register. In this mode all FP code except that built for the plain FP64 ABI can execute correctly. Most notably a combination of FP64A & FP32 code can execute correctly, allowing for existing FP32 binaries to be linked with new FP64A binaries that can make use of 64 bit FP & MSA. Hybrid FPRs are implemented by setting both the FR & FRE bits, trapping & emulating single precision FP instructions (via Reserved Instruction exceptions) whilst allowing others to execute natively. It therefore has a penalty in terms of execution speed, and should only be used when no fully native mode can be. As more binaries are recompiled to use either the FPXX or FP64(A) ABIs, the need for hybrid FPRs should diminish. However in the short to mid term it allows for a gradual transition towards that world, rather than a complete ABI break which is not feasible for some users & not desirable for many. A task will be executed using the hybrid FPR scheme when its TIF_HYBRID_FPREGS flag is set & TIF_32BIT_FPREGS is clear. A further patch will set the flags as necessary, this patch simply adds the infrastructure necessary for the hybrid FPR mode to work. Signed-off-by: Paul Burton <paul.burton@imgtec.com> Cc: linux-mips@linux-mips.org Cc: Alexander Viro <viro@zeniv.linux.org.uk> Cc: linux-fsdevel@vger.kernel.org Cc: linux-kernel@vger.kernel.org Patchwork: https://patchwork.linux-mips.org/patch/7683/ Signed-off-by: Ralf Baechle <ralf@linux-mips.org>
2014-09-11 15:30:20 +08:00
* which implement the Status.FR bit. Note that the bottom bit of the value
* purposefully matches the desired value of the Status.FR bit.
*/
enum fpu_mode {
FPU_32BIT = 0, /* FR = 0 */
MIPS: Support for hybrid FPRs Hybrid FPRs is a scheme where scalar FP registers are 64b wide, but accesses to odd indexed single registers use bits 63:32 of the preceeding even indexed 64b register. In this mode all FP code except that built for the plain FP64 ABI can execute correctly. Most notably a combination of FP64A & FP32 code can execute correctly, allowing for existing FP32 binaries to be linked with new FP64A binaries that can make use of 64 bit FP & MSA. Hybrid FPRs are implemented by setting both the FR & FRE bits, trapping & emulating single precision FP instructions (via Reserved Instruction exceptions) whilst allowing others to execute natively. It therefore has a penalty in terms of execution speed, and should only be used when no fully native mode can be. As more binaries are recompiled to use either the FPXX or FP64(A) ABIs, the need for hybrid FPRs should diminish. However in the short to mid term it allows for a gradual transition towards that world, rather than a complete ABI break which is not feasible for some users & not desirable for many. A task will be executed using the hybrid FPR scheme when its TIF_HYBRID_FPREGS flag is set & TIF_32BIT_FPREGS is clear. A further patch will set the flags as necessary, this patch simply adds the infrastructure necessary for the hybrid FPR mode to work. Signed-off-by: Paul Burton <paul.burton@imgtec.com> Cc: linux-mips@linux-mips.org Cc: Alexander Viro <viro@zeniv.linux.org.uk> Cc: linux-fsdevel@vger.kernel.org Cc: linux-kernel@vger.kernel.org Patchwork: https://patchwork.linux-mips.org/patch/7683/ Signed-off-by: Ralf Baechle <ralf@linux-mips.org>
2014-09-11 15:30:20 +08:00
FPU_64BIT, /* FR = 1, FRE = 0 */
FPU_AS_IS,
MIPS: Support for hybrid FPRs Hybrid FPRs is a scheme where scalar FP registers are 64b wide, but accesses to odd indexed single registers use bits 63:32 of the preceeding even indexed 64b register. In this mode all FP code except that built for the plain FP64 ABI can execute correctly. Most notably a combination of FP64A & FP32 code can execute correctly, allowing for existing FP32 binaries to be linked with new FP64A binaries that can make use of 64 bit FP & MSA. Hybrid FPRs are implemented by setting both the FR & FRE bits, trapping & emulating single precision FP instructions (via Reserved Instruction exceptions) whilst allowing others to execute natively. It therefore has a penalty in terms of execution speed, and should only be used when no fully native mode can be. As more binaries are recompiled to use either the FPXX or FP64(A) ABIs, the need for hybrid FPRs should diminish. However in the short to mid term it allows for a gradual transition towards that world, rather than a complete ABI break which is not feasible for some users & not desirable for many. A task will be executed using the hybrid FPR scheme when its TIF_HYBRID_FPREGS flag is set & TIF_32BIT_FPREGS is clear. A further patch will set the flags as necessary, this patch simply adds the infrastructure necessary for the hybrid FPR mode to work. Signed-off-by: Paul Burton <paul.burton@imgtec.com> Cc: linux-mips@linux-mips.org Cc: Alexander Viro <viro@zeniv.linux.org.uk> Cc: linux-fsdevel@vger.kernel.org Cc: linux-kernel@vger.kernel.org Patchwork: https://patchwork.linux-mips.org/patch/7683/ Signed-off-by: Ralf Baechle <ralf@linux-mips.org>
2014-09-11 15:30:20 +08:00
FPU_HYBRID, /* FR = 1, FRE = 1 */
#define FPU_FR_MASK 0x1
};
#ifdef CONFIG_MIPS_FP_SUPPORT
extern void _save_fp(struct task_struct *);
extern void _restore_fp(struct task_struct *);
#define __disable_fpu() \
do { \
clear_c0_status(ST0_CU1); \
disable_fpu_hazard(); \
} while (0)
static inline int __enable_fpu(enum fpu_mode mode)
{
int fr;
switch (mode) {
case FPU_AS_IS:
/* just enable the FPU in its current mode */
set_c0_status(ST0_CU1);
enable_fpu_hazard();
return 0;
MIPS: Support for hybrid FPRs Hybrid FPRs is a scheme where scalar FP registers are 64b wide, but accesses to odd indexed single registers use bits 63:32 of the preceeding even indexed 64b register. In this mode all FP code except that built for the plain FP64 ABI can execute correctly. Most notably a combination of FP64A & FP32 code can execute correctly, allowing for existing FP32 binaries to be linked with new FP64A binaries that can make use of 64 bit FP & MSA. Hybrid FPRs are implemented by setting both the FR & FRE bits, trapping & emulating single precision FP instructions (via Reserved Instruction exceptions) whilst allowing others to execute natively. It therefore has a penalty in terms of execution speed, and should only be used when no fully native mode can be. As more binaries are recompiled to use either the FPXX or FP64(A) ABIs, the need for hybrid FPRs should diminish. However in the short to mid term it allows for a gradual transition towards that world, rather than a complete ABI break which is not feasible for some users & not desirable for many. A task will be executed using the hybrid FPR scheme when its TIF_HYBRID_FPREGS flag is set & TIF_32BIT_FPREGS is clear. A further patch will set the flags as necessary, this patch simply adds the infrastructure necessary for the hybrid FPR mode to work. Signed-off-by: Paul Burton <paul.burton@imgtec.com> Cc: linux-mips@linux-mips.org Cc: Alexander Viro <viro@zeniv.linux.org.uk> Cc: linux-fsdevel@vger.kernel.org Cc: linux-kernel@vger.kernel.org Patchwork: https://patchwork.linux-mips.org/patch/7683/ Signed-off-by: Ralf Baechle <ralf@linux-mips.org>
2014-09-11 15:30:20 +08:00
case FPU_HYBRID:
if (!cpu_has_fre)
return SIGFPE;
/* set FRE */
set_c0_config5(MIPS_CONF5_FRE);
MIPS: Support for hybrid FPRs Hybrid FPRs is a scheme where scalar FP registers are 64b wide, but accesses to odd indexed single registers use bits 63:32 of the preceeding even indexed 64b register. In this mode all FP code except that built for the plain FP64 ABI can execute correctly. Most notably a combination of FP64A & FP32 code can execute correctly, allowing for existing FP32 binaries to be linked with new FP64A binaries that can make use of 64 bit FP & MSA. Hybrid FPRs are implemented by setting both the FR & FRE bits, trapping & emulating single precision FP instructions (via Reserved Instruction exceptions) whilst allowing others to execute natively. It therefore has a penalty in terms of execution speed, and should only be used when no fully native mode can be. As more binaries are recompiled to use either the FPXX or FP64(A) ABIs, the need for hybrid FPRs should diminish. However in the short to mid term it allows for a gradual transition towards that world, rather than a complete ABI break which is not feasible for some users & not desirable for many. A task will be executed using the hybrid FPR scheme when its TIF_HYBRID_FPREGS flag is set & TIF_32BIT_FPREGS is clear. A further patch will set the flags as necessary, this patch simply adds the infrastructure necessary for the hybrid FPR mode to work. Signed-off-by: Paul Burton <paul.burton@imgtec.com> Cc: linux-mips@linux-mips.org Cc: Alexander Viro <viro@zeniv.linux.org.uk> Cc: linux-fsdevel@vger.kernel.org Cc: linux-kernel@vger.kernel.org Patchwork: https://patchwork.linux-mips.org/patch/7683/ Signed-off-by: Ralf Baechle <ralf@linux-mips.org>
2014-09-11 15:30:20 +08:00
goto fr_common;
case FPU_64BIT:
#if !(defined(CONFIG_CPU_MIPSR2) || defined(CONFIG_CPU_MIPSR6) \
|| defined(CONFIG_64BIT))
/* we only have a 32-bit FPU */
return SIGFPE;
#endif
/* fall through */
case FPU_32BIT:
if (cpu_has_fre) {
/* clear FRE */
clear_c0_config5(MIPS_CONF5_FRE);
}
MIPS: Support for hybrid FPRs Hybrid FPRs is a scheme where scalar FP registers are 64b wide, but accesses to odd indexed single registers use bits 63:32 of the preceeding even indexed 64b register. In this mode all FP code except that built for the plain FP64 ABI can execute correctly. Most notably a combination of FP64A & FP32 code can execute correctly, allowing for existing FP32 binaries to be linked with new FP64A binaries that can make use of 64 bit FP & MSA. Hybrid FPRs are implemented by setting both the FR & FRE bits, trapping & emulating single precision FP instructions (via Reserved Instruction exceptions) whilst allowing others to execute natively. It therefore has a penalty in terms of execution speed, and should only be used when no fully native mode can be. As more binaries are recompiled to use either the FPXX or FP64(A) ABIs, the need for hybrid FPRs should diminish. However in the short to mid term it allows for a gradual transition towards that world, rather than a complete ABI break which is not feasible for some users & not desirable for many. A task will be executed using the hybrid FPR scheme when its TIF_HYBRID_FPREGS flag is set & TIF_32BIT_FPREGS is clear. A further patch will set the flags as necessary, this patch simply adds the infrastructure necessary for the hybrid FPR mode to work. Signed-off-by: Paul Burton <paul.burton@imgtec.com> Cc: linux-mips@linux-mips.org Cc: Alexander Viro <viro@zeniv.linux.org.uk> Cc: linux-fsdevel@vger.kernel.org Cc: linux-kernel@vger.kernel.org Patchwork: https://patchwork.linux-mips.org/patch/7683/ Signed-off-by: Ralf Baechle <ralf@linux-mips.org>
2014-09-11 15:30:20 +08:00
fr_common:
/* set CU1 & change FR appropriately */
MIPS: Support for hybrid FPRs Hybrid FPRs is a scheme where scalar FP registers are 64b wide, but accesses to odd indexed single registers use bits 63:32 of the preceeding even indexed 64b register. In this mode all FP code except that built for the plain FP64 ABI can execute correctly. Most notably a combination of FP64A & FP32 code can execute correctly, allowing for existing FP32 binaries to be linked with new FP64A binaries that can make use of 64 bit FP & MSA. Hybrid FPRs are implemented by setting both the FR & FRE bits, trapping & emulating single precision FP instructions (via Reserved Instruction exceptions) whilst allowing others to execute natively. It therefore has a penalty in terms of execution speed, and should only be used when no fully native mode can be. As more binaries are recompiled to use either the FPXX or FP64(A) ABIs, the need for hybrid FPRs should diminish. However in the short to mid term it allows for a gradual transition towards that world, rather than a complete ABI break which is not feasible for some users & not desirable for many. A task will be executed using the hybrid FPR scheme when its TIF_HYBRID_FPREGS flag is set & TIF_32BIT_FPREGS is clear. A further patch will set the flags as necessary, this patch simply adds the infrastructure necessary for the hybrid FPR mode to work. Signed-off-by: Paul Burton <paul.burton@imgtec.com> Cc: linux-mips@linux-mips.org Cc: Alexander Viro <viro@zeniv.linux.org.uk> Cc: linux-fsdevel@vger.kernel.org Cc: linux-kernel@vger.kernel.org Patchwork: https://patchwork.linux-mips.org/patch/7683/ Signed-off-by: Ralf Baechle <ralf@linux-mips.org>
2014-09-11 15:30:20 +08:00
fr = (int)mode & FPU_FR_MASK;
change_c0_status(ST0_CU1 | ST0_FR, ST0_CU1 | (fr ? ST0_FR : 0));
enable_fpu_hazard();
/* check FR has the desired value */
if (!!(read_c0_status() & ST0_FR) == !!fr)
return 0;
/* unsupported FR value */
__disable_fpu();
return SIGFPE;
default:
BUG();
}
return SIGFPE;
}
#define clear_fpu_owner() clear_thread_flag(TIF_USEDFPU)
static inline int __is_fpu_owner(void)
{
return test_thread_flag(TIF_USEDFPU);
}
static inline int is_fpu_owner(void)
{
return cpu_has_fpu && __is_fpu_owner();
}
static inline int __own_fpu(void)
{
enum fpu_mode mode;
int ret;
MIPS: Support for hybrid FPRs Hybrid FPRs is a scheme where scalar FP registers are 64b wide, but accesses to odd indexed single registers use bits 63:32 of the preceeding even indexed 64b register. In this mode all FP code except that built for the plain FP64 ABI can execute correctly. Most notably a combination of FP64A & FP32 code can execute correctly, allowing for existing FP32 binaries to be linked with new FP64A binaries that can make use of 64 bit FP & MSA. Hybrid FPRs are implemented by setting both the FR & FRE bits, trapping & emulating single precision FP instructions (via Reserved Instruction exceptions) whilst allowing others to execute natively. It therefore has a penalty in terms of execution speed, and should only be used when no fully native mode can be. As more binaries are recompiled to use either the FPXX or FP64(A) ABIs, the need for hybrid FPRs should diminish. However in the short to mid term it allows for a gradual transition towards that world, rather than a complete ABI break which is not feasible for some users & not desirable for many. A task will be executed using the hybrid FPR scheme when its TIF_HYBRID_FPREGS flag is set & TIF_32BIT_FPREGS is clear. A further patch will set the flags as necessary, this patch simply adds the infrastructure necessary for the hybrid FPR mode to work. Signed-off-by: Paul Burton <paul.burton@imgtec.com> Cc: linux-mips@linux-mips.org Cc: Alexander Viro <viro@zeniv.linux.org.uk> Cc: linux-fsdevel@vger.kernel.org Cc: linux-kernel@vger.kernel.org Patchwork: https://patchwork.linux-mips.org/patch/7683/ Signed-off-by: Ralf Baechle <ralf@linux-mips.org>
2014-09-11 15:30:20 +08:00
if (test_thread_flag(TIF_HYBRID_FPREGS))
mode = FPU_HYBRID;
else
mode = !test_thread_flag(TIF_32BIT_FPREGS);
ret = __enable_fpu(mode);
if (ret)
return ret;
KSTK_STATUS(current) |= ST0_CU1;
MIPS: Support for hybrid FPRs Hybrid FPRs is a scheme where scalar FP registers are 64b wide, but accesses to odd indexed single registers use bits 63:32 of the preceeding even indexed 64b register. In this mode all FP code except that built for the plain FP64 ABI can execute correctly. Most notably a combination of FP64A & FP32 code can execute correctly, allowing for existing FP32 binaries to be linked with new FP64A binaries that can make use of 64 bit FP & MSA. Hybrid FPRs are implemented by setting both the FR & FRE bits, trapping & emulating single precision FP instructions (via Reserved Instruction exceptions) whilst allowing others to execute natively. It therefore has a penalty in terms of execution speed, and should only be used when no fully native mode can be. As more binaries are recompiled to use either the FPXX or FP64(A) ABIs, the need for hybrid FPRs should diminish. However in the short to mid term it allows for a gradual transition towards that world, rather than a complete ABI break which is not feasible for some users & not desirable for many. A task will be executed using the hybrid FPR scheme when its TIF_HYBRID_FPREGS flag is set & TIF_32BIT_FPREGS is clear. A further patch will set the flags as necessary, this patch simply adds the infrastructure necessary for the hybrid FPR mode to work. Signed-off-by: Paul Burton <paul.burton@imgtec.com> Cc: linux-mips@linux-mips.org Cc: Alexander Viro <viro@zeniv.linux.org.uk> Cc: linux-fsdevel@vger.kernel.org Cc: linux-kernel@vger.kernel.org Patchwork: https://patchwork.linux-mips.org/patch/7683/ Signed-off-by: Ralf Baechle <ralf@linux-mips.org>
2014-09-11 15:30:20 +08:00
if (mode == FPU_64BIT || mode == FPU_HYBRID)
KSTK_STATUS(current) |= ST0_FR;
else /* mode == FPU_32BIT */
KSTK_STATUS(current) &= ~ST0_FR;
set_thread_flag(TIF_USEDFPU);
return 0;
}
static inline int own_fpu_inatomic(int restore)
{
int ret = 0;
if (cpu_has_fpu && !__is_fpu_owner()) {
ret = __own_fpu();
if (restore && !ret)
_restore_fp(current);
}
return ret;
}
static inline int own_fpu(int restore)
{
int ret;
preempt_disable();
ret = own_fpu_inatomic(restore);
preempt_enable();
return ret;
}
static inline void lose_fpu_inatomic(int save, struct task_struct *tsk)
{
if (is_msa_enabled()) {
if (save) {
save_msa(tsk);
tsk->thread.fpu.fcr31 =
read_32bit_cp1_register(CP1_STATUS);
}
disable_msa();
clear_tsk_thread_flag(tsk, TIF_USEDMSA);
__disable_fpu();
} else if (is_fpu_owner()) {
if (save)
_save_fp(tsk);
__disable_fpu();
MIPS: Fix FPU disable with preemption The FPU should not be left enabled after a task context switch. This isn't usually a problem as the FPU enable bit is updated before returning to userland, however it can potentially mask kernel bugs, and in fact KVM assumes it won't happen and won't clear the FPU enable bit before returning to the guest, which allows the guest to use stale FPU context. Interrupts and exceptions save and restore most bits of the CP0 Status register which contains the FPU enable bit (CU1). When the kernel needs to enable or disable the FPU (for example due to attempted FPU use by userland, or the scheduler being invoked) both the actual Status register and the saved value in the userland context are updated. However this doesn't work correctly with full kernel preemption enabled, since the FPU enable bit can be cleared from within an interrupt when the scheduler is invoked, and only the userland context is updated, not the interrupt context. For example: 1) Enter kernel with FPU already enabled, TIF_USEDFPU=1, Status.CU1=1 saved. 2) Take a timer interrupt while in kernel mode, Status.CU1=1 saved. 3) Timer interrupt invokes scheduler to preempt the task, which clears TIF_USEDFPU, disables the FPU in Status register (Status.CU1=0), and the value stored in user context from step (1), but not the interrupt context from step (2). 4) When the process is scheduled back in again Status.CU1=0. 5) The interrupt context from step (2) is restored, which sets Status.CU1=1. So from user context point of view, preemption has re-enabled FPU! 6) If the scheduler is invoked again (via preemption or voluntarily) before returning to userland, TIF_USEDFPU=0 so the FPU is not disabled before the task context switch. 7) The next task resumes from the context switch with FPU enabled! The restoring of the Status register on return from interrupt/exception is already selective about which bits to restore, leaving the interrupt mask bits alone so enabling/disabling of CPU interrupt lines can persist. Extend this to also leave both the CU1 bit (FPU enable) and the FR bit (which specifies the FPU mode and gets changed with CU1). This prevents a stale Status value being restored in step (5) above and persisting through subsequent context switches. Also switch to the use of definitions from asm/mipsregs.h while we're at it. Since this change also affects the restoration of Status register on the path back to userland, it increases the sensitivity of the kernel to the problem of the FPU being left enabled, allowing it to propagate to userland, therefore a warning is also added to lose_fpu_inatomic() to point out any future reoccurances before they do any damage. Signed-off-by: James Hogan <james.hogan@imgtec.com> Reviewed-by: Paul Burton <paul.burton@imgtec.com> Cc: linux-mips@linux-mips.org Patchwork: https://patchwork.linux-mips.org/patch/12303/ Signed-off-by: Ralf Baechle <ralf@linux-mips.org>
2016-02-01 21:50:37 +08:00
} else {
/* FPU should not have been left enabled with no owner */
WARN(read_c0_status() & ST0_CU1,
"Orphaned FPU left enabled");
}
KSTK_STATUS(tsk) &= ~ST0_CU1;
clear_tsk_thread_flag(tsk, TIF_USEDFPU);
}
static inline void lose_fpu(int save)
{
preempt_disable();
lose_fpu_inatomic(save, current);
preempt_enable();
}
MIPS: Simplify FP context initialization MIPS has up until now had 3 different ways for a task's floating point context to be initialized: - If the task's first use of FP involves it gaining ownership of an FPU then _init_fpu() is used to initialize the FPU's registers such that they all contain ~0, and the FPU registers will be stored to struct thread_info later (eg. when context switching). - If the task first uses FP on a CPU without an associated FPU then fpu_emulator_init_fpu() initializes the task's floating point register state in struct thread_info such that all floating point register contain the bit pattern 0x7ff800007ff80000, different to the _init_fpu() behaviour. - If a task's floating point context is first accessed via ptrace then init_fp_ctx() initializes the floating point register state in struct thread_info to ~0, giving equivalent state to _init_fpu(). The _init_fpu() path has 2 separate implementations - one for r2k/r3k style systems & one for r4k style systems. The _init_fpu() path also requires that we be careful to clear & restore the value of the Config5.FRE bit on modern systems in order to avoid inadvertently triggering floating point exceptions. None of this code is in a performance critical hot path - it runs only the first time a task uses floating point. As such it doesn't seem to warrant the complications of maintaining the _init_fpu() path. Remove _init_fpu() & fpu_emulator_init_fpu(), instead using init_fp_ctx() consistently to initialize floating point register state in struct thread_info. Upon a task's first use of floating point this will typically mean that we initialize state in memory & then load it into FPU registers using _restore_fp() just as we would on a context switch. For other paths such as __compute_return_epc_for_insn() or mipsr2_decoder() this results in a significant simplification of the work to be done. Signed-off-by: Paul Burton <paul.burton@mips.com> Patchwork: https://patchwork.linux-mips.org/patch/21002/ Cc: linux-mips@linux-mips.org
2018-11-08 07:13:59 +08:00
/**
* init_fp_ctx() - Initialize task FP context
* @target: The task whose FP context should be initialized.
*
* Initializes the FP context of the target task to sane default values if that
* target task does not already have valid FP context. Once the context has
* been initialized, the task will be marked as having used FP & thus having
* valid FP context.
*
* Returns: true if context is initialized, else false.
*/
static inline bool init_fp_ctx(struct task_struct *target)
{
MIPS: Simplify FP context initialization MIPS has up until now had 3 different ways for a task's floating point context to be initialized: - If the task's first use of FP involves it gaining ownership of an FPU then _init_fpu() is used to initialize the FPU's registers such that they all contain ~0, and the FPU registers will be stored to struct thread_info later (eg. when context switching). - If the task first uses FP on a CPU without an associated FPU then fpu_emulator_init_fpu() initializes the task's floating point register state in struct thread_info such that all floating point register contain the bit pattern 0x7ff800007ff80000, different to the _init_fpu() behaviour. - If a task's floating point context is first accessed via ptrace then init_fp_ctx() initializes the floating point register state in struct thread_info to ~0, giving equivalent state to _init_fpu(). The _init_fpu() path has 2 separate implementations - one for r2k/r3k style systems & one for r4k style systems. The _init_fpu() path also requires that we be careful to clear & restore the value of the Config5.FRE bit on modern systems in order to avoid inadvertently triggering floating point exceptions. None of this code is in a performance critical hot path - it runs only the first time a task uses floating point. As such it doesn't seem to warrant the complications of maintaining the _init_fpu() path. Remove _init_fpu() & fpu_emulator_init_fpu(), instead using init_fp_ctx() consistently to initialize floating point register state in struct thread_info. Upon a task's first use of floating point this will typically mean that we initialize state in memory & then load it into FPU registers using _restore_fp() just as we would on a context switch. For other paths such as __compute_return_epc_for_insn() or mipsr2_decoder() this results in a significant simplification of the work to be done. Signed-off-by: Paul Burton <paul.burton@mips.com> Patchwork: https://patchwork.linux-mips.org/patch/21002/ Cc: linux-mips@linux-mips.org
2018-11-08 07:13:59 +08:00
/* If FP has been used then the target already has context */
if (tsk_used_math(target))
return false;
MIPS: Support for hybrid FPRs Hybrid FPRs is a scheme where scalar FP registers are 64b wide, but accesses to odd indexed single registers use bits 63:32 of the preceeding even indexed 64b register. In this mode all FP code except that built for the plain FP64 ABI can execute correctly. Most notably a combination of FP64A & FP32 code can execute correctly, allowing for existing FP32 binaries to be linked with new FP64A binaries that can make use of 64 bit FP & MSA. Hybrid FPRs are implemented by setting both the FR & FRE bits, trapping & emulating single precision FP instructions (via Reserved Instruction exceptions) whilst allowing others to execute natively. It therefore has a penalty in terms of execution speed, and should only be used when no fully native mode can be. As more binaries are recompiled to use either the FPXX or FP64(A) ABIs, the need for hybrid FPRs should diminish. However in the short to mid term it allows for a gradual transition towards that world, rather than a complete ABI break which is not feasible for some users & not desirable for many. A task will be executed using the hybrid FPR scheme when its TIF_HYBRID_FPREGS flag is set & TIF_32BIT_FPREGS is clear. A further patch will set the flags as necessary, this patch simply adds the infrastructure necessary for the hybrid FPR mode to work. Signed-off-by: Paul Burton <paul.burton@imgtec.com> Cc: linux-mips@linux-mips.org Cc: Alexander Viro <viro@zeniv.linux.org.uk> Cc: linux-fsdevel@vger.kernel.org Cc: linux-kernel@vger.kernel.org Patchwork: https://patchwork.linux-mips.org/patch/7683/ Signed-off-by: Ralf Baechle <ralf@linux-mips.org>
2014-09-11 15:30:20 +08:00
MIPS: Simplify FP context initialization MIPS has up until now had 3 different ways for a task's floating point context to be initialized: - If the task's first use of FP involves it gaining ownership of an FPU then _init_fpu() is used to initialize the FPU's registers such that they all contain ~0, and the FPU registers will be stored to struct thread_info later (eg. when context switching). - If the task first uses FP on a CPU without an associated FPU then fpu_emulator_init_fpu() initializes the task's floating point register state in struct thread_info such that all floating point register contain the bit pattern 0x7ff800007ff80000, different to the _init_fpu() behaviour. - If a task's floating point context is first accessed via ptrace then init_fp_ctx() initializes the floating point register state in struct thread_info to ~0, giving equivalent state to _init_fpu(). The _init_fpu() path has 2 separate implementations - one for r2k/r3k style systems & one for r4k style systems. The _init_fpu() path also requires that we be careful to clear & restore the value of the Config5.FRE bit on modern systems in order to avoid inadvertently triggering floating point exceptions. None of this code is in a performance critical hot path - it runs only the first time a task uses floating point. As such it doesn't seem to warrant the complications of maintaining the _init_fpu() path. Remove _init_fpu() & fpu_emulator_init_fpu(), instead using init_fp_ctx() consistently to initialize floating point register state in struct thread_info. Upon a task's first use of floating point this will typically mean that we initialize state in memory & then load it into FPU registers using _restore_fp() just as we would on a context switch. For other paths such as __compute_return_epc_for_insn() or mipsr2_decoder() this results in a significant simplification of the work to be done. Signed-off-by: Paul Burton <paul.burton@mips.com> Patchwork: https://patchwork.linux-mips.org/patch/21002/ Cc: linux-mips@linux-mips.org
2018-11-08 07:13:59 +08:00
/* Begin with data registers set to all 1s... */
memset(&target->thread.fpu.fpr, ~0, sizeof(target->thread.fpu.fpr));
MIPS: Support for hybrid FPRs Hybrid FPRs is a scheme where scalar FP registers are 64b wide, but accesses to odd indexed single registers use bits 63:32 of the preceeding even indexed 64b register. In this mode all FP code except that built for the plain FP64 ABI can execute correctly. Most notably a combination of FP64A & FP32 code can execute correctly, allowing for existing FP32 binaries to be linked with new FP64A binaries that can make use of 64 bit FP & MSA. Hybrid FPRs are implemented by setting both the FR & FRE bits, trapping & emulating single precision FP instructions (via Reserved Instruction exceptions) whilst allowing others to execute natively. It therefore has a penalty in terms of execution speed, and should only be used when no fully native mode can be. As more binaries are recompiled to use either the FPXX or FP64(A) ABIs, the need for hybrid FPRs should diminish. However in the short to mid term it allows for a gradual transition towards that world, rather than a complete ABI break which is not feasible for some users & not desirable for many. A task will be executed using the hybrid FPR scheme when its TIF_HYBRID_FPREGS flag is set & TIF_32BIT_FPREGS is clear. A further patch will set the flags as necessary, this patch simply adds the infrastructure necessary for the hybrid FPR mode to work. Signed-off-by: Paul Burton <paul.burton@imgtec.com> Cc: linux-mips@linux-mips.org Cc: Alexander Viro <viro@zeniv.linux.org.uk> Cc: linux-fsdevel@vger.kernel.org Cc: linux-kernel@vger.kernel.org Patchwork: https://patchwork.linux-mips.org/patch/7683/ Signed-off-by: Ralf Baechle <ralf@linux-mips.org>
2014-09-11 15:30:20 +08:00
MIPS: Simplify FP context initialization MIPS has up until now had 3 different ways for a task's floating point context to be initialized: - If the task's first use of FP involves it gaining ownership of an FPU then _init_fpu() is used to initialize the FPU's registers such that they all contain ~0, and the FPU registers will be stored to struct thread_info later (eg. when context switching). - If the task first uses FP on a CPU without an associated FPU then fpu_emulator_init_fpu() initializes the task's floating point register state in struct thread_info such that all floating point register contain the bit pattern 0x7ff800007ff80000, different to the _init_fpu() behaviour. - If a task's floating point context is first accessed via ptrace then init_fp_ctx() initializes the floating point register state in struct thread_info to ~0, giving equivalent state to _init_fpu(). The _init_fpu() path has 2 separate implementations - one for r2k/r3k style systems & one for r4k style systems. The _init_fpu() path also requires that we be careful to clear & restore the value of the Config5.FRE bit on modern systems in order to avoid inadvertently triggering floating point exceptions. None of this code is in a performance critical hot path - it runs only the first time a task uses floating point. As such it doesn't seem to warrant the complications of maintaining the _init_fpu() path. Remove _init_fpu() & fpu_emulator_init_fpu(), instead using init_fp_ctx() consistently to initialize floating point register state in struct thread_info. Upon a task's first use of floating point this will typically mean that we initialize state in memory & then load it into FPU registers using _restore_fp() just as we would on a context switch. For other paths such as __compute_return_epc_for_insn() or mipsr2_decoder() this results in a significant simplification of the work to be done. Signed-off-by: Paul Burton <paul.burton@mips.com> Patchwork: https://patchwork.linux-mips.org/patch/21002/ Cc: linux-mips@linux-mips.org
2018-11-08 07:13:59 +08:00
/* FCSR has been preset by `mips_set_personality_nan'. */
MIPS: Simplify FP context initialization MIPS has up until now had 3 different ways for a task's floating point context to be initialized: - If the task's first use of FP involves it gaining ownership of an FPU then _init_fpu() is used to initialize the FPU's registers such that they all contain ~0, and the FPU registers will be stored to struct thread_info later (eg. when context switching). - If the task first uses FP on a CPU without an associated FPU then fpu_emulator_init_fpu() initializes the task's floating point register state in struct thread_info such that all floating point register contain the bit pattern 0x7ff800007ff80000, different to the _init_fpu() behaviour. - If a task's floating point context is first accessed via ptrace then init_fp_ctx() initializes the floating point register state in struct thread_info to ~0, giving equivalent state to _init_fpu(). The _init_fpu() path has 2 separate implementations - one for r2k/r3k style systems & one for r4k style systems. The _init_fpu() path also requires that we be careful to clear & restore the value of the Config5.FRE bit on modern systems in order to avoid inadvertently triggering floating point exceptions. None of this code is in a performance critical hot path - it runs only the first time a task uses floating point. As such it doesn't seem to warrant the complications of maintaining the _init_fpu() path. Remove _init_fpu() & fpu_emulator_init_fpu(), instead using init_fp_ctx() consistently to initialize floating point register state in struct thread_info. Upon a task's first use of floating point this will typically mean that we initialize state in memory & then load it into FPU registers using _restore_fp() just as we would on a context switch. For other paths such as __compute_return_epc_for_insn() or mipsr2_decoder() this results in a significant simplification of the work to be done. Signed-off-by: Paul Burton <paul.burton@mips.com> Patchwork: https://patchwork.linux-mips.org/patch/21002/ Cc: linux-mips@linux-mips.org
2018-11-08 07:13:59 +08:00
/*
* Record that the target has "used" math, such that the context
* just initialised, and any modifications made by the caller,
* aren't discarded.
*/
set_stopped_child_used_math(target);
MIPS: Simplify FP context initialization MIPS has up until now had 3 different ways for a task's floating point context to be initialized: - If the task's first use of FP involves it gaining ownership of an FPU then _init_fpu() is used to initialize the FPU's registers such that they all contain ~0, and the FPU registers will be stored to struct thread_info later (eg. when context switching). - If the task first uses FP on a CPU without an associated FPU then fpu_emulator_init_fpu() initializes the task's floating point register state in struct thread_info such that all floating point register contain the bit pattern 0x7ff800007ff80000, different to the _init_fpu() behaviour. - If a task's floating point context is first accessed via ptrace then init_fp_ctx() initializes the floating point register state in struct thread_info to ~0, giving equivalent state to _init_fpu(). The _init_fpu() path has 2 separate implementations - one for r2k/r3k style systems & one for r4k style systems. The _init_fpu() path also requires that we be careful to clear & restore the value of the Config5.FRE bit on modern systems in order to avoid inadvertently triggering floating point exceptions. None of this code is in a performance critical hot path - it runs only the first time a task uses floating point. As such it doesn't seem to warrant the complications of maintaining the _init_fpu() path. Remove _init_fpu() & fpu_emulator_init_fpu(), instead using init_fp_ctx() consistently to initialize floating point register state in struct thread_info. Upon a task's first use of floating point this will typically mean that we initialize state in memory & then load it into FPU registers using _restore_fp() just as we would on a context switch. For other paths such as __compute_return_epc_for_insn() or mipsr2_decoder() this results in a significant simplification of the work to be done. Signed-off-by: Paul Burton <paul.burton@mips.com> Patchwork: https://patchwork.linux-mips.org/patch/21002/ Cc: linux-mips@linux-mips.org
2018-11-08 07:13:59 +08:00
return true;
}
static inline void save_fp(struct task_struct *tsk)
{
if (cpu_has_fpu)
_save_fp(tsk);
}
static inline void restore_fp(struct task_struct *tsk)
{
if (cpu_has_fpu)
_restore_fp(tsk);
}
static inline union fpureg *get_fpu_regs(struct task_struct *tsk)
{
if (tsk == current) {
preempt_disable();
if (is_fpu_owner())
_save_fp(current);
preempt_enable();
}
return tsk->thread.fpu.fpr;
}
#else /* !CONFIG_MIPS_FP_SUPPORT */
/*
* When FP support is disabled we provide only a minimal set of stub functions
* to avoid callers needing to care too much about CONFIG_MIPS_FP_SUPPORT.
*/
static inline int __enable_fpu(enum fpu_mode mode)
{
return SIGILL;
}
static inline void __disable_fpu(void)
{
/* no-op */
}
static inline int is_fpu_owner(void)
{
return 0;
}
static inline void clear_fpu_owner(void)
{
/* no-op */
}
static inline int own_fpu_inatomic(int restore)
{
return SIGILL;
}
static inline int own_fpu(int restore)
{
return SIGILL;
}
static inline void lose_fpu_inatomic(int save, struct task_struct *tsk)
{
/* no-op */
}
static inline void lose_fpu(int save)
{
/* no-op */
}
static inline bool init_fp_ctx(struct task_struct *target)
{
return false;
}
/*
* The following functions should only be called in paths where we know that FP
* support is enabled, typically a path where own_fpu() or __enable_fpu() have
* returned successfully. When CONFIG_MIPS_FP_SUPPORT=n it is known at compile
* time that this should never happen, so calls to these functions should be
* optimized away & never actually be emitted.
*/
extern void save_fp(struct task_struct *tsk)
__compiletime_error("save_fp() should not be called when CONFIG_MIPS_FP_SUPPORT=n");
extern void _save_fp(struct task_struct *)
__compiletime_error("_save_fp() should not be called when CONFIG_MIPS_FP_SUPPORT=n");
extern void restore_fp(struct task_struct *tsk)
__compiletime_error("restore_fp() should not be called when CONFIG_MIPS_FP_SUPPORT=n");
extern void _restore_fp(struct task_struct *)
__compiletime_error("_restore_fp() should not be called when CONFIG_MIPS_FP_SUPPORT=n");
extern union fpureg *get_fpu_regs(struct task_struct *tsk)
__compiletime_error("get_fpu_regs() should not be called when CONFIG_MIPS_FP_SUPPORT=n");
#endif /* !CONFIG_MIPS_FP_SUPPORT */
#endif /* _ASM_FPU_H */