Re: [PATCH] cipher:riscv: gate Zvkned AES backend on VLEN == 128

Hello,

On 2026-05-06 10:47, Michael Neuling wrote:
> Jussi,
> 
> Thanks for the reply.
> 
>> m4 batching code path selects 128-bit vectors (4 32-bit elements or
>> 16 8-bit elements) and "m4" grouping. Whatever HW supports VLEN>128
>> or VLEN=128 not should not matter here.
> 
> I think the code's assumption around __riscv_vset_v_u32m1_u32m4() may 
> be wrong.

Thanks for checking this out and for the reproducer. I tested with clang 
and same problem persists, __riscv_vset_v_u32m1_u32m4 usage must be 
wrong. I'll check for proper fix.


Btw, VLEN=512 gives yet another output:

$ clang --target=riscv64-linux-gnu libgcrypt-rvv-vlen128-assumption.c -o 
libgcrypt-rvv-vlen128-assumption -O2 -march=rv64gcv -static
$ qemu-riscv64 -cpu max,vlen=512 ./libgcrypt-rvv-vlen128-assumption
Element-by-element view of out[0..15]:

   out[ 0] = 10001111
   out[ 1] = 10002222
   out[ 2] = 10003333
   out[ 3] = 10004444
   out[ 4] = 00000000
   out[ 5] = 00000000
   out[ 6] = 00000000
   out[ 7] = 00000000
   out[ 8] = 00000000
   out[ 9] = 00000000
   out[10] = 00000000
   out[11] = 00000000
   out[12] = 00000000
   out[13] = 00000000
   out[14] = 00000000
   out[15] = 00000000

libgcrypt-shaped layout (VLEN=128 assumption): BUG -- AES_CRYPT m4 vl=16 
will not find the 4 blocks here

Where each loaded m1 register actually lands in g (per RVV intrinsic 
spec, sub-register N -> elements N*VLMAX_m1 .. (N+1)*VLMAX_m1 - 1):
   out[0..3]   = sub-register 0 (= r0 + r0-tail)
   ... and so on for sub-registers 1..3



-Jussi