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

[Tsukasa OI]

Hi Clément,

On 2025/05/20 16:30, Clément Léger wrote:
> 
> 
> On 20/05/2025 07:25, Tsukasa OI wrote:
>> 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.
> 
> While not technically required right now, there has been a series to use
> ZALRSC to implement AMO (from MIPS) [1] and thus remove the kernel
> dependency on the full "A" extensions. The goal of adding ZAAMO/ZALRSC
> was to have a comprehensive support of RISC-V extensions that might be
> useful for the userspace. Rationale was also that it was better to
> express all the dependencies rather than letting the userspace make some
> assumptions that would be hard to remove later.


Thanks for the background!

In this case, meanings of the key RISCV_HWPROBE_KEY_IMA_EXT_0 should be
changed in the future (when the requirements are lowered and a different
RISCV_HWPROBE_KEY_BASE_BEHAVIOR value is defined) but otherwise looks
fine (and documentation update is only needed once that happens).

And I understand that this is not worrying state for the userland.

I appreciate that!

Thanks,
Tsukasa


> 
> BTW, there are a few mechanisms that are unlikely to be used as well in
> hwprobe (per-cpu extensions for instance, I do not think we yet have
> seen such hardware yet ?). Ditto for per-cpu misaligned access support.
> While potentially not popular, we try to cover the majority of the use
> cases, RISC-V hardware being, by nature, flexible.
> 
> Thanks,
> 
> Clément
> 
> Link:
> https://patchwork.kernel.org/project/linux-riscv/patch/20241225082412.36727-1-arikalo@gmail.com/#26192228
> [1]
> 
>>
>>
>> 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).
>