Re: [PATCH v8 11/11] riscv: hwprobe: Introduce rva23u64 base behavior

[Radim Krcmar <rkrcmar@qti.qualcomm.com>]

2026-10-02T04:40:53-04:00, Guodong Xu <guodong.xu@oss.qualcomm.com>:
> On Tue, 29 Sep 2026 16:00:22 +0000, Radim Krcmar wrote:
>> 2026-09-20T03:18:31-04:00, Guodong Xu <guodong.xu@oss.qualcomm.com>:
>>> [ ... ]
>>> +	int cpu;
>>> +
>>> +	for_each_cpu(cpu, cpus) {
>>> +		if (!riscv_isa_base_available(hart_isa[cpu].isa_bases, base))
>>> +			return false;
>>
>> I think that extensions like F or V might be present in the ISA, yet
>> actually disabled in user-mode and this loop would misreport that
>> RVA23U64 is present.
>
> Only V has a way to be disabled by user-mode, through
> prctl(PR_RISCV_V_SET_CONTROL) with PR_RISCV_V_VSTATE_CTRL_OFF. That
> interface is questionable, and obsoleting it was discussed on the
> RISE Platform WG call on 16 Sep. And I plan to take this to LPC26
> next week in Prague to see what the community says.

Sounds like a good plan.  I'll have to figure out how to an invite to
the RISE meetings again...

> Besides, since you mentioned hwprobe_isa_ext0() below: actually, today's
> per hart hwprobe_isa_ext0() doesn't honor that prctl(V OFF), IMA_V stays
> set. Refer to [1].

Yes, that is an acceptable behavior.  User-mode should know what it does
with prctls, so hwprobe doesn't need to report the prctl affected state.

I meant that there are sstatus.FS/VS, senvcfg, sstateen, and possibly
other bits that control the set of extensions that are present in
user-mode based on variables outside of user-mode's control.

> There is no way for a user-mode application to disable F/D.
>
>> Is there a reason to diverge from how hwprobe_isa_ext0() does the
>> extension detection?  (has_fpu() and other global checks)
>
> Anyway, back to the RVA23U64 isa_base bit. In this design, I mean to
> report the per-hart RVA23U64 base, which is derived from hart_isa[cpu].isa.
> That bitmap has passed the validate callbacks in riscv_resolve_isa(), so
> it "matches kernel configuration as well as correct extension
> dependencies".

Whether kernel is compiled without a support for an extension that needs
to be enabled, or decided to not enable such extension at runtime
(command line parameter or weird platform) makes no difference to
user-mode and hwprobe output should be the same.

> There can be a mismatch on a system with heterogeneous harts, where
> has_fpu() is false globally but this particular hart has F/D. On such
> a system Zfa and Zcd are still reported for that hart today, which is
> the same mismatch. Same reason, because Zfa/Zcd passed validate callbacks
> per hart.

That is the bug.  User-mode can never utilize F, Zfa, and Zcd even on
harts that have those extensions, because sstatus.FS is always Off
without has_fpu().

I'll send patches for Zfa and Zcd in hwprobe_isa_ext0, but since this
series doesn't leverage the existing code, we'll need a fix here too.

> So the isa_base bit RVA23U64 behaves like the per-hart keys do today,
> while IMA_FD, IMA_C and IMA_V at the top of hwprobe_isa_ext0() are
> host-wide. My take is that when user space queries over all CPUs, it
> gets the intersection, where RVA23U64 is not reported in such a
> heterogeneous situation. Per hart, I want to keep the kernel config + ISA
> string truth.

Right, when querying across a subset of harts, user-mode should get the
maximal set of extension that are present on each.

Why we would report RVA23U64 on a hart that doesn't run RVA23U64
user-mode, though?

Thanks.