* [RFC] Making sense of RISCV_HWPROBE_EXT_* (new flags in version 6.15)
@ 2025-05-20 5:25 Tsukasa OI
2025-05-20 7:30 ` Clément Léger
0 siblings, 1 reply; 7+ messages in thread
From: Tsukasa OI @ 2025-05-20 5:25 UTC (permalink / raw)
To: linux-riscv, Clément Léger,
Miquel Sabaté Solà, Paul Walmsley, Palmer Dabbelt
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).
_______________________________________________
linux-riscv mailing list
linux-riscv@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-riscv
^ permalink raw reply [flat|nested] 7+ messages in thread* Re: [RFC] Making sense of RISCV_HWPROBE_EXT_* (new flags in version 6.15) 2025-05-20 5:25 [RFC] Making sense of RISCV_HWPROBE_EXT_* (new flags in version 6.15) Tsukasa OI @ 2025-05-20 7:30 ` Clément Léger 2025-05-20 9:32 ` Tsukasa OI 0 siblings, 1 reply; 7+ messages in thread From: Clément Léger @ 2025-05-20 7:30 UTC (permalink / raw) To: Tsukasa OI, linux-riscv, Miquel Sabaté Solà, Paul Walmsley, Palmer Dabbelt 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). _______________________________________________ linux-riscv mailing list linux-riscv@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-riscv ^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: [RFC] Making sense of RISCV_HWPROBE_EXT_* (new flags in version 6.15) 2025-05-20 7:30 ` Clément Léger @ 2025-05-20 9:32 ` Tsukasa OI 2025-05-20 13:49 ` Miquel Sabaté Solà 0 siblings, 1 reply; 7+ messages in thread From: Tsukasa OI @ 2025-05-20 9:32 UTC (permalink / raw) To: Clément Léger, linux-riscv, Miquel Sabaté Solà, Paul Walmsley, Palmer Dabbelt 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). > _______________________________________________ linux-riscv mailing list linux-riscv@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-riscv ^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: [RFC] Making sense of RISCV_HWPROBE_EXT_* (new flags in version 6.15) 2025-05-20 9:32 ` Tsukasa OI @ 2025-05-20 13:49 ` Miquel Sabaté Solà 2025-05-20 13:59 ` Clément Léger 2025-05-22 4:16 ` Tsukasa OI 0 siblings, 2 replies; 7+ messages in thread From: Miquel Sabaté Solà @ 2025-05-20 13:49 UTC (permalink / raw) To: Tsukasa OI Cc: Clément Léger, linux-riscv, Paul Walmsley, Palmer Dabbelt [-- Attachment #1.1: Type: text/plain, Size: 9619 bytes --] 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 [-- Attachment #1.2: signature.asc --] [-- Type: application/pgp-signature, Size: 861 bytes --] [-- Attachment #2: Type: text/plain, Size: 161 bytes --] _______________________________________________ linux-riscv mailing list linux-riscv@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-riscv ^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: [RFC] Making sense of RISCV_HWPROBE_EXT_* (new flags in version 6.15) 2025-05-20 13:49 ` Miquel Sabaté Solà @ 2025-05-20 13:59 ` Clément Léger 2025-05-22 4:16 ` Tsukasa OI 1 sibling, 0 replies; 7+ messages in thread From: Clément Léger @ 2025-05-20 13:59 UTC (permalink / raw) To: Miquel Sabaté Solà, Tsukasa OI Cc: linux-riscv, Paul Walmsley, Palmer Dabbelt On 20/05/2025 15: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. > > 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. Kernel rule n°1 being "Do not break the userspace", if it was in a released kernel and thus exposed to userspace, we should most probably keep it. Additionally, if it's useless, then it's not really harming anything, so there is no need to actually remove it. Thanks, Clément > >> >>> >>> 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 _______________________________________________ linux-riscv mailing list linux-riscv@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-riscv ^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: [RFC] Making sense of RISCV_HWPROBE_EXT_* (new flags in version 6.15) 2025-05-20 13:49 ` Miquel Sabaté Solà 2025-05-20 13:59 ` Clément Léger @ 2025-05-22 4:16 ` Tsukasa OI 2025-05-22 11:30 ` Miquel Sabaté Solà 1 sibling, 1 reply; 7+ messages in thread From: Tsukasa OI @ 2025-05-22 4:16 UTC (permalink / raw) To: Miquel Sabaté Solà, Clément Léger Cc: linux-riscv, Paul Walmsley, Palmer Dabbelt 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). 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 _______________________________________________ linux-riscv mailing list linux-riscv@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-riscv ^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: [RFC] Making sense of RISCV_HWPROBE_EXT_* (new flags in version 6.15) 2025-05-22 4:16 ` Tsukasa OI @ 2025-05-22 11:30 ` Miquel Sabaté Solà 0 siblings, 0 replies; 7+ messages in thread From: Miquel Sabaté Solà @ 2025-05-22 11:30 UTC (permalink / raw) To: Tsukasa OI Cc: Clément Léger, linux-riscv, Paul Walmsley, Palmer Dabbelt [-- Attachment #1.1: Type: text/plain, Size: 11666 bytes --] 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 [-- Attachment #1.2: signature.asc --] [-- Type: application/pgp-signature, Size: 861 bytes --] [-- Attachment #2: Type: text/plain, Size: 161 bytes --] _______________________________________________ linux-riscv mailing list linux-riscv@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-riscv ^ permalink raw reply [flat|nested] 7+ messages in thread
end of thread, other threads:[~2025-05-22 11:32 UTC | newest] Thread overview: 7+ messages (download: mbox.gz follow: Atom feed -- links below jump to the message on this page -- 2025-05-20 5:25 [RFC] Making sense of RISCV_HWPROBE_EXT_* (new flags in version 6.15) Tsukasa OI 2025-05-20 7:30 ` Clément Léger 2025-05-20 9:32 ` Tsukasa OI 2025-05-20 13:49 ` Miquel Sabaté Solà 2025-05-20 13:59 ` Clément Léger 2025-05-22 4:16 ` Tsukasa OI 2025-05-22 11:30 ` Miquel Sabaté Solà
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for NNTP newsgroup(s).