| 50867db0 | 05-Dec-2024 |
Ard Biesheuvel <ardb@kernel.org> |
ARM: 9438/1: assembler: Drop obsolete VFP accessor fallback
Now that the minimum supported binutils version is 2.25, we no longer need a workaround for binutils older than 2.24 for accessing VFP con
ARM: 9438/1: assembler: Drop obsolete VFP accessor fallback
Now that the minimum supported binutils version is 2.25, we no longer need a workaround for binutils older than 2.24 for accessing VFP control registers from assembler.
Reviewed-by: Linus Walleij <linus.walleij@linaro.org> Reviewed-by: Nathan Chancellor <nathan@kernel.org> Signed-off-by: Ard Biesheuvel <ardb@kernel.org> Signed-off-by: Russell King (Oracle) <rmk+kernel@armlinux.org.uk>
show more ...
|
| c0b5195b | 02-Oct-2024 |
Sebastian Andrzej Siewior <bigeasy@linutronix.de> |
ARM: 9426/1: vfp: Move sending signals outside of vfp_state_hold()ed section.
VFP_bounce() is invoked from within vfp_support_entry() and may send a signal. Sending a signal uses spinlock_t which be
ARM: 9426/1: vfp: Move sending signals outside of vfp_state_hold()ed section.
VFP_bounce() is invoked from within vfp_support_entry() and may send a signal. Sending a signal uses spinlock_t which becomes a sleeping lock on PREEMPT_RT and must not be acquired within a preempt-disabled section.
Move the vfp_raise_sigfpe() block outside of the vfp_state_hold() section.
Reviewed-by: Ard Biesheuvel <ardb@kernel.org> Signed-off-by: Sebastian Andrzej Siewior <bigeasy@linutronix.de> Signed-off-by: Russell King (Oracle) <rmk+kernel@armlinux.org.uk>
show more ...
|
| 27035c23 | 02-Oct-2024 |
Sebastian Andrzej Siewior <bigeasy@linutronix.de> |
ARM: 9425/1: vfp: Use vfp_state_hold() in vfp_support_entry().
vfp_entry() is invoked from exception handler and is fully preemptible. It uses local_bh_disable() to remain uninterrupted while checki
ARM: 9425/1: vfp: Use vfp_state_hold() in vfp_support_entry().
vfp_entry() is invoked from exception handler and is fully preemptible. It uses local_bh_disable() to remain uninterrupted while checking the VFP state. This is not working on PREEMPT_RT because local_bh_disable() synchronizes the relevant section but the context remains fully preemptible.
Use vfp_state_hold() for uninterrupted access.
Reviewed-by: Ard Biesheuvel <ardb@kernel.org> Signed-off-by: Sebastian Andrzej Siewior <bigeasy@linutronix.de> Signed-off-by: Russell King (Oracle) <rmk+kernel@armlinux.org.uk>
show more ...
|
| b54cdbad | 02-Oct-2024 |
Sebastian Andrzej Siewior <bigeasy@linutronix.de> |
ARM: 9424/1: vfp: Use vfp_state_hold() in vfp_sync_hwstate().
vfp_sync_hwstate() uses preempt_disable() followed by local_bh_disable() to ensure that it won't get interrupted while checking the VFP
ARM: 9424/1: vfp: Use vfp_state_hold() in vfp_sync_hwstate().
vfp_sync_hwstate() uses preempt_disable() followed by local_bh_disable() to ensure that it won't get interrupted while checking the VFP state. This harms PREEMPT_RT because softirq handling can get preempted and local_bh_disable() synchronizes the related section with a sleeping lock which does not work with disabled preemption.
Use the vfp_state_hold() to synchronize the access.
Reviewed-by: Ard Biesheuvel <ardb@kernel.org> Signed-off-by: Sebastian Andrzej Siewior <bigeasy@linutronix.de> Signed-off-by: Russell King (Oracle) <rmk+kernel@armlinux.org.uk>
show more ...
|
| cdd87465 | 19-Mar-2023 |
Ard Biesheuvel <ardb@kernel.org> |
ARM: vfp: Use undef hook for handling VFP exceptions
Now that the VFP support code has been reimplemented as a C function that takes a struct pt_regs pointer and an opcode, we can use the existing u
ARM: vfp: Use undef hook for handling VFP exceptions
Now that the VFP support code has been reimplemented as a C function that takes a struct pt_regs pointer and an opcode, we can use the existing undef_hook framework to deal with undef exceptions triggered by VFP instructions instead of having special handling in assembler.
Reviewed-by: Linus Walleij <linus.walleij@linaro.org> Signed-off-by: Ard Biesheuvel <ardb@kernel.org>
show more ...
|
| 4708fb04 | 16-Mar-2023 |
Ard Biesheuvel <ardb@kernel.org> |
ARM: vfp: Reimplement VFP exception entry in C code
En/disabling softirqs from asm code turned out to be trickier than expected, so vfp_support_entry now returns by tail calling __local_enable_bh_ip
ARM: vfp: Reimplement VFP exception entry in C code
En/disabling softirqs from asm code turned out to be trickier than expected, so vfp_support_entry now returns by tail calling __local_enable_bh_ip() and passing the same arguments that a C call to local_bh_enable() would pass. However, this is slightly hacky, as we don't want to carry our own implementation of local_bh_enable().
So let's bite the bullet, and get rid of the asm logic in vfp_support_entry that reasons about whether or not to save and/or reload the VFP state, and about whether or not an FP exception is pending, and only keep the VFP loading logic as a function that is callable from C.
Replicate the removed logic in vfp_entry(), and use the exact same reasoning as in the asm code. To emphasize the correspondence, retain some of the asm comments in the C version as well.
Signed-off-by: Ard Biesheuvel <ardb@kernel.org> Acked-by: Linus Walleij <linus.walleij@linaro.org>
show more ...
|
| 4a0548c6 | 20-Mar-2023 |
Ard Biesheuvel <ardb@kernel.org> |
ARM: vfp: Remove workaround for Feroceon CPUs
Feroceon CPUs have a non-standard implementation of VFP which reports synchronous VFP exceptions using the async VFP flag. This requires a workaround wh
ARM: vfp: Remove workaround for Feroceon CPUs
Feroceon CPUs have a non-standard implementation of VFP which reports synchronous VFP exceptions using the async VFP flag. This requires a workaround which is difficult to reconcile with other implementations, making it tricky to support both versions in a single image.
Since this is a v5 CPU, it is not supported by armhf and so the likelihood that anybody is using this with recent distros/kernels and rely on the VFP at the same time is extremely low. So let's just disable VFP support on these cores, so we can remove the workaround.
This will help future development to support v5 and v6 CPUs with a single kernel image.
Reviewed-by: Linus Walleij <linus.walleij@linaro.org> Acked-by: Nicolas Pitre <nico@fluxnic.net> Acked-by: Arnd Bergmann <arnd@arndb.de> Signed-off-by: Ard Biesheuvel <ardb@kernel.org>
show more ...
|
| 2b951b0e | 08-May-2023 |
Ard Biesheuvel <ardb@kernel.org> |
ARM: 9297/1: vfp: avoid unbalanced stack on 'success' return path
Commit c76c6c4ecbec0deb5 ("ARM: 9294/2: vfp: Fix broken softirq handling with instrumentation enabled") updated the VFP exception en
ARM: 9297/1: vfp: avoid unbalanced stack on 'success' return path
Commit c76c6c4ecbec0deb5 ("ARM: 9294/2: vfp: Fix broken softirq handling with instrumentation enabled") updated the VFP exception entry logic to go via a C function, so that we get the compiler's version of local_bh_disable(), which may be instrumented, and isn't generally callable from assembler.
However, this assumes that passing an alternative 'success' return address works in C as it does in asm, and this is only the case if the C calls in question are tail calls, as otherwise, the stack will need some unwinding as well.
I have already sent patches to the list that replace most of the asm logic with C code, and so it is preferable to have a minimal fix that addresses the issue and can be backported along with the commit that it
fixes to v6.3 from v6.4. Hopefully, we can land the C conversion for v6.5.
So instead of passing the 'success' return address as a function argument, pass the stack address from where to pop it so that both LR and SP have the expected value.
Fixes: c76c6c4ecbec0deb5 ("ARM: 9294/2: vfp: Fix broken softirq handling with ...") Reported-by: syzbot+d4b00edc2d0c910d4bf4@syzkaller.appspotmail.com Tested-by: syzbot+d4b00edc2d0c910d4bf4@syzkaller.appspotmail.com Reviewed-by: Linus Walleij <linus.walleij@linaro.org> Tested-by: Andrew Lunn <andrew@lunn.ch> Signed-off-by: Ard Biesheuvel <ardb@kernel.org> Tested-by: Andre Przywara <andre.przywara@arm.com> Signed-off-by: Russell King (Oracle) <rmk+kernel@armlinux.org.uk>
show more ...
|
| c76c6c4e | 12-Apr-2023 |
Ard Biesheuvel <ardb@kernel.org> |
ARM: 9294/2: vfp: Fix broken softirq handling with instrumentation enabled
Commit 62b95a7b44d1 ("ARM: 9282/1: vfp: Manipulate task VFP state with softirqs disabled") replaced the en/disable preempti
ARM: 9294/2: vfp: Fix broken softirq handling with instrumentation enabled
Commit 62b95a7b44d1 ("ARM: 9282/1: vfp: Manipulate task VFP state with softirqs disabled") replaced the en/disable preemption calls inside the VFP state handling code with en/disabling of soft IRQs, which is necessary to allow kernel use of the VFP/SIMD unit when handling a soft IRQ.
Unfortunately, when lockdep is enabled (or other instrumentation that enables TRACE_IRQFLAGS), the disable path implemented in asm fails to perform the lockdep and RCU related bookkeeping, resulting in spurious warnings and other badness.
Set let's rework the VFP entry code a little bit so we can make the local_bh_disable() call from C, with all the instrumentations that happen to have been configured. Calling local_bh_enable() can be done from asm, as it is a simple wrapper around __local_bh_enable_ip(), which is always a callable function.
Link: https://lore.kernel.org/all/ZBBYCSZUJOWBg1s8@localhost.localdomain/
Fixes: 62b95a7b44d1 ("ARM: 9282/1: vfp: Manipulate task VFP state with softirqs disabled") Signed-off-by: Ard Biesheuvel <ardb@kernel.org> Reviewed-by: Linus Walleij <linus.walleij@linaro.org> Tested-by: Guenter Roeck <linux@roeck-us.net> Signed-off-by: Russell King (Oracle) <rmk+kernel@armlinux.org.uk>
show more ...
|
| 3a2bdad0 | 21-Mar-2023 |
Ard Biesheuvel <ardb@kernel.org> |
ARM: 9293/1: vfp: Pass successful return address via register R3
In preparation for reimplementing the do_vfp()->vfp_support_entry() handover in C code, switch to using R3 to pass the 'success' retu
ARM: 9293/1: vfp: Pass successful return address via register R3
In preparation for reimplementing the do_vfp()->vfp_support_entry() handover in C code, switch to using R3 to pass the 'success' return address, rather than R9, as it cannot be used for parameter passing.
Signed-off-by: Ard Biesheuvel <ardb@kernel.org> Reviewed-by: Linus Walleij <linus.walleij@linaro.org> Tested-by: Guenter Roeck <linux@roeck-us.net> Signed-off-by: Russell King (Oracle) <rmk+kernel@armlinux.org.uk>
show more ...
|
| c79f8163 | 22-Dec-2022 |
Ard Biesheuvel <ardb@kernel.org> |
ARM: 9283/1: permit non-nested kernel mode NEON in softirq context
We currently only permit kernel mode NEON in process context, to avoid the need to preserve/restore the NEON register file when tak
ARM: 9283/1: permit non-nested kernel mode NEON in softirq context
We currently only permit kernel mode NEON in process context, to avoid the need to preserve/restore the NEON register file when taking an exception while running in the kernel.
Like we did on arm64, we can relax this restriction substantially, by permitting kernel mode NEON from softirq context, while ensuring that softirq processing is disabled when the NEON is being used in task context. This guarantees that only NEON context belonging to user space needs to be preserved and restored, which is already taken care of.
This is especially relevant for network encryption, where incoming frames are typically handled in softirq context, and deferring software decryption to a kernel thread or falling back to C code are both undesirable from a performance PoV.
Tested-by: Martin Willi <martin@strongswan.org> Reviewed-by: Linus Walleij <linus.walleij@linaro.org> Signed-off-by: Ard Biesheuvel <ardb@kernel.org> Signed-off-by: Russell King (Oracle) <rmk+kernel@armlinux.org.uk>
show more ...
|
| 956ca3a4 | 17-Nov-2022 |
Amit Daniel Kachhap <amit.kachhap@arm.com> |
ARM: 9272/1: vfp: Add hwcap for FEAT_AA32I8MM
Int8 matrix multiplication (FEAT_AA32I8MM) is a feature present in AArch32 state for Armv8 and is represented by ISAR6.I8MM identification register.
Th
ARM: 9272/1: vfp: Add hwcap for FEAT_AA32I8MM
Int8 matrix multiplication (FEAT_AA32I8MM) is a feature present in AArch32 state for Armv8 and is represented by ISAR6.I8MM identification register.
This feature denotes the presence of VSMMLA, VSUDOT, VUMMLA, VUSMMLA and VUSDOT instructions and hence adding a hwcap will enable the userspace to check it before trying to use those instructions.
Reviewed-by: Linus Walleij <linus.walleij@linaro.org> Signed-off-by: Amit Daniel Kachhap <amit.kachhap@arm.com> Signed-off-by: Russell King (Oracle) <rmk+kernel@armlinux.org.uk>
show more ...
|
| 23b6d4ad | 17-Nov-2022 |
Amit Daniel Kachhap <amit.kachhap@arm.com> |
ARM: 9271/1: vfp: Add hwcap for FEAT_AA32BF16
Advanced SIMD BFloat16 (FEAT_AA32BF16) is a feature present in AArch32 state for Armv8 and is represented by ISAR6.BF16 identification register.
This f
ARM: 9271/1: vfp: Add hwcap for FEAT_AA32BF16
Advanced SIMD BFloat16 (FEAT_AA32BF16) is a feature present in AArch32 state for Armv8 and is represented by ISAR6.BF16 identification register.
This feature denotes the presence of VCVT, VCVTB, VCVTT, VDOT, VFMAB, VFMAT and VMMLA instructions and hence adding a hwcap will enable the userspace to check it before trying to use those instructions.
Reviewed-by: Linus Walleij <linus.walleij@linaro.org> Signed-off-by: Amit Daniel Kachhap <amit.kachhap@arm.com> Signed-off-by: Russell King (Oracle) <rmk+kernel@armlinux.org.uk>
show more ...
|
| ce483549 | 17-Nov-2022 |
Amit Daniel Kachhap <amit.kachhap@arm.com> |
ARM: 9270/1: vfp: Add hwcap for FEAT_FHM
Floating-point half-precision multiplication (FHM) is a feature present in AArch32 state for Armv8 and is represented by ISAR6.FHM identification register.
ARM: 9270/1: vfp: Add hwcap for FEAT_FHM
Floating-point half-precision multiplication (FHM) is a feature present in AArch32 state for Armv8 and is represented by ISAR6.FHM identification register.
This feature denotes the presence of VFMAL and VMFSL instructions and hence adding a hwcap will enable the userspace to check it before trying to use those instructions.
Reviewed-by: Linus Walleij <linus.walleij@linaro.org> Signed-off-by: Amit Daniel Kachhap <amit.kachhap@arm.com> Signed-off-by: Russell King (Oracle) <rmk+kernel@armlinux.org.uk>
show more ...
|