std_detect: Use riscv_hwprobe on RISC-V Linux/Android #1762

taiki-e · 2025-03-30T17:46:41Z

On RISC-V, detection using auxv only supports single-letter extensions.
So, this PR uses riscv_hwprobe that supports multi-letter extensions if available to support more target features. https://www.kernel.org/doc/html/latest/arch/riscv/hwprobe.html

I had originally planned to open a PR after the nightly release that included rust-lang/rust#138742 merged today, but there was a question about this (rust-lang/rust#139139), so I opened it earlier.

Closes rust-lang/rust#139139

Tested with QEMU 9.2.1 user mode:

riscv64gc-unknown-linux-gnu

rv32i: false
rv32e: false
rv64i: true
rv128i: false
zicsr: true
zicntr: false
zihpm: false
zifencei: false
zihintpause: false
m: true
a: true
zacas: true
zawrs: false
zam: false
ztso: true
f: true
d: true
q: false
zfh: true
zfhmin: true
zfinx: false
zdinx: false
zhinx: false
zhinxmin: false
c: true
zba: true
zbb: true
zbc: true
zbs: true
zbkb: true
zbkc: true
zbkx: true
zknd: true
zkne: true
zknh: true
zksed: true
zksh: true
zkr: false
zksed: true
zksh: true
zkr: false
zkn: true
zks: true
zkt: true
v: true
zvfh: true
zvfhmin: true
zve32x: true
zve32f: true
zve64x: true
zve64f: true
zve64d: true
zvkb: true
zvbb: true
zvbc: true
zvkg: true
zvkned: true
zvknha: true
zvknhb: true
zvksed: true
zvksh: true
zvkn: true
zvknc: true
zvkng: true
zvks: true
zvksc: true
zvksg: true
zvkt: true
unaligned-scalar-mem: true
unaligned-vector-mem: false
j: false
p: false

riscv32gc-unknown-linux-gnu

rv32i: true
rv32e: false
rv64i: false
rv128i: false
zicsr: true
zicntr: false
zihpm: false
zifencei: false
zihintpause: false
m: true
a: true
zacas: true
zawrs: false
zam: false
ztso: true
f: true
d: true
q: false
zfh: true
zfhmin: true
zfinx: false
zdinx: false
zhinx: false
zhinxmin: false
c: true
zba: true
zbb: true
zbc: true
zbs: true
zbkb: true
zbkc: true
zbkx: true
zknd: true
zkne: true
zknh: true
zksed: true
zksh: true
zkr: false
zksed: true
zksh: true
zkr: false
zkn: true
zks: true
zkt: true
v: true
zvfh: true
zvfhmin: true
zve32x: true
zve32f: true
zve64x: true
zve64f: true
zve64d: true
zvkb: true
zvbb: true
zvbc: true
zvkg: true
zvkned: true
zvknha: true
zvknhb: true
zvksed: true
zvksh: true
zvkn: true
zvknc: true
zvkng: true
zvks: true
zvksc: true
zvksg: true
zvkt: true
unaligned-scalar-mem: true
unaligned-vector-mem: false
j: false
p: false

rustbot · 2025-03-30T17:46:47Z

r? @Amanieu

rustbot has assigned @Amanieu.
They will have a look at your PR within the next two weeks and either review your PR or reassign to another reviewer.

Use r? to explicitly pick a reviewer

taiki-e · 2025-03-30T17:56:52Z

crates/std_detect/src/detect/os/linux/riscv.rs

+    // FIXME: e is not exposed in any of asm/hwcap.h, uapi/asm/hwcap.h, uapi/asm/hwprobe.h
+    #[cfg(target_arch = "riscv32")]
    enable_feature(
        &mut value,
        Feature::rv32e,
        bit::test(auxv.hwcap, (b'e' - b'a').into()),
    );
