2026-09-20T03:18:31-04:00, Guodong Xu <[email protected]>: > Provide a hwprobe base-behavior bit so userspace can check RVA23U64 > support in one call. Without it, a consumer needs five hwprobe > calls and four prctl calls, which is error-prone to require of every > caller. Most software treats RVA23U64 as a new base anyway, so > expose it directly. > > The IMA bit is now derived from the same cached bases instead of being > hardcoded, so it agrees with AT_HWCAP and the "isa bases" cpuinfo lines; > on any system this kernel can run on it stays set. > > Co-developed-by: Andrew Jones <[email protected]> > Signed-off-by: Andrew Jones <[email protected]> > Signed-off-by: Guodong Xu <[email protected]> > --- > index 8a38a4d37806f..2290126792797 100644 > +static bool hwprobe_has_isa_base(const struct cpumask *cpus, unsigned int > base) > +{ > + 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. Is there a reason to diverge from how hwprobe_isa_ext0() does the extension detection? (has_fpu() and other global checks) Thanks.
