Re: [RFC PATCH v1 04/11] riscv: Add B to hwcap

[Guodong Xu]

On Wed, Feb 25, 2026 at 7:05 AM Andrew Jones
<andrew.jones@xxxxxxxxxxxxxxxx> wrote:
>
> On Sat, Feb 21, 2026 at 06:49:18PM +0800, Guodong Xu wrote:
> > Hi, Drew
> >
> > On Fri, Feb 6, 2026 at 8:24 AM Andrew Jones
> > <andrew.jones@xxxxxxxxxxxxxxxx> wrote:
> > >
> > > Add B to hwcap and ensure when B is present that Zba, Zbb, and Zbs
> > > are all set.
> > >
> > > Signed-off-by: Andrew Jones <andrew.jones@xxxxxxxxxxxxxxxx>
> > > ---
> > >  arch/riscv/include/asm/hwcap.h      | 1 +
> > >  arch/riscv/include/uapi/asm/hwcap.h | 1 +
> > >  arch/riscv/kernel/cpufeature.c      | 8 ++++++++
> > >  3 files changed, 10 insertions(+)
> >
> > I saw you chose not to add B to hwprobe in this series, per
> > your review of my patch [1]. I have a different opinion.
> >
> > As you said, FD, C, and V are all exported through both hwcap
> > and hwprobe. Adding B to hwprobe too keeps things consistent,
> > users can query all the single-letter extensions from one
> > interface without needing to know that B is missing in hwprobe
> > and that they'd have to check Zba/Zbb/Zbs to infer B support.
> >
> > Relying on the rva23u64 base bit to imply B also doesn't cover
> > chips that implement B without being rva23u64 compliant. Eg. my
> > patchset [2] adds support for existing (non-rva23u64) SoCs.
> >
>
> I think we need to come up with some sort of policy as to what goes to
> hwprobe and what doesn't. IMO, hwcap is easy. If RISC-V defines a single
> letter extension, such as V or B, then we should add it to hwcap. However,

When we export an extension through hwcap but it cannot
be queried through hwprobe, we create an inconsistency:
the same extension is discoverable through one interface
but not the other.

The current kernel already exposes other single-letter
extensions through both interfaces:

  F+D: RISCV_HWPROBE_IMA_FD + COMPAT_HWCAP_ISA_F/_D
  C:   RISCV_HWPROBE_IMA_C  + COMPAT_HWCAP_ISA_C
  V:   RISCV_HWPROBE_IMA_V  + COMPAT_HWCAP_ISA_V

(I/M/A are folded into RISCV_HWPROBE_BASE_BEHAVIOR_IMA,
so they are a separate case.)

F, D, C, and V are consistent between hwcap and hwprobe.
Why should B be different?

> for hwprobe, we can go two ways:
>
>  1. Add every extension, including 'bundle' extensions, which are nothing
>  more than an alias for a collection of extensions. This includes single
>  letter bundle extensions like B.
>
>  2. Add only unique extensions, i.e. no purely bundle extensions get
>  added.
>
> If we go with (2), then userspace will need to use the base behaviors
> (profiles) in order to get any sort of bundling, but I think most people
> agree that userspace will target profiles, so (2) seems sufficient. I'm


Looking at existing code, cpufeature.c follows option (2)
for bundle extensions. Zk has no hwprobe bit. The
community settled on this in 2023 [1], and I respect
that decision.

The kernel has two families of bundles today: the Zk
series (Zk, Zkn, Zks) and the Zvk series (Zvkn, Zvknc,
Zvkng, Zvks, Zvksc, Zvksg). All use
__RISCV_ISA_EXT_BUNDLE(). Two things to note:

1) They are all multi-letter extensions.
2) Bundle extensions have no valid ext id, so userspace
cannot query them through hwprobe. To determine
"Zk" support, a user must check all 8 sub-extensions
individually.

B is different.

In your patch and mine, we both define B as a superset,
not a bundle:

+ __RISCV_ISA_EXT_SUPERSET(b, RISCV_ISA_EXT_B,
riscv_b_exts),

>From a spec perspective, B adds no new functionality
beyond Zba + Zbb + Zbs. The only thing B adds is a misa
bit (m-mode CSR 0x301, not visible to S-mode or U-mode).
So functionally it looks like a bundle.

But can we change B to __RISCV_ISA_EXT_BUNDLE()? I do
not think so. A bundle has id = RISCV_ISA_EXT_INVALID,
which means no bit in the ISA bitmap. The isa2hwcap[]
mapping in riscv_fill_hwcap() requires a valid ext id
to set COMPAT_HWCAP_ISA_B into elf_hwcap. Without it,
AT_HWCAP support for B breaks, and we would need a
special hack. That is unnecessary complexity.

The existing Zk/Zvk bundles work as bundles because they
are multi-letter extensions with no AT_HWCAP presence.
B lives in both worlds.

[1] https://lore.kernel.org/all/20231012-darkness-neutron-fc1843ff05ff@spud/

> not sure about applications that won't target profiles but will want to
> check for bundle extensions rather than individual extensions. Should we
> take on the maintenance burden of adding each bundle extension to hwprobe
> for those? In particular, I'm not sure about B, because it's already
> available independently of a base behavior (profile) through hwcap.
>

In summary, my comments are:

1. F, D, C, and V are detectable from both hwcap and
   hwprobe. B should follow the same pattern. Dropping
   B from hwprobe while keeping it in hwcap creates a
   gap that will confuse users.

2. B is functionally a bundle (the misa B bit at 0x301
   is m-mode only, not visible to S-mode or U-mode),
   yet we declare it as __RISCV_ISA_EXT_SUPERSET()
   because it needs a valid ext id for AT_HWCAP. I
   suggest we document this with a comment in
   cpufeature.c:

+ /*
+  * B is functionally a bundle (Zba + Zbb + Zbs,
+  * no additional instructions). We use SUPERSET
+  * instead of BUNDLE because B needs a valid ext
+  * id for isa2hwcap[] to set COMPAT_HWCAP_ISA_B.
+  */
+   __RISCV_ISA_EXT_SUPERSET(b, RISCV_ISA_EXT_B, riscv_b_exts),

3. Should we also document in .rst or (in cpufeature.c) about when to use
_BUNDLE() and when to use _SUPERSET(), and what's the implication when
using them, to echo what you stated above "... Add only unique
extensions, i.e. no purely bundle extensions getadded."

BR,
Guodong

> Thanks,
> drew