Re: [PATCH -next v20 24/26] riscv: Add documentation for Vector

[Rémi Denis-Courmont]

	Hi,

Le torstaina 18. toukokuuta 2023 19.19.47 EEST, vous avez écrit :
> This patch add a brief documentation of the userspace interface in
> regard to the RISC-V Vector extension.
> 
> Signed-off-by: Andy Chiu <andy.chiu at sifive.com>
> Reviewed-by: Greentime Hu <greentime.hu at sifive.com>
> Reviewed-by: Vincent Chen <vincent.chen at sifive.com>
> Co-developed-by: Bagas Sanjaya <bagasdotme at gmail.com>
> Signed-off-by: Bagas Sanjaya <bagasdotme at gmail.com>
> ---
> Changelog v20:
>  - Drop bit-field repressentation and typos (Bj?rn)
>  - Fix document styling (Bagas)
> ---
>  Documentation/riscv/index.rst  |   1 +
>  Documentation/riscv/vector.rst | 120 +++++++++++++++++++++++++++++++++
>  2 files changed, 121 insertions(+)
>  create mode 100644 Documentation/riscv/vector.rst
> 
> diff --git a/Documentation/riscv/index.rst b/Documentation/riscv/index.rst
> index 175a91db0200..95cf9c1e1da1 100644
> --- a/Documentation/riscv/index.rst
> +++ b/Documentation/riscv/index.rst
> @@ -10,6 +10,7 @@ RISC-V architecture
>      hwprobe
>      patch-acceptance
>      uabi
> +    vector
> 
>      features
> 
> diff --git a/Documentation/riscv/vector.rst b/Documentation/riscv/vector.rst
> new file mode 100644
> index 000000000000..5d37fd212720
> --- /dev/null
> +++ b/Documentation/riscv/vector.rst
> @@ -0,0 +1,120 @@
> +.. SPDX-License-Identifier: GPL-2.0
> +
> +=========================================
> +Vector Extension Support for RISC-V Linux
> +=========================================
> +
> +This document briefly outlines the interface provided to userspace by Linux
> in +order to support the use of the RISC-V Vector Extension.
> +
> +1.  prctl() Interface
> +---------------------
> +
> +Two new prctl() calls are added to allow programs to manage the enablement
> +status for the use of Vector in userspace:
> +
> +* prctl(PR_RISCV_V_SET_CONTROL, unsigned long arg)
> +
> +    Sets the Vector enablement status of the calling thread, where the
> control
> +    argument consists of two 2-bit enablement statuses and a bit
> for inheritance
> +    mode. Other threads of the calling process are
> unaffected.

I somewhat wonder who is/are the intended users of this new prctl(). Are they 
the run-time (libc)? The main program? Libraries using RVV internally (think 
OpenSSL, Nettle, FFmpeg, etc)? The init system?

Library code doesn't typically know how stacks are allocated and how signal 
are handled (on alternate or normal stacks), since signal handlers are 
process-global state. So I figure that libraries should keep off off this one.

Conversely, it would be impractical for programs to call a Linux-specific RISC-
V-specific in or around their main(). And then libc presumably should not 
override the configured policy that comes from sysctl or from the parent 
process.

So I guess that that leaves just the init system (in a broad sense) then?

In any case, I think the intended use should be clarified with proper usage 
guidelines. Otherwise, what I bet happens is RVV-capable libraries just 
blindly invoke the prctl() to "enable RVV", deafeating the purpose of having 
the prctl() in the first place.

-- 
Rémi Denis-Courmont
http://www.remlab.net/