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

[Radim Krčmář]

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.)

I think this check is adding a bit of sanity, although the platforms
where it comes into play are already very wild.

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.