Re: [EXT] Re: [PATCH 1/2] riscv: hwprobe: export the availability of vector to user

Back from vacation and I don't see that Florian's question was answered, so...
Also adding Jeff in on CC, since Jeff, Palmer and I have discussed this on the
GCC patch review call.


On 7/24/26 7:53 AM, Florian Weimer wrote:
> What is the expected behavior if RISCV_HWPROBE_KEY_EXT_ENABLED is not
> supported?

Unknown keys are ignored by the kernel modulo that the unknown key value
is reset to -1.  This means we can safely pass RISCV_HWPROBE_KEY_EXT_ENABLED
to both old and new kernels.

Andy did look at possibly adding a new "flag" value, rather than a new "key",
but old kernels basically rejected the entire hwprobe call for unknown flag
values and so doing that would not be a userspace simplification.


> We only get a true userspace simplification over hwprobe + prctl if we
> can disable vector extension usage if the kernel does not support
> RISCV_HWPROBE_KEY_EXT_ENABLED (so a V usage regression for older
> kernels).  Otherwise we'd have to use the new approach and, as a
> fallback, the old combination of hwprobe and prctl.

Since the kernel ignores unknown keys, we do get a userspace simplification
over hwprobe + prctl.  The plan is for our GLIBC IFUNC resolvers to just have
one hwprobe call (as they do now) with RISCV_HWPROBE_KEY_EXT_ENABLED as the
first key and RISCV_HWPROBE_KEY_IMA_EXT_0 as the second key.

We also don't need to have any configure time checks in GLIBC to see whether
we can pass the new key to the kernel or not, we can just blindly pass it in.
On old kernels, we'll get the "extension is present" result for the key
RISCV_HWPROBE_KEY_IMA_EXT_0 we're currently getting now, while on new kernels,
we'll get the better "extension is enabled" result.


Peter



_______________________________________________
linux-riscv mailing list
[email protected]
http://lists.infradead.org/mailman/listinfo/linux-riscv