Re: [PATCH 1/6] riscv: hwprobe: Report FP extensions only when available

From: Charlie Jenkins

Date: Wed Oct 07 2026 - 04:09:51 EST


On Wed, Oct 07, 2026 at 09:46:31AM +0200, Radim Krčmář wrote:
> 2026-10-06T16:54:53-07:00, Charlie Jenkins <thecharlesjenkins@xxxxxxxxx>:
> >> 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@xxxxxxxxxxxxxxxx>
> >>
> >> 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.