On Tue, Mar 02, 2021 at 10:01:12AM +0100, Ard Biesheuvel wrote: > Kernel mode NEON can be used in task or softirq context, but only in > a non-nesting manner, i.e., softirq context is only permitted if the > interrupt was not taken at a point where the kernel was using the NEON > in task context. > > This means all users of kernel mode NEON have to be aware of this > limitation, and either need to provide scalar fallbacks that may be much > slower (up to 20x for AES instructions) and potentially less safe, or > use an asynchronous interface that defers processing to a later time > when the NEON is guaranteed to be available. > > Given that grabbing and releasing the NEON is cheap, we can relax this > restriction, by increasing the granularity of kernel mode NEON code, and > always disabling softirq processing while the NEON is being used in task > context. > > Signed-off-by: Ard Biesheuvel <ardb@xxxxxxxxxx> > --- > arch/arm64/crypto/aes-modes.S | 2 +- > arch/arm64/crypto/sha1-ce-core.S | 2 +- > arch/arm64/crypto/sha2-ce-core.S | 2 +- > arch/arm64/crypto/sha3-ce-core.S | 4 +-- > arch/arm64/crypto/sha512-ce-core.S | 2 +- > arch/arm64/include/asm/assembler.h | 28 +++++++++++++++----- > arch/arm64/kernel/asm-offsets.c | 2 ++ > arch/arm64/kernel/fpsimd.c | 4 +-- > 8 files changed, 31 insertions(+), 15 deletions(-) Acked-by: Will Deacon <will@xxxxxxxxxx> Will
