2026-09-24T06:38:17-04:00, Guodong Xu <[email protected]>: > On Mon, 21 Sep 2026 16:24:53 +0200, Heinrich Schuchardt wrote: >> On 9/20/26 09:18, Guodong Xu wrote: >>> [ ... ] >>> __RISCV_ISA_EXT_DATA(q, RISCV_ISA_EXT_Q), >>> __RISCV_ISA_EXT_SUPERSET(c, RISCV_ISA_EXT_C, riscv_c_exts), >>> + __RISCV_ISA_EXT_SUPERSET(b, RISCV_ISA_EXT_B, riscv_b_exts), >> >> Hello Guodong, >> >> The RISC-V Unpriviledged ISA specification has this description of >> extension B: >> >> "The B standard extension comprises instructions provided by the Zba, >> Zbb, and Zbs extensions." >> >> __RISCV_ISA_EXT_SUPERSET would imply that something else but >> riscv_b_exts is in B. But such an extra seems not to exist. >> >> So shouldn't __RISCV_ISA_EXT_BUNDLE be used here? Some code further >> change may be needed to set extension B if riscv_b_exts is fulfilled. > > Thanks for the review. Intentional, and the difference between the two > macros is whether the extension gets a bit of its own. > > __RISCV_ISA_EXT_BUNDLE carries RISCV_ISA_EXT_INVALID as its id: parsing > the name only sets the bits of its parts. That fits zk, zkn names, which > are shorthands with no identity of their own beyond the ISA string. > > B is different: it is a single-letter standard extension with its own > misa bit (in the same way as A), and AT_HWCAP on RISC-V is the bitmask > of exactly those single letters, so the kernel needs a bit for B itself. > > A is declared the same way; with the spec defines A in the same words as > B. If I can take that as a precedence. > > IMHO, "superset" in this table means "also sets these subset bits", not > "contains something extra".
Zba, Zbb, and Zbs are equivalent to B for our purposes. Are we sure that B will always be listed in the ISA string when Zba, Zbb, and Zbs are present? We could incorrectly lose RVA23U64 bit otherwise, and I think this was Heinrich's concern as well... (The "A" extension has the same issue...) Thanks.
