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

[Andrew Jones]

On Fri, Mar 06, 2026 at 10:17:19AM +0800, Guodong Xu wrote:
> On Wed, Feb 25, 2026 at 7:05 AM Andrew Jones
> <andrew.jones at oss.qualcomm.com> 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 at oss.qualcomm.com> 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 at oss.qualcomm.com>
> > > > ---
> > > >  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?

Ok, you've sold me. The obvious advantage to applications is that they
don't need to know anything about hwcap at all. hwprobe can be a one-
stop shop.

> 
> > 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),

Looks good.

> 
> 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."

We're probably OK with the comments already in cpufeature.h

/* Used to declare pure "lasso" extension (Zk for instance) */
BUNDLE...
/* Used to declare extensions that are a superset of other extensions (Zvbb for instance) */
SUPERSET...

And your proposed comment above B will also help explain things.

Thanks,
drew