On Wed, Apr 02, 2025 at 08:20:08PM -0700, Eric Biggers wrote:
>
> Also, riscv has scalar AES instructions. (They aren't used by the kernel yet,
> but they could be. The CRC code already uses scalar carryless multiplication.)
It still doesn't mean that it's a good idea to use AES in a
hard IRQ handler, especially if the code is meant to be portable.
> Also, as I said already, x86 does support SIMD instructions in hardirq context
> in some cases. Whether anyone actually uses that, I don't know, but it is
> explicitly supported. Check out irq_fpu_usable().
This is more of an accident than some deliberate strategy of
supporting FPU usage in hard IRQs. This test was initially
added for aesni:
commit 54b6a1bd5364aca95cd6ffae00f2b64c6511122c
Author: Ying Huang <huang.ying.caritas@xxxxxxxxx>
Date: Sun Jan 18 16:28:34 2009 +1100
crypto: aes-ni - Add support to Intel AES-NI instructions for x86_64 platform
It was then improved by:
Author: Linus Torvalds <torvalds@xxxxxxxxxxxxxxxxxxxx>
Date: Mon Feb 13 13:56:14 2012 -0800
i387: make irq_fpu_usable() tests more robust
Some code - especially the crypto layer - wants to use the x86
FP/MMX/AVX register set in what may be interrupt (typically softirq)
context.
At no point was there any intention of using this in a hardirq
context.
Until such a time when you have a valid application for using
lib/crypto code in a hardirq context, I don't think we should
be supporting that at the expense of real users who are in
process/softirq context only.
Cheers,
--
Email: Herbert Xu <herbert@xxxxxxxxxxxxxxxxxxx>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
