RFR: 8365732: RISC-V: implement AES CTR intrinsics [v26]

[Hamlin Li]

On Wed, 19 Nov 2025 07:22:28 GMT, Anjian Wen <wenanjian at openjdk.org> wrote:

>> src/hotspot/cpu/riscv/stubGenerator_riscv.cpp line 2676:
>> 
>>> 2674:     // Compute #rounds for AES based on the length of the key array
>>> 2675:     __ lwu(keylen, Address(key, arrayOopDesc::length_offset_in_bytes() - arrayOopDesc::base_offset_in_bytes(T_INT)));
>>> 2676:     __ mv(t0, 52);
>> 
>> what's this `52`? I see it also in `generate_aescrypt_encryptBlock`, do they mean similar things?
>> Can you add some comment about it? and give a name rather than use the magic number.
>
> key length could be only {11, 13, 15} * 4 = {44, 52, 60}，I notice that x86 and aarch64 use directly 52，I think add some more comment will be enough？

Can you add some comments in other existing code with magic 52 if they mean the same thing? Thanks!

>> src/hotspot/cpu/riscv/stubGenerator_riscv.cpp line 2748:
>> 
>>> 2746:     };
>>> 2747: 
>>> 2748:     __ vsetivli(x0, 4, Assembler::e32, Assembler::m1);
>> 
>> A general question, can we make it bigger than `4`, or even `m2`?
>
> This is a good question! I spent a relatively long time on it earlier. 
> Initially, I tried m2 and m4. In the case of m4, I had already developed a version passed all the test(which really take a long time to test), it seems faster, but since the Java API supports non-complete block data encrypt or decrypt, it is difficult to ensure the time for counter increment is consistent under various circumstances, which may pose a security risk thanks to the remind of Andrew. Additionally, the Java API allows the counter to grow up to 128 bits, RV does not have a very suitable vector 128-bit add currently. Using other types such as 64-bit requires consideration of the overflow issue, and using a version higher than m1 makes it more harder to ensure the time for each counter increment. Based on these considerations, I selected m1.

Thank you for explanation!

>> src/hotspot/cpu/riscv/stubGenerator_riscv.cpp line 2813:
>> 
>>> 2811:     __ bind(L_exit);
>>> 2812:     __ sw(used, Address(used_ptr));
>>> 2813:     __ mv(x10, input_len);
>> 
>> is this mv necessary?
>
> it's a return value saved to x10, it seems necessary according to aarch64 and x86, aarch64 used r0 to save it and x86 used rax

There is a `mv` before exit of `generate_counterMode_AESCrypt`, is this one still necessary?

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/25281#discussion_r2541293550
PR Review Comment: https://git.openjdk.org/jdk/pull/25281#discussion_r2541301228
PR Review Comment: https://git.openjdk.org/jdk/pull/25281#discussion_r2541300426