[RFC] Making sense of RISCV_HWPROBE_EXT_* (new flags in version 6.15)

[Tsukasa OI]

Hello Clément, Miquel and all.

It's too late to make changes for the Linux kernel version 6.15 but at
least we need to clarify something.  I would like to hear from Clément
and Miquel about your original intent of your changes and hear from all
about your thoughts about the argument below.


Background
===========

While I am preparing for the riscv_hwprobe support in the Rust standard
library (for target feature detection) looking at the master branch of
Linux, I found three extensions in the RISCV_HWPROBE_KEY_IMA_EXT_0 key
that would be redundant if we read the documentation pedantically.

cf. Original riscv_hwprobe support for the Rust standard library
(supports all flags as of Linux 6.14 except OS-dependent "Supm"):
<https://github.com/rust-lang/stdarch/pull/1770>

Here's the list (all of them will be new in 6.15):

Commit 4458b8f68dc7ab8309291f1667157d0250938291 (by Miquel):
1.  Zicntr
(Zihpm is excluded because the argument below does not apply).

Commit 9d45d1ff90a6888f6138eb7e1f2619ef427831d3 (by Clément):
2.  Zalrsc
3.  Zaamo


Base Facts
===========

The RISC-V hwprobe documentation states that
RISCV_HWPROBE_BASE_BEHAVIOR_IMA is either RV32IMA/RV64IMA (user ISA
version 2.2 and privileged ISA version 1.10 with a few exceptions) and
RISCV_HWPROBE_KEY_IMA_EXT_0 lists extensions that are compatible with
the RISCV_HWPROBE_BASE_BEHAVIOR_IMA base system behavior (I'll call this
the IMA base behavior from now on).

cf. <https://docs.kernel.org/arch/riscv/hwprobe.html>


1. Zicntr
==========

The user ISA version 2.2 has RV32I / RV64I ("I") base ISAs, version 2.0.
However, "I" base ISAs at that time contain features now ratified as the
"Zicntr" extension.  To be specific, the "I" base ISAs in the user ISA
version 2.2 have changed as follows (with some extras):

User ISA version 2.2:
*   RV32I / RV64I ("I") version 2.0

User ISA version 20190608:
*   RV32I / RV64I ("I") version 2.1
*   The "Zicsr" extension, version 2.0
*   The "Zifencei" extension, version 2.0
*   Non-extension: Counters
    *   3 counters originally available in "I" v2.0 (later "Zicntr")
    *   NEW: Additional up to 29 counters (later "Zihpm")

User ISA version 20240411:
*   RV32I / RV64I ("I") version 2.1
*   The "Zicsr" extension, version 2.0
*   The "Zifencei" extension, version 2.0
*   The "Zicntr" extension, version 2.0 (New as an extension)
*   The "Zihpm" extension, version 2.0 (New as an extension)

In other words, "I" version 2.0 is roughly equivalent to:
*   RV32I / RV64I ("I") version 2.1
*   The "Zicsr" extension, version 2.0
*   The "Zifencei" extension, version 2.0
*   The "Zicntr" extension, version 2.0

So if we think pedantically, the flag containing "Zicntr" makes no
sense.  Of course, there are a few cases where this flag becomes valid:

1.  IMA base behavior should have been changed
    (a documentation fix will be required to justify this)
2.  Denotes that native hardware support of basic hardware counters

In either case, we will need to clarify somewhere.


2/3. Zalrsc / Zaamo
====================

This is easier to tell but harder to justify flags' existence.

1.  The IMA base behavior contains the "A" extension.
2.  Both "Zalrsc" and "Zaamo" extensions are subsets of "A"
    (in fact, A == Zalrsc + Zaamo)
3.  Is there any case where the IMA base behavior is available but
    lacks a part of full "A" extension?

For me, it just looks RISCV_HWPROBE_EXT_ZAAMO and
RISCV_HWPROBE_EXT_ZALRSC are always-on flags.  If the value containing
these bits (key RISCV_HWPROBE_KEY_IMA_EXT_0) just lists extensions (with
no conditions), that would be meaningful if the Linux kernel is changed
so that the full "A" extension is no longer needed.  But because the key
RISCV_HWPROBE_KEY_IMA_EXT_0 lists extensions *compatible to* the IMA
base behavior, justifying this is pretty hard.

If there is a case where these flags can be turned off and still valid,
I'm happy to see an example and learn.


Rust (userland) Behavior on version 1.88 or later
==================================================

>From Rust 1.88 (currently in beta and will be released on the end of
June), the RISC-V feature detection logic (backend for the
is_riscv_feature_detected macro) will start to use the riscv_hwprobe
system call on Linux (before that, only auxiliary vector is used).

cf.
<https://doc.rust-lang.org/beta/std/arch/macro.is_riscv_feature_detected.html>

Currently, these flags are not read by the Rust standard library
(because Linux kernel version 6.15 hasn't released yet) but the behavior
is determined considering existence of these flags (new in 6.15):

If the IMA base behavior is detected, following Rust target features are
enabled:

1.  Either "rv32i" or "rv64i"
    The IMA base behavior contains "I" base and extensions "M" and "A".
2.  "zicsr"
    This is inferred from the fact I explained in the "Zicntr" section
    above.  It is also justified by the fact that Linux requires
    the privileged architecture, which depends on the Zicsr extension.
3.  "zifencei"
    This is inferred from the fact I explained in the "Zicntr" section
    above.  Linux also has the CMODX feature which makes the Zifencei
    extension in the userland valid but riscv_hwprobe doesn't provide
    a flag for the Zifencei extension.
4.  "m"
    The IMA base behavior contains "I" base and extensions "M" and "A".
    It implies the Zmmul extension but this one is not supported by
    the Rust's feature handling system yet.
5.  "a"
    The IMA base behavior contains "I" base and extensions "M" and "A".
6.  "zalrsc"
    This extension is supported by Rust and implied from "a",
    making RISCV_HWPROBE_EXT_ZALRSC ineffective.
7.  "zaamo"
    This extension is supported by Rust and implied from "a",
    making RISCV_HWPROBE_EXT_ZAAMO ineffective.

But the IMA base behavior alone does NOT enable:

1.  "zicntr"
    I implemented the RISC-V feature detection logic in Rust more
    conservatively than the documentation suggests.
    It may make RISCV_HWPROBE_EXT_ZICNTR effective on Rust depending
    on how future versions of the standard library is implemented
    (possibly Rust version 1.90 or later).


Reiterating RFC
================

1.  (To Clément and Miquel)
    I'd like to hear the original intent of your changes.
2.  (To all)
    How do we handle this situation?


Best regards,
Tsukasa

p.s.
Just in case, I'm talking NOTHING about Rust on Linux (kernel mode).