Messages in this thread | | | From | Rémi Denis-Courmont <> | Subject | Re: [PATCH -next v20 24/26] riscv: Add documentation for Vector | Date | Sun, 21 May 2023 08:20:39 +0300 |
| |
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/
| |