RVA23 Profile

Can a specific profile compliance be reported as well, instead of forcing applications to check for every feature? This might be useful for applications to detect a minimum baseline.

Here's some further feedback on hwprobe mechanism from the Language and Runtime TG lead, @Ludovic Henry (Deactivated)

I would say the main gaps in the current implementation (not much to do with the API) is whether the extensions it detects are available in a given version of a Kernel. For example, Linux 6.4 today detects IMA, FD, C, and misaligned memory accesses performance. However, it doesn't detect some very useful extensions and features of the hardware:

• V, Zba, Zbb, Zbc, and many other ratified extensions

• SATP mode: sv39, sv48, sv57, etc.

• Support for ZTso

• Optimal vlmul mode (m1, m2, m4, or m8?)

I understand the detection of some of the extensions is a limitation of the Kernel itself (no support for V in the kernel itself for example), and that future versions of the Kernel will detect and report it as part of hwprobe. (I also understand the non-trivial amount of work needed for the Kernel to implement support for these extensions.) But that leads to a situation where on the same hardware, the same runtime (OpenJDK, Go, etc.) will behave and perform differently based on the version of the Kernel. It is also particularly impactful on runtimes which take advantage of JIT compilation which can then fine-tune the code generation for the hardware at-hand (thing -march=native enabled at all time).

The alternative to detecting the features through hwprobe is to use the vendorid/archid/impid to fine-tune based on the known models of hardware. That is what we need to do in the OpenJDK to enable/disable certain features. hwprobe is AFAIK the only way to get that information in user-space.

Overall, the main limitation we see with this hwprobe mechanism today is the need to wait for newer Kernel versions to detect newer extensions.  A possible solution might then be to make sure to backport the detection of these new extensions to older or LTS Kernel versions, but that is up to the Kernel maintainers of course. Another possible solution would be to make the vendorid/archid/impid available to user-space through other means than hwprobe but I'm not aware of the discussions that happened at RVI around that.

Having information about the hardware support for I/D cache coherency would be great to avoid unnecessary syscalls and i-cache flushes.

Distros maintain their own stable kernel (based on some LTS kernel) and they do backport important patches so the dependency on newer kernel version is more a distro question, how they want to handle it ?

Depending on vendorid/archid/impid for detecting HW capabilities instead of hwprobe is not scalable and should only be a backup option until an updated kernel is available. The real problem is that HWPROBE came late in the game so right now we are in catch-up mode. I believe things will be much smoother in the long run.

Regarding Zjid (i.e. hardware support for I/D consistency), it is still not clear whether it will be part of RVA23 profile. This needs to be discussed within RVI.