2026-10-02T04:40:53-04:00, Guodong Xu <[email protected]>: > On Tue, 29 Sep 2026 16:00:22 +0000, Radim Krcmar wrote: >> 2026-09-20T03:18:31-04:00, Guodong Xu <[email protected]>: >>> [ ... ] >>> + 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.
