From: Charlie Jenkins <thecharlesjenkins@gmail.com>
To: "Radim Krčmář" <radim.krcmar@oss.qualcomm.com>
Cc: linux-riscv@lists.infradead.org, linux-kernel@vger.kernel.org,
Paul Walmsley <pjw@kernel.org>,
Palmer Dabbelt <palmer@dabbelt.com>,
Alexandre Ghiti <alex@ghiti.fr>,
Samuel Holland <samuel.holland@sifive.com>,
Andy Chiu <andybnac@gmail.com>, Guodong Xu <guodong@riscstar.com>,
Zong Li <zong.li@sifive.com>
Subject: Re: [PATCH 1/6] riscv: hwprobe: Report FP extensions only when available
Date: Wed, 7 Oct 2026 01:05:19 -0700 [thread overview]
Message-ID: <asX9P5ZEcSUdiuiz@blinky> (raw)
In-Reply-To: <DLYFU3VAEP3D.OTOZB5Y3BADZ@oss.qualcomm.com>
On Wed, Oct 07, 2026 at 09:46:31AM +0200, Radim Krčmář wrote:
> 2026-10-06T16:54:53-07:00, Charlie Jenkins <thecharlesjenkins@gmail.com>:
> >> User-mode use of Zcd, Zcf, Zfa, Zfbfmin, Zfh and Zfhmin requires
> >> non-Off sstatus.FS, which we set only when has_fpu() (CONFIG_FPU and D
> >> on all harts). The vector floating-point extensions Zve32f, Zve64f,
> >> Zve64d, Zvfbfmin, Zvfbfwma, Zvfh and Zvfhmin require it as well, but
> >> hwprobe gates them only on has_vector(). hwprobe otherwise reports the
> >> extensions from the per-hart ISA bitmaps alone, so it can advertise
> >> extensions that are always disabled in user-mode.
> >>
> >> Report correct environment to user-mode.
> >>
> >> Fixes: 2e2cf5581fcc ("riscv: cpufeature: add validation for zfa, zfh and zfhmin")
> >> Fixes: de8f8282a969 ("riscv: hwprobe: add zve Vector subextensions into hwprobe interface")
> >> Fixes: 5dadda5e6a59 ("riscv: hwprobe: export Zvfh[min] ISA extensions")
> >> Signed-off-by: Radim Krčmář <radim.krcmar@oss.qualcomm.com>
> >>
> >> diff --git a/arch/riscv/kernel/sys_hwprobe.c b/arch/riscv/kernel/sys_hwprobe.c
> >> index 7818e1d32622..b57ccd116bb1 100644
> >> --- a/arch/riscv/kernel/sys_hwprobe.c
> >> +++ b/arch/riscv/kernel/sys_hwprobe.c
> >> @@ -146,15 +146,8 @@ static void hwprobe_isa_ext0(struct riscv_hwprobe *pair,
> >> if (has_vector()) {
> >> EXT_KEY(isainfo->isa, ZVBB, pair->value, missing);
> >> EXT_KEY(isainfo->isa, ZVBC, pair->value, missing);
> >> - EXT_KEY(isainfo->isa, ZVE32F, pair->value, missing);
> >> EXT_KEY(isainfo->isa, ZVE32X, pair->value, missing);
> >> - EXT_KEY(isainfo->isa, ZVE64D, pair->value, missing);
> >> - EXT_KEY(isainfo->isa, ZVE64F, pair->value, missing);
> >> EXT_KEY(isainfo->isa, ZVE64X, pair->value, missing);
> >> - EXT_KEY(isainfo->isa, ZVFBFMIN, pair->value, missing);
> >> - EXT_KEY(isainfo->isa, ZVFBFWMA, pair->value, missing);
> >> - EXT_KEY(isainfo->isa, ZVFH, pair->value, missing);
> >> - EXT_KEY(isainfo->isa, ZVFHMIN, pair->value, missing);
> >> EXT_KEY(isainfo->isa, ZVKB, pair->value, missing);
> >> EXT_KEY(isainfo->isa, ZVKG, pair->value, missing);
> >> EXT_KEY(isainfo->isa, ZVKNED, pair->value, missing);
> >> @@ -163,14 +156,26 @@ static void hwprobe_isa_ext0(struct riscv_hwprobe *pair,
> >> EXT_KEY(isainfo->isa, ZVKSED, pair->value, missing);
> >> EXT_KEY(isainfo->isa, ZVKSH, pair->value, missing);
> >> EXT_KEY(isainfo->isa, ZVKT, pair->value, missing);
> >> +
> >> + if (has_fpu()) {
> >> + EXT_KEY(isainfo->isa, ZVE32F, pair->value, missing);
> >> + EXT_KEY(isainfo->isa, ZVE64D, pair->value, missing);
> >> + EXT_KEY(isainfo->isa, ZVE64F, pair->value, missing);
> >> + EXT_KEY(isainfo->isa, ZVFBFMIN, pair->value, missing);
> >> + EXT_KEY(isainfo->isa, ZVFBFWMA, pair->value, missing);
> >> + EXT_KEY(isainfo->isa, ZVFH, pair->value, missing);
> >> + EXT_KEY(isainfo->isa, ZVFHMIN, pair->value, missing);
> >
> > The vector Kconfig is gated on FPU=y so the vector instructions can't
> > ever be enabled when FPU=n.
>
> Right, I'll make the commit message clearer in v2.
> (Zve32x and hence has_vector() can technically exist without CONFIG_FPU,
> so future implementations might require use to remove the dependency.)
Yeah having vector dependent on FPU is not really accurate but since
nobody has built vector hardware without an FPU it hasn't come up yet. I
feel that would be highly unlikely to happen and probably not a good
idea so maybe it won't ever happen...
>
> I think this check is adding a bit of sanity, although the platforms
> where it comes into play are already very wild.
Yeah I agree, it is reasonable to add the check here.
- Charlie
>
> has_fpu()=false and has_vector()=true is possible on heterogenous
> platforms since the filtering/validation of floating vector extensions
> happens on F extension support on that hart alone.
>
> If other hart doesn't support F, all harts will trap floating vector
> extension as mstatus.FS=Off, although scalar vector should still work
> because has_vector() isn't keyed on V support, but only on Zve32x.
>
> Thanks.
next prev parent reply other threads:[~2026-10-07 8:05 UTC|newest]
Thread overview: 13+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-10-06 7:52 [PATCH 0/6] riscv: hwprobe: do not report disabled extensions Radim Krčmář
2026-10-06 7:52 ` [PATCH 1/6] riscv: hwprobe: Report FP extensions only when available Radim Krčmář
2026-10-06 23:54 ` Charlie Jenkins
2026-10-07 7:46 ` Radim Krčmář
2026-10-07 8:05 ` Charlie Jenkins [this message]
2026-10-06 7:52 ` [PATCH 2/6] riscv: hwprobe: Report Zicbom and Zicboz " Radim Krčmář
2026-10-06 7:53 ` [PATCH 3/6] riscv: hwprobe: Report Zicfilp and Zicfiss " Radim Krčmář
2026-10-06 7:53 ` [PATCH 4/6] riscv: hwprobe: Report Supm " Radim Krčmář
2026-10-06 7:53 ` [PATCH 5/6] riscv: hwprobe: Report XTheadVector " Radim Krčmář
2026-10-06 23:54 ` Charlie Jenkins
2026-10-07 7:59 ` Radim Krčmář
2026-10-07 8:07 ` Charlie Jenkins
2026-10-06 7:53 ` [PATCH 6/6] riscv: hwprobe: Report SiFive vector extensions " Radim Krčmář
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=asX9P5ZEcSUdiuiz@blinky \
--to=thecharlesjenkins@gmail.com \
--cc=alex@ghiti.fr \
--cc=andybnac@gmail.com \
--cc=guodong@riscstar.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-riscv@lists.infradead.org \
--cc=palmer@dabbelt.com \
--cc=pjw@kernel.org \
--cc=radim.krcmar@oss.qualcomm.com \
--cc=samuel.holland@sifive.com \
--cc=zong.li@sifive.com \
/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
all inboxes | Powered by JetHome®