+    // FIXME: h is not exposed in uapi/asm/hwcap.h and uapi/asm/hwprobe.h
    enable_feature(
        &mut value,
        Feature::h,


I guess there is no chance for these to be enabled in the current Linux user mode, although...

I would argue that all the supervisor features should probably just be removed from feature detection and from the compiler. They are not relevant for the language/compiler.

crates/std_detect/src/detect/os/linux/riscv.rs

taiki-e · 2025-03-30T18:05:40Z

crates/std_detect/src/detect/os/linux/riscv.rs

+        flags: libc::c_uint,
+    ) -> libc::c_long {
+        unsafe {
+            libc::syscall(


We could use inline assembly for Linux here (like portable-atomic does), but since this module is currently behind the libc feature, and since std currently always depends on libc on all Linux targets, there is no need to complicate the code here.

a4lg · 2025-03-31T11:23:57Z

That's pretty much the same as what I've testing and thanks for making progress earlier than me.
So, I'll review some of the details as a RISC-V toolchain maintainer (mainly on GNU).

a4lg · 2025-04-01T10:41:32Z

@taiki-e @Amanieu

We need to discuss about one topic before merging this: the fact that Linux supports disabling vector support per thread (current one / next context created by following execve call) by a prctl call: PR_RISCV_V_SET_CONTROL.

The point is, support for vector extensions retrieved by a riscv_hwprobe call is not affected whether the vector extension for the current thread (or the next context created by following execve call) is enabled.

IMHO, the solution here would be, checking (on the first feature test call) whether vector extensions for the current thread are enabled by prctl with PR_RISCV_V_GET_CONTROL and disabling vector-related extensions if not. This method cannot track per-thread status and later enablement after the feature detection but should be fine on most cases. Force-enabling vector extensions is also a solution but can be a problem on a library.

taiki-e · 2025-04-01T11:11:59Z

Given the structure of Rust/LLVM's target feature, I wonder if it is UB to call code that is not written in (inline or external) assembly in the time between disallowing vector instructions and re-allowing it.

For example, if I compile code with -C target-feature=+v, the compiler will use vector instructions for code that copies a size larger than a register from memory, but if I disallowing vector instructions and then reach that code, I will get a trap, right?

Amanieu · 2025-04-01T11:28:19Z

My reading of https://docs.kernel.org/arch/riscv/vector.html is that it's mainly intended for system-level management of vector availability. They explicitly say that:

To get the availability of V in an ELF program, please read COMPAT_HWCAP_ISA_V bit of ELF_HWCAP in the auxiliary vector.

So we should just do that: hwcaps will reflect whether vector support is enabled for the current process.

Note that hwprobe does not disable V if vector support is disabled for the process, so we need to use hwcaps in this case (or manually check with prctl(PR_RISCV_V_GET_CONTROL)).

a4lg · 2025-04-01T12:03:52Z

@Amanieu I confirmed that ELF_HWCAP is in fact affected by availability of the V extension when the program starts (unlike riscv_hwprobe; I remembered ELF_HWCAP incorrectly and I worried a breaking change if ELF_HWCAP is not affected by prctl (in fact, that was not the case)).
Still, I think we'd better use prctl not to accidentally enable vector extensions through riscv_hwprobe.

a4lg · 2025-04-01T12:09:51Z

@taiki-e I think that's correct and I'm not worrying about static feature checking (if we use -C target-feature=+v, we expect that the V extension is enabled even on runtime, right?).
I'm worrying about the situation where the vector extensions are soft-disabled on runtime (see intended usage as described in https://docs.kernel.org/arch/riscv/vector.html).

It reflects Vector enablement status, unlike hwprobe.

taiki-e · 2025-04-01T19:48:46Z

Updated PR (mostly based on feedback).

Changed V extension detection to use hwcap.
Removed RISC-V privileged features (supervisor/hypervisor).
- Because these target features are not in rustc's target_feature list and also detecting them from std/std_detect running in user mode is useless.
Enabled cfg check for RISC-V vector-related target features.
- Because rustc_target: Add more RISC-V vector-related features and use zvl*b target features in vector ABI check rust#138742 is now available on the nightly toolchain.

Note that hwprobe does not disable V if vector support is disabled for the process, so we need to use hwcaps in this
case (or manually check with prctl(PR_RISCV_V_GET_CONTROL)).

Still, I think we'd better use prctl not to accidentally enable vector extensions through riscv_hwprobe.

I thought that the use of hwprobe and prctl is probably more preferable because hwcap only supports detection of V extension, but hwprobe also supports detection of cases where only subset of V extension are available.

However, qemu-user 9.2.1 does not seem to support that, so for now I implemented it using hwcap.

[crates/std_detect/src/detect/os/linux/riscv.rs:211:25] libc::prctl(70) = -1

a4lg · 2025-04-02T01:30:15Z

Let me give a time to test that (I'm struggling to prepare RISC-V 32-bit Linux environment with QEMU system emulation while preparing 64-bit counterpart worked well).

taiki-e · 2025-04-02T16:22:33Z

(I tested this with qemu-riscv32 (user mode) using toolchain used in setup-cross-toolchain-action, and updated PR description to include the result.)

a4lg · 2025-04-03T01:59:17Z

Okay, finally I've built full Linux 6.14 + Buildroot + glibc RISC-V environments (32/64) + Rust toolchain and tested your code is working as expected (I could not accept your changes while no real Linux environment is tested). I will likely make some tidying but after you make most of the changes (because I found your prctl-based version branch).

Recommendation: Approval

Sidenote: not just changing the -cpu option to QEMU, I also confirmed that a sysctl entry /proc/sys/abi/riscv_v_default_allow (1: enabled, 0: disabled) changes the result of the V extension retrieved by std::arch::is_riscv_feature_detected!.

taiki-e · 2025-04-05T03:37:51Z

crates/std_detect/src/detect/os/linux/riscv.rs

+// const RISCV_HWPROBE_EXT_SUPM: u64 = 1 << 49;
+


By the way, Linux 6.15 will also add the following.
(Although we cannot include them in this PR because 6.15 is not yet released and could be changed.)

const RISCV_HWPROBE_EXT_ZICNTR: u64 = 1 << 50; const RISCV_HWPROBE_EXT_ZIHPM: u64 = 1 << 51; const RISCV_HWPROBE_EXT_ZFBFMIN: u64 = 1 << 52; const RISCV_HWPROBE_EXT_ZVFBFMIN: u64 = 1 << 53; const RISCV_HWPROBE_EXT_ZVFBFWMA: u64 = 1 << 54; const RISCV_HWPROBE_EXT_ZICBOM: u64 = 1 << 55; const RISCV_HWPROBE_EXT_ZAAMO: u64 = 1 << 56; const RISCV_HWPROBE_EXT_ZALRSC: u64 = 1 << 57;

Wow, I'm writing full riscv_hwprobe feature probing (including OS-independent logic for stdarch) and related feature sets (for Rust) and... I think that will exceed 93, the current limit of the 12-byte cache.

crates/std_detect/src/detect/os/linux/riscv.rs

a4lg · 2025-04-03T02:23:30Z

crates/std_detect/src/detect/arch/riscv.rs

+    // FIXME: we can implement this by getting the current vlen
+    // zvl*b: Minimum Vector Length Standard Extensions


Despite that I can allow this comment alone (so that you can keep up with this PR), I disagree (actually) adding all Zvl*b extensions (in total of 12; * being a power of two between 32 and 65536 inclusive) for being too redundant (e.g. 256 implies 128, 128 implies 64 and so on) and either:

Unlikely to be referred by real-world programs (due to the software-side nature of RVV) or

Likely that (for specialized programs) just knowing the vector length is not enough (it is said that implementing RVV to the hardware is harder than implementing regular SIMD instructions and some reports suggested that the actual performance boost heavily depends on the actual vector engine implementation) so that adding Zvl*b alone will not help them much.

I acknowledge that there's still a need to retrieve the vector register size and I think an intrinsic (which returns the vector register size) would be a better solution.

It indeed makes more sense to have it as a core::arch intrinsic, since nothing OS-specific is needed to get the VLEN, and the actual length information can be obtained in a single call.

Removed that code comment.

a4lg · 2025-04-05T04:29:47Z

crates/std_detect/src/detect/os/linux/riscv.rs

+// const RISCV_HWPROBE_EXT_SUPM: u64 = 1 << 49;
+


Wow, I'm writing full riscv_hwprobe feature probing (including OS-independent logic for stdarch) and related feature sets (for Rust) and... I think that will exceed 93, the current limit of the 12-byte cache.

a4lg · 2025-04-05T04:32:49Z

I noticed that I haven't pressed the "Submit review" button.

a4lg · 2025-04-11T02:45:30Z

crates/std_detect/src/detect/os/linux/riscv.rs

+            }
+        };
+        if out[0].key != -1 {
+            let ima_ext_0 = out[0].value;


It seems using this key alone is not robust enough (checking the IMA base is necessary).

I opened #1770 for my similar proposal with OS-independent extension implication logic and with fixes including this part.

Good catch. Earlier versions of this PR actually included that check, but it was accidentally removed when I changed to use hwcap.
3203fd5#diff-dfab5b675012c4be84a409e8c4f92c8e172e797caf07a23516d1fda390fb9818R152

a4lg · 2025-04-11T02:51:42Z

I opened #1770 to shape the best feature detection logic in my mind.

a4lg · 2025-04-11T02:55:15Z

Interestingly, in the process reviewing your PR, I found that your direct syscall approach (not calling glibc's __riscv_hwprobe and userland vDSO) succeeds to workaround a weird behavior I found when we call glibc's __riscv_hwprobe which calls vDSO prepared by the Linux kernel (likely a Linux-side bug possibly related to vDSO).

taiki-e · 2025-04-11T06:04:07Z

Closing in favor of #1770.

rustbot assigned Amanieu Mar 30, 2025

taiki-e force-pushed the std-detect-riscv-linux branch from c29e969 to 41e579e Compare March 30, 2025 17:50

taiki-e mentioned this pull request Mar 30, 2025

is_riscv_feature_detected doesn't seem to actually detect anything at runtime rust-lang/rust#139139

Open

taiki-e force-pushed the std-detect-riscv-linux branch from 41e579e to 3203fd5 Compare March 30, 2025 17:53

taiki-e commented Mar 30, 2025

View reviewed changes

std_detect: Use riscv_hwprobe on RISC-V Linux/Android

1ece49d

taiki-e force-pushed the std-detect-riscv-linux branch from 3203fd5 to 1ece49d Compare March 31, 2025 01:35

taiki-e added 2 commits April 2, 2025 02:12

std_detect: Enable cfg check for RISC-V vector-related target features

507193a

std_detect: Remove RISC-V privileged features

eeb0002

taiki-e force-pushed the std-detect-riscv-linux branch from 525a848 to e26a29f Compare April 1, 2025 18:40

std_detect: Check hwcap to detect RISC-V V extension

1474c1d

It reflects Vector enablement status, unlike hwprobe.

taiki-e force-pushed the std-detect-riscv-linux branch from e26a29f to 1474c1d Compare April 1, 2025 19:01

a4lg mentioned this pull request Apr 5, 2025

rustc_target: RISC-V Zfinx is incompatible with {ILP32,LP64}[FD] ABIs rust-lang/rust#138872

Open

taiki-e commented Apr 5, 2025

View reviewed changes

a4lg reviewed Apr 5, 2025

View reviewed changes

taiki-e added 2 commits April 10, 2025 17:46

std_detect: Remove comment about zvl*b target features

5bee27c

std_detect: Enable riscv_linux test also on Android

669e553

a4lg mentioned this pull request Apr 11, 2025

RISC-V: riscv_hwprobe-based feature detection #1770

Draft

a4lg suggested changes Apr 11, 2025

View reviewed changes

taiki-e closed this Apr 11, 2025

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

std_detect: Use riscv_hwprobe on RISC-V Linux/Android #1762

std_detect: Use riscv_hwprobe on RISC-V Linux/Android #1762

taiki-e commented Mar 30, 2025 •

edited

Loading

rustbot commented Mar 30, 2025

taiki-e Mar 30, 2025

Amanieu Mar 31, 2025

taiki-e Mar 30, 2025

a4lg commented Mar 31, 2025

a4lg commented Apr 1, 2025 •

edited

Loading

taiki-e commented Apr 1, 2025 •

edited

Loading

Amanieu commented Apr 1, 2025

a4lg commented Apr 1, 2025

a4lg commented Apr 1, 2025

taiki-e commented Apr 1, 2025

a4lg commented Apr 2, 2025

taiki-e commented Apr 2, 2025

a4lg commented Apr 3, 2025 •

edited

Loading

taiki-e Apr 5, 2025

a4lg Apr 5, 2025

a4lg Apr 3, 2025

taiki-e Apr 10, 2025

a4lg Apr 5, 2025

a4lg commented Apr 5, 2025

a4lg Apr 11, 2025

taiki-e Apr 11, 2025

a4lg commented Apr 11, 2025

a4lg commented Apr 11, 2025

taiki-e commented Apr 11, 2025

		// FIXME: we can implement this by getting the current vlen
		// zvl*b: Minimum Vector Length Standard Extensions

std_detect: Use riscv_hwprobe on RISC-V Linux/Android #1762

std_detect: Use riscv_hwprobe on RISC-V Linux/Android #1762

Conversation

taiki-e commented Mar 30, 2025 • edited Loading

rustbot commented Mar 30, 2025

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

a4lg commented Mar 31, 2025

a4lg commented Apr 1, 2025 • edited Loading

taiki-e commented Apr 1, 2025 • edited Loading

Amanieu commented Apr 1, 2025

a4lg commented Apr 1, 2025

a4lg commented Apr 1, 2025

taiki-e commented Apr 1, 2025

a4lg commented Apr 2, 2025

taiki-e commented Apr 2, 2025

a4lg commented Apr 3, 2025 • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

a4lg commented Apr 5, 2025

Choose a reason for hiding this comment

Choose a reason for hiding this comment

a4lg commented Apr 11, 2025

a4lg commented Apr 11, 2025

taiki-e commented Apr 11, 2025

taiki-e commented Mar 30, 2025 •

edited

Loading

a4lg commented Apr 1, 2025 •

edited

Loading

taiki-e commented Apr 1, 2025 •

edited

Loading

a4lg commented Apr 3, 2025 •

edited

Loading