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

Tue May 20 06:49:30 PDT 2025

Hello,

On dt., de maig 20 2025, Tsukasa OI wrote:

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

From my end and the Zicntr inclusion, I have to admit that given the
documentation and the arguments you are bringing to the table, it is
indeed redundant if we look at things pedantically. That being said, and
as both of you are mentioning, maybe the requirements could be lowered
to enable the flexibility which is inherent on the RISC-V architecture.

Thus, I'm fine if you want me to provide a patch removing Zicntr in
hwprobe if that is inconvenient to user-space. That is, I'd still keep
it just in case, but if you feel that it's inconvenient or that it
breaks user-space in any way, I'm more than happy to provide a patch for
that.

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

Thanks for looking into this!
Miquel
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 861 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-riscv/attachments/20250520/69a70a10/attachment.sig>