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

Rémi Denis-Courmont
2023-05-21T05:27:38Z

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