[RFC] Making sense of RISCV_HWPROBE_EXT_* (new flags in version 6.15)
Miquel Sabaté Solà
mikisabate at gmail.com
Thu May 22 04:30:57 PDT 2025
On dj., de maig 22 2025, Tsukasa OI wrote:
> On 2025/05/20 22:49, Miquel Sabaté Solà wrote:
>> 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.
>
> Thanks for the background!
>
> I wasn't keeping my eyes on the Linux kernel and I'm sorry for that.
> I would have replied with concerns if I was there at the time but I
> understand that this is quite hard to notice. So don't mind too much.
>
>>
>> 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.
>
> I support to keep it (even if this is *currently* redundant).
>
> As Clément quoted, we'd like to follow the rule: "Do not break the
> userspace". As the current requirements can be lowered in the future
> and the Zicntr extension constant will perfectly make sense if that happens.
>
> If that happens, I would propose adding the constant for the Zifencei
> extension (which has a history similar to the Zicntr extension but not
> in the extension list for riscv_hwprobe).
>
This is already the current behavior, as the extension for Zifencei is
already defined (see arch/riscv/include/asm/hwcap.h) and the extension
is properly detected, but it's simply not exported to the riscv_hwprobe
interface. Hence, no patches required for now.
Thanks for the feedback,
Miquel
>
> I appreciate that both of you (Miquel and Clément) gave me the
> backgrounds and happy to confirm that no userland problems will occur on
> the kernel version 6.15. I (or someone) might change the behavior on
> handling the Zicntr extension on the Rust standard library in the future
> but it will be still compatible to the documented kernel behavior.
>
> Best regards,
> 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).
>>>>
>>
>> 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/20250522/5e7d8415/attachment.sig>
More information about the linux-riscv
mailing list