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

Tue May 20 00:30:34 PDT 2025

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.

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).