RFR: 8333245: RISC-V: UseRVV option can't be enabled after JDK-8316859

[Robbin Ehn]

On Thu, 30 May 2024 09:13:30 GMT, Gui Cao <gcao at openjdk.org> wrote:

> Because some dev boards only support RVV version 0.7, In [JDK-8316859](https://bugs.openjdk.org/browse/JDK-8316859) we masked the use of HWCAP to probe for RVV extensions, and in the meantime, we can use hwprobe to probe for V extensions in Linux kernel 6.5 and above. But recently we got Banana Pi BPI-F3 board (has RVV1.0), but his kernel is 6.1.15, so the V extensions detected by HWCAP are masked. And we get the warning: `RVV is not supported on this CPU` when we enable UseRVV with the command, and we can't enable UseRVV correctly.
> 
> Without Patch:
> 
> zifeihan at bananapif3:~/jre/jdk/bin$ ./java -XX:+PrintFlagsFinal -XX:+UseRVV -version | grep UseRVV
> OpenJDK 64-Bit Server VM warning: RVV is not supported on this CPU
>      bool UseRVV                                   = false                                {ARCH product} {command line}
>      bool UseRVVForBigIntegerShiftIntrinsics       = false                                {ARCH product} {default}
> openjdk version "23-internal" 2024-09-17
> OpenJDK Runtime Environment (build 23-internal-adhoc.zifeihan.jdk)
> OpenJDK 64-Bit Server VM (build 23-internal-adhoc.zifeihan.jdk, mixed mode)
> 
> 
> With Patch:
> 
> zifeihan at bananapif3:~/jre/jdk/bin$ ./java -XX:+PrintFlagsFinal -XX:+UseRVV -version | grep UseRVV
>      bool UseRVV                                   = true                                 {ARCH product} {command line}
>      bool UseRVVForBigIntegerShiftIntrinsics       = true                                 {ARCH product} {default}
> openjdk version "23-internal" 2024-09-17
> OpenJDK Runtime Environment (build 23-internal-adhoc.zifeihan.jdk)
> OpenJDK 64-Bit Server VM (build 23-internal-adhoc.zifeihan.jdk, mixed mode)

If you don't have RVV you are not guaranteed to have Zicsr, meaning the csrr read of vlenb may crash ?
If you have csr, what will that return in this case? (no V but Zicsr)

You also need kernel support for RVV:
- You must turn on V from privilege mode, the kernel needs to do this.
- If you are context switched in the middle of your vector code the kernel must saves all those V registers.

Only kernels with hw_probe that is reporting RVV is guaranteed todo this.

If this is a vanilla 6.1.15 you can't use V AFIAK. If there are out of tree patches on top of this to make V work, they need to add the hw_probe patches also.

So I would suggest something like:
- If UseRVV and hwcap V = true but no hwprobe.
- Test if we can csrr in a safe fetch manor.
- If we can, we try to read vector context status field, VS, to determine if it's on or off. (in a 'safe fetch' manor)
- If that succeds, we store something in v0, change CPU using affinity mask, and verify that v0 contains that value after the change of CPU.
- Now you just need to cross fingers that it is v1.0 :) (this will still fail on THEAD)

Or similar as we don't want the VM to crash just because an user added +UseRVV erroneously.

Note in 6.7 there is `prctl(PR_RISCV_V_SET_CONTROL, unsigned long arg)` to turn on/off V for a thread.

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

PR Comment: https://git.openjdk.org/jdk/pull/19472#issuecomment-2139241648