[PATCH v3 2/3] riscv: hwprobe: export the availability of vector to user

[Guodong Xu]

Hi Andy,

On Fri, 28 Aug 2026 11:00:59 -0500, Andy Chiu wrote:
> On Thu, Aug 13, 2026 at 04:38:54PM -0700, Mark Harris wrote:
>> > 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
> >
> > [...]
> >
>> indicate that existing keys should be reinterpreted in a new manner.
>> Using a key as a modifier with no value and changing the keys to
>> be order-dependent seems like an unnecessarily confusing ugly hack
>> that we would have to live with for decades to come, just to slightly
>> simplify code needed in the short term to handle older kernels.
>
> [...]
>
>> Because ifunc resolvers may not have access to external symbols
>> beyond __riscv_hwprobe(), it is really attractive to be able to
>> obtain extension availability information using the same function.
>> But that doesn't mean that the kernel has to be involved.  The
>> function is in libc, so it could call the vDSO function and then
>> optionally modify the resulting values according to its own
>> process-specific information about enabled or disabled extensions.
>> This extra information would ideally come from the initial hwcaps

It already does, and I can be more definite than "ideally" here.
ld.so invokes every ifunc resolver through elf_ifunc_invoke(), which
calls the resolver as resolver(GLRO(dl_hwcap), __riscv_hwprobe, NULL);
dl_hwcap is AT_HWCAP from the auxv, which is ELF_HWCAP from the kernel
riscv_get_elf_hwcap() who already considers the prctl V ON or OFF.

glibc's RISC-V memcpy resolver receives that argument today and ignores
it, keying only on hwprobe IMA_EXT_0. So the glibc-side fix is to consult
the dl_hwcap argument the resolver is already handed: no new kernel
interface needed.

Refer to glibc.git, sysdeps/unix/sysv/linux/riscv/multiarch/memcpy.c
  select_memcpy_ifunc (uint64_t dl_hwcap, __riscv_hwprobe_t hwprobe_func)

PS: I briefly verified this solution can work using QEMU.

> Unfortunately, I think the riscv community has decided to stop using
> hwcap and move forward with hwprobe. Although I agree with you that it

If you can clarify what 'stop using hwcap' means, that could help a lot.
The policy I know of is that new multi-letter extensions are exported
through hwprobe only, and the policy doesn't say user space stop reading
hwcap bits.

>From what I can see, hwcap is still in use, and with new single-letter
extensions being ratified, hwcap is being extended as well. Like 'B'.
Andrew stated the policy on his RFC: "If RISC-V defines a single letter
extension, such as V or B, then we should add it to hwcap" [1].

It's true that ELF_HWCAP only carries the single-letter extensions,
and multi-letter extensions go to hwprobe. But here we are talking about
'V'.

> is a convenient way to add such per-process's extension enablement
> status.

For V in particular, AT_HWCAP is already the per-process view. Your
own commit 50724efcb370 ("riscv: hwcap: change ELF_HWCAP to a
function") clears COMPAT_HWCAP_ISA_V whenever the prctl state is not
ON, and Documentation/arch/riscv/vector.rst still tells ELF programs
to read that bit to learn whether they may use V.

>> (which reflect the vector prctl) and any tunables, so it is
>> process-wide, can support arbitrary extensions, and can be checked
>> without any kernel syscalls and without callers having to know or
>> care whether a particular extension can be disabled.  If the prctl
>> was used to re-enable vector in some thread that may not affect it,
>> but that seems like the desired behavior, at least for ifunc
>> resolvers, since they are assumed to produce the same result in any
>> thread and at any point during the process lifetime.
>
> [...]
>
> I think the argument comes down to: do we expect the mismatch between
> an extension's availability and existence to grow? Using the same set of
> keys sounds like a good idea if we expect more extensions comes with
> per-process enablement status. On the other hand, if future extension
> supports come without the ability to turn it off, then this
> implementation may be an overshoot.

My position is with Mark: a positional modifier key is the wrong
shape for hwprobe, and I don't think the kernel needs to change for
this. For V, the per-process answer is already in AT_HWCAP, and
glibc's resolvers should use the hwcap argument they receive.

If a second extension with per-process enablement ever appears, that
is the time to pick a hwprobe flag or an independent bit, as Palmer
suggested. Or a solution based on glibc tunable as Mark mentioned.

[1] https://lore.kernel.org/all/wozbsfbvlhsqhvrvjsxyx2u5rpagwlnezythkutzqwikmzeoah@lc3brdn5cu3t/

BR,
Guodong Xu