From: Sergey Matyukevich <geomatsi@gmail.com>
To: Andy Chiu <andybnac@gmail.com>
Cc: Jonathan Corbet <corbet@lwn.net>, Paul Walmsley <pjw@kernel.org>,
Palmer Dabbelt <palmer@dabbelt.com>,
Albert Ou <aou@eecs.berkeley.edu>,
Alexandre Ghiti <alex@ghiti.fr>,
Charlie Jenkins <charlie@rivosinc.com>,
Conor Dooley <conor.dooley@microchip.com>,
Andrew Jones <ajones@ventanamicro.com>,
linux-riscv@lists.infradead.org, linux-doc@vger.kernel.org,
linux-kernel@vger.kernel.org
Subject: Re: [PATCH] riscv: hwprobe: expose vector register length in bytes
Date: Mon, 8 Dec 2025 23:35:53 +0300 [thread overview]
Message-ID: <aTc2qaf6JxBPLvtH@curiosity> (raw)
In-Reply-To: <CAFTtA3NVd8HMomd60i=T_S34TSL18==aYRFhg2AH-PbsM=hggw@mail.gmail.com>
Hi Andy
On Wed, Dec 03, 2025 at 11:57:06AM -0600, Andy Chiu wrote:
> Hi Sergey,
>
> On Fri, Nov 21, 2025 at 1:37 PM Sergey Matyukevich <geomatsi@gmail.com> wrote:
> >
> > The vector register length can be obtained from the read-only CSR vlenb.
> > However reading this CSR may be undesirable in some cases. XTheadVector
> > extension is one example: existing implementations may not provide this
> > register. On such platforms, vlenb is specified as device-tree property.
>
> I wonder why a hwprobe entry is needed even in this context. If vlenb
> is not available, we can always use a vsetvli and read the destination
> register to infer register length. Isn't that also true for Vector
> 0.7, or are you considering anything else?
Sure, reading vsetvli works for XTheadVector as well. The primary reason
for the new hwprobe key is convenience. Vector 1.0 and XTheadVector have
some differences that complicate that sort of autodetection. For instance,
an older encoding for vsetvli. Good examples are vstate save and restore
functions in `arch/riscv/include/asm/vector.h`. Using hwprobe seems more
convenient than using vector-or-xtheadvector logic with custom opcods,
especially since the kernel already has all the necessary information.
> > Reading vlenb also initializes the application’s vector context, even
> > though the application may decide not to use the vector extension based
> > on the reported length.
> >
> > Meanwhile the kernel already determines vlenb at boot, either from the
> > CSR or from the device tree. So add RISCV_HWPROBE_KEY_VECTOR_REG_LENGTH
> > to expose the vector register length already known to the kernel.
> >
> > Signed-off-by: Sergey Matyukevich <geomatsi@gmail.com>
> > ---
> > Documentation/arch/riscv/hwprobe.rst | 3 +++
> > arch/riscv/include/asm/hwprobe.h | 2 +-
> > arch/riscv/include/uapi/asm/hwprobe.h | 1 +
> > arch/riscv/kernel/sys_hwprobe.c | 6 ++++++
> > 4 files changed, 11 insertions(+), 1 deletion(-)
[snip]...
> Thanks,
> Andy
Regards,
Sergey
prev parent reply other threads:[~2025-12-08 20:35 UTC|newest]
Thread overview: 3+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-11-21 19:35 [PATCH] riscv: hwprobe: expose vector register length in bytes Sergey Matyukevich
2025-12-03 17:57 ` Andy Chiu
2025-12-08 20:35 ` Sergey Matyukevich [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=aTc2qaf6JxBPLvtH@curiosity \
--to=geomatsi@gmail.com \
--cc=ajones@ventanamicro.com \
--cc=alex@ghiti.fr \
--cc=andybnac@gmail.com \
--cc=aou@eecs.berkeley.edu \
--cc=charlie@rivosinc.com \
--cc=conor.dooley@microchip.com \
--cc=corbet@lwn.net \
--cc=linux-doc@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-riscv@lists.infradead.org \
--cc=palmer@dabbelt.com \
--cc=pjw@kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).