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

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

[Florian Weimer]

* Andy Chiu:

> Userland IFUNC resolvers use hwprobe to decide whether to dispatch to
> vectorized routines. But RISCV_HWPROBE_KEY_IMA_EXT_0 only reports what
> is present in hardware, not what the calling process may actually use:
> when Vector is disabled for a process via
> prctl(PR_RISCV_V_SET_CONTROL, PR_RISCV_V_VSTATE_CTRL_OFF), it is still
> reported as present. A resolver that trusts this and runs a vector
> instruction crashes with SIGILL.
>
> Add RISCV_HWPROBE_KEY_EXT_ENABLED, a positional modifier key that carries
> no value of its own. Within a single request, keys placed after it report
> extensions that are both present and enabled for the calling process,
> while keys before it keep reporting hardware presence. This masks out V
> and its V-dependent sub-extensions when V is disabled for the process, and
> lets userland obtain both views in one query:
>
>       [ {IMA_EXT_0}, {EXT_ENABLED}, {IMA_EXT_0} ]
>           present       modifier       enabled
>
> The enabled view depends on per-process state, so it cannot be served from
> the vDSO's process-independent cache; requests carrying the modifier are
> deferred to the syscall. Unknown keys are still reported as -1, so the
> feature is detectable and existing users are unaffected.

What is the expected behavior if RISCV_HWPROBE_KEY_EXT_ENABLED is not
supported?

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.

Thanks,
Florian

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

[Peter Bergner]

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

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

[Florian Weimer]

* Peter Bergner:

>> 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.

And if RISCV_HWPROBE_KEY_IMA_EXT_0 comes back at -1, we'd turn on V
unconditionally?  That still leaves the existing bug on old kernels, but
at least the bug goes away with a kernel upgrade.  This isn't too bad.

Thanks,
Florian

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

[Peter Bergner]

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