RFR: 8284196: RISC-V: Detect supported ISA extensions over cpuinfo [v2]

[Ludovic Henry]

On Thu, 9 Feb 2023 06:06:22 GMT, Feilong Jiang <fjiang at openjdk.org> wrote:

>>> > It should be safe for them to do as this PR adds the necessary detection of availability of those ISA extensions.
>>> 
>>> Ok. That also aligns RISC-V with how it's done on other platforms (SHA on x86 or AArch64 for example).
>>> 
>>> I've a slight concern with the reliability of detecting these features based solely on the device tree + being able to force enable said-features in case we know for sure the extension is available but it's not communicated by the kernel.
>>> 
>>> FYI, the kernel doesn't transfer verbatim the device-tree "isa" provided by the hardware, but it reconstruct it based on the extensions the kernel knows about. So if the hardware support a cutting edge extension (Zvknh and Zvkb for example), but the kernel is older and doesn't know about it, the hardware is going to provide a device-tree with `_Zvknh_Zvkb` to the kernel, but it's not going to show up in `/proc/cpuinfo`. (You can find the list of extensions the kernel currently knows about at [1], and the logic to build the `isa` string at [2]).
>> 
>> That make sense to me. My initial thought was to have some sort of checking like this PR does when users try to enable use of isa extensions on the command line. It will be better than simply crashing the JVM when their hardware are not equipped with those features. But as you mentioned, this might also bear the risk of losing the ability for them to do so. In the hope of having some stable user interface for probing riscv hardware features like [1], I guess we might need to stay with the current approach and put off this PR for some while to see. @feilongjiang : Are you OK with this?
>> 
>> [1] https://lkml.org/lkml/2023/2/6/1147
>
>> I guess we might need to stay with the current approach and put off this PR for some while to see
> 
> Agreed.  Looks like it's still too early to do that. I'll convert this PR to draft then.

An alternative approach that doesn't rely on a kernel API is to generate some stub that probes for some instructions, and trigger a SIGILL in case the instruction isn't supported. That SIGILL can be caught by the runtime (very similar to how we do it with SIGSEGV and SafeFetch for example) and we know based on the instruction executed that it isn't available.

That would work as long as there is no conflicts in the encoding of instructions, and no bug/performance penalty in the actual implementation of the instructions (but that's where vendor-specific settings is helpful).

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

PR: https://git.openjdk.org/jdk/pull/12343