On Nov 9, 2023, at 15:16, Eric Biggers <ebiggers@xxxxxxxxxx> wrote: > On Tue, Nov 07, 2023 at 04:53:13PM +0800, Jerry Shih wrote: >> On Nov 2, 2023, at 13:16, Eric Biggers <ebiggers@xxxxxxxxxx> wrote: >>> On Thu, Oct 26, 2023 at 02:36:38AM +0800, Jerry Shih wrote: >>>> +static int ecb_encrypt(struct skcipher_request *req) >>>> +{ >>> >>> There's no fallback for !crypto_simd_usable() here. I really like it this way. >>> However, for it to work (for skciphers and aeads), RISC-V needs to allow the >>> vector registers to be used in softirq context. Is that already the case? >> >> The kernel-mode-vector could be enabled in softirq, but we don't have nesting >> vector contexts. Will we have the case that kernel needs to jump to softirq for >> encryptions during the regular crypto function? If yes, we need to have fallbacks >> for all algorithms. > > Are you asking what happens if a softirq is taken while the CPU is between > kernel_vector_begin() and kernel_vector_end()? I think that needs to be > prevented by making kernel_vector_begin() and kernel_vector_end() disable and > re-enable softirqs, like what kernel_neon_begin() and kernel_neon_end() do on > arm64. Refer to commit 13150149aa6ded which implemented that behavior on arm64. > > - Eric The current kernel-mode-vector implementation, it only calls `preempt_disable()` during vector context. So, we will hit nesting vector context issue from softirq which also use kernel-vector. https://lore.kernel.org/all/20230721112855.1006-1-andy.chiu@xxxxxxxxxx/ Maybe we could use the `simd_register_aeads_compat()` wrapping as x86 platform first in a simpler way first. -Jerry