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

[Andy Chiu <tchiu@tenstorrent.com>]

Hi Mark,

Sorry for responding late, we have been thinking through this internally
with the team and other community members, and here is the reply

On Thu, Aug 13, 2026 at 04:38:54PM -0700, Mark Harris wrote:
> Andy Chiu wrote:
> > 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.
> 
> Currently, each key has a value and the order of the keys does not
> matter.  If the interface needed to be extended to support
> process-specific values, or thread-specific values (the prctl() is
> thread-specific), I would expect either new keys to retrieve those
> process-specific or thread-specific values, or a new flag bit to

Our concern with the new flag is that we have to call hwprobe twice on
an old kernel that doesn't know about the flag. It takes a syscall when
the VDSO finds an unknown flag at the first call to hwprobe. The kernel
returns -EINVAL immediately, leaving all probe values empty. So the user
space has to make the second call with the flag bit unset.

> 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.
> 
> Additionally, the approach of falling back to the syscall whenever
> the modifier key is used could lead to each check for the vector
> extension, in an ifunc resolver or almost anywhere else, having to
> perform a syscall.  Callers wanting to use other extensions may
> even use this modifier when checking for them, because given the
> choice of knowing whether the extension is potentially available
> or is available, the latter sounds like what they should be using
> to be future-proof, even if there is not currently a way to disable
> the extension.  That could lead to a syscall for every extension
> check, defeating the vDSO cache.

Likewise, I think the new flag bit can encourage the same user space
behavior, because it is the same low cost change to get more
information.

> 
> On some non-RISC-V platforms glibc allows its own use of specific
> CPU capabilities to be disabled through tunables (e.g.,
> GLIBC_TUNABLES=glibc.cpu.hwcaps=-AVX2 ./my_x86_64_program), and as
> of glibc 2.44 tunables can also be set in /etc/tunables.conf and
> applied system-wide, even to specific programs.  This is more
> convenient than a prctl and it would be nice if RISC-V extensions
> could also be disabled for specific programs through tunables, for
> any use where its availability is checked beforehand (in an ifunc
> resolver or elsewhere), without the need to go to the kernel for
> each check.
> 
> 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

Unfortunately, I think the riscv community has decided to stop using
hwcap and move forward with hwprobe. Although I agree with you that it
is a convenient way to add such per-process's extension enablement
status.

> (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.
> 
> If implemented using a new flag, the libc __riscv_hwprobe() function
> could just call the existing vDSO function but with the new flag
> masked out, and then if the flag is set, modify the resulting values.
> That would probably be the simplest and easiest to understand API
> and would not require kernel syscalls.

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.

Cheers,
Andy