[PATCH v1 1/1] riscv: Add RVV memset via multiarch/IFUNC

[daichengrong]

在 2025/11/7 9:56:14, Peter Bergner 写道:
> On 10/31/25 9:25 AM, Yao Zihong wrote:
>> My understanding is that the kernel may eventually make riscv_hwprobe
>> reflect whether an extension is enabled, not just present, but that is
>> not the case today.
>>
>> I’m unsure whether it is glibc’s responsibility to cover this gap in the
>> meantime.
>> If it is, then perhaps we should gate the RVV path on both riscv_hwprobe
>> (to ensure V = 1.0 capability) and dl_hwcap.V (to respect per-process enablement
>> via prctl/sysctl).
>>
>> Do you think this should be handled in glibc or left for the kernel side?
> I don't think glibc can fix this/cover the gap.  My guess is the common use
> case of using prctl to disable vector (or some other extension) would be
> to call prctl and then exec a child process that would inherit the change.
> [Not to say the use case itself is common!]

As stated in the Linux kernel comments:“Do not allow user to turn off V 
if current is not off.”

PR_RISCV_V_VSTATE_CTRL_NEXT_MASK accounts for the enablement status of 
next thread that created by next execve().

If we do nothing, the child process should not see the parent's prctl 
call that enabled vector.

> In that case, the child process and its glibc would never see the parent's
> prctl call that disabled vector, but its hwprobe query would still say that
> vector is enabled, leading to a SIGILL when it tries to execute a vector
> instruction.
>      bergner@bananapif3:~$ ./march-test.out
>      Some enabled risc-v extensions: rv64imafdcv
>      Executed a vector instruction.
>      bergner@bananapif3:~$ ./riscv-disable-vec ./march-test.out
>      Some enabled risc-v extensions: rv64imafdcv
>      Illegal instruction
>
> I think the only solution that makes sense here, is for the kernel to modify
> hwprobe so that it doesn't show vector (or some other extension) when prctl
> has disabled vector (or some other extension).  I'm actually surprised it
> doesn't already operate that way.
>
>
> Peter
>