Re: [PATCH v3 08/15] riscv: Add Zic64b to cpufeature and hwprobe

[Conor Dooley <conor@kernel.org>]

[-- Attachment #1: Type: text/plain, Size: 2743 bytes --]

On Thu, Jun 04, 2026 at 09:31:36PM -0400, Guodong Xu wrote:
> On 2026-06-04 10:17, Conor Dooley wrote:
> > On Thu, Jun 04, 2026 at 02:42:22PM +0800, Guodong Xu wrote:
> > > On Wed, Jun 3, 2026 at 7:28 AM <sashiko-bot@kernel.org> wrote:
> > > >
> > > > > @@ -154,6 +154,23 @@ static int riscv_ext_zicbop_validate(const struct riscv_isa_ext_data *data,
> > > > >       return 0;
> > > > >  }
> > > > >
> > > > > +static int riscv_ext_zic64b_validate(const struct riscv_isa_ext_data *data,
> > > > > +                                  const unsigned long *isa_bitmap)
> > > > > +{
> > > > > +     /*
> > > > > +      * Zic64b mandates 64-byte naturally aligned cache blocks; cross-check the
> > > > > +      * cbom/cbop/cboz block-size device-tree properties to avoid inconsistency.
> > > > > +      */
> > > > > +     if (riscv_cbom_block_size != 64 ||
> > > > > +         riscv_cbop_block_size != 64 ||
> > > > > +         riscv_cboz_block_size != 64) {
> > > >
> > > > [Severity: Medium]
> > > > Will this check erroneously disable Zic64b if a platform does not implement
> > > > all three CBO extensions?
> > > 
> > > Zic64b is mandatory in RVA22/RVA23, which also mandate Zicbom,
> > > Zicbop and Zicboz, so all three block sizes must be present on any Zic64b
> > > platform.
> > 
> > Where do you get that conclusion from? That's not how we treat any other
> > extension defined in the profiles spec. My understanding was that even
> > if things are defined in the profiles spec that they're fair game for
> > independent use.
> 
> Ok, I get your point. Agree, Zic64b/Zicbom/cbop/cboz can be implemented
> on each hart independently (at least spec doesn't say no). With this in
> mind, the validation of Zic64b should be like this:
> 
>     if ((riscv_cbom_block_size && riscv_cbom_block_size != 64) ||
>        (riscv_cbop_block_size && riscv_cbop_block_size != 64) ||
>        (riscv_cboz_block_size && riscv_cboz_block_size != 64))

Or you could check for the extension instead of the left-hand sides
here, but I think that becomes more complex because you need to start
returning EPROBE_DEFER sometimes etc.

>     return -EINVAL;
> 
> This will allow :
> 1. A Zic64b hart with 0, 1, 2, or 3 CBO extension and block_size 64
>    passes the validation.

I'm not too worried about the 0 case here, people shouldn't be using
zic64b if they don't have a corresponding extension after all.

> 2. A Zic64b hart with CBO extensions but block_size is not 64
>    fails the validation
> 
> Thanks for the catch.
> 
> I will fix that in v4.

btw, can you fix your system time? It's like 12 hours in the future and
that impacts the timestamps on emails you send.

Cheers,
Conor.

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 228 bytes --]