[PATCH 1/2] riscv: hwprobe: export the availability of vector to user
Peter Bergner
bergner at oss.tenstorrent.com
Thu Aug 6 10:09:00 PDT 2026
On 8/6/26 1:31 AM, Florian Weimer wrote:
>
> And if RISCV_HWPROBE_KEY_IMA_EXT_0 comes back at -1, we'd turn on V
> unconditionally?
No. The unknown key (RISCV_HWPROBE_KEY_IMA_EXT_0 in this case) field would
be reset to -1, but the value field (which is what we test for the presence
of V and other extensions in the resolver) is set to 0, so we would not enable
any ifuncs in that case.
In the "new" case we're discussing, we'll pass RISCV_HWPROBE_KEY_EXT_ENABLED
and RISCV_HWPROBE_KEY_IMA_EXT_0 to hwprobe. For kernels that don't know about
either key, both key fields will be reset to -1 and their value fields set to 0.
No bugs in this case.
For kernels that know about RISCV_HWPROBE_KEY_IMA_EXT_0, but not the new key
RISCV_HWPROBE_KEY_EXT_ENABLED, the key field holding RISCV_HWPROBE_KEY_EXT_ENABLED
will be reset to -1 and its value field set to 0, while the value field
associated with RISCV_HWPROBE_KEY_IMA_EXT_0 will be set to the "extension is
present" value. This still suffers from the (already existing) we'll enable V
ifuncs issue you mentioned if prctl was used to disable V, but as you say,
it will be fixed with a kernel upgrade.
For "new" kernels that know about both keys, the value field associated with
RISCV_HWPROBE_KEY_IMA_EXT_0 key will be set to the "extension is enabled" value.
Peter
More information about the linux-riscv
mailing list