Hi Radim, 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. 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]. 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". 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. 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. [1] https://lore.kernel.org/linux-riscv/[email protected]/ Guodong
