[PATCH v1] riscv: cpufeature: Add Zic64b ISA extension support

[PATCH v1] riscv: cpufeature: Add Zic64b ISA extension support

[Qingwei Hu]

Zic64b describes a platform with 64-byte cache block sizes. It is a
mandatory part of RVA23U64, but a system may provide 64-byte CMO block
sizes without satisfying all profile requirements.

The ISA string parser currently ignores Zic64b because the extension is
not present in the cpufeature table. Add an ISA extension ID and table
entry for Zic64b so it can be reported in /proc/cpuinfo when firmware
advertises it.

Validate the entry against the CBO block sizes discovered from firmware.
Only check CBO block sizes that are present, since Zic64b constrains
implemented CBO extensions to use 64-byte blocks but does not require all
CBO extensions to exist.

Signed-off-by: Qingwei Hu <qingwei.hu@bytedance.com>
---
 arch/riscv/include/asm/hwcap.h |  1 +
 arch/riscv/kernel/cpufeature.c | 14 ++++++++++++++
 2 files changed, 15 insertions(+)

diff --git a/arch/riscv/include/asm/hwcap.h b/arch/riscv/include/asm/hwcap.h
index 7ef8e5f55c8d..b17cae75c295 100644
--- a/arch/riscv/include/asm/hwcap.h
+++ b/arch/riscv/include/asm/hwcap.h
@@ -112,6 +112,7 @@
 #define RISCV_ISA_EXT_ZCLSD		103
 #define RISCV_ISA_EXT_ZICFILP		104
 #define RISCV_ISA_EXT_ZICFISS		105
+#define RISCV_ISA_EXT_ZIC64B		106
 
 #define RISCV_ISA_EXT_XLINUXENVCFG	127
 
diff --git a/arch/riscv/kernel/cpufeature.c b/arch/riscv/kernel/cpufeature.c
index f46aa5602d74..510ea6aa66ae 100644
--- a/arch/riscv/kernel/cpufeature.c
+++ b/arch/riscv/kernel/cpufeature.c
@@ -136,6 +136,19 @@ 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)
+{
+	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)) {
+		pr_err("Zic64b detected in ISA string, disabling as a present CBO block size is not 64 bytes\n");
+		return -EINVAL;
+	}
+
+	return 0;
+}
+
 static int riscv_ext_f_validate(const struct riscv_isa_ext_data *data,
 				const unsigned long *isa_bitmap)
 {
@@ -499,6 +512,7 @@ const struct riscv_isa_ext_data riscv_isa_ext[] = {
 	__RISCV_ISA_EXT_SUPERSET(c, RISCV_ISA_EXT_c, riscv_c_exts),
 	__RISCV_ISA_EXT_SUPERSET_VALIDATE(v, RISCV_ISA_EXT_v, riscv_v_exts, riscv_ext_vector_float_validate),
 	__RISCV_ISA_EXT_DATA(h, RISCV_ISA_EXT_h),
+	__RISCV_ISA_EXT_DATA_VALIDATE(zic64b, RISCV_ISA_EXT_ZIC64B, riscv_ext_zic64b_validate),
 	__RISCV_ISA_EXT_SUPERSET_VALIDATE(zicbom, RISCV_ISA_EXT_ZICBOM, riscv_xlinuxenvcfg_exts, riscv_ext_zicbom_validate),
 	__RISCV_ISA_EXT_DATA_VALIDATE(zicbop, RISCV_ISA_EXT_ZICBOP, riscv_ext_zicbop_validate),
 	__RISCV_ISA_EXT_SUPERSET_VALIDATE(zicboz, RISCV_ISA_EXT_ZICBOZ, riscv_xlinuxenvcfg_exts, riscv_ext_zicboz_validate),

base-commit: e7ae89a0c97ce2b68b0983cd01eda67cf373517d
-- 
2.39.5

Re: [PATCH v1] riscv: cpufeature: Add Zic64b ISA extension support

[Vivian Wang]

On 5/28/26 22:16, Qingwei Hu wrote:
> Zic64b describes a platform with 64-byte cache block sizes. It is a
> mandatory part of RVA23U64, but a system may provide 64-byte CMO block
> sizes without satisfying all profile requirements.
>
> The ISA string parser currently ignores Zic64b because the extension is
> not present in the cpufeature table. Add an ISA extension ID and table
> entry for Zic64b so it can be reported in /proc/cpuinfo when firmware
> advertises it.

I'd like to understand: What is the motivation to doing this, given that
the very same information is already available as riscv,cbo*-block-size
and hwprobe?

> Validate the entry against the CBO block sizes discovered from firmware.
> Only check CBO block sizes that are present, since Zic64b constrains
> implemented CBO extensions to use 64-byte blocks but does not require all
> CBO extensions to exist.
>
> Signed-off-by: Qingwei Hu <qingwei.hu@bytedance.com>
> ---
>  arch/riscv/include/asm/hwcap.h |  1 +
>  arch/riscv/kernel/cpufeature.c | 14 ++++++++++++++
>  2 files changed, 15 insertions(+)
>
> diff --git a/arch/riscv/include/asm/hwcap.h b/arch/riscv/include/asm/hwcap.h
> index 7ef8e5f55c8d..b17cae75c295 100644
> --- a/arch/riscv/include/asm/hwcap.h
> +++ b/arch/riscv/include/asm/hwcap.h
> @@ -112,6 +112,7 @@
>  #define RISCV_ISA_EXT_ZCLSD		103
>  #define RISCV_ISA_EXT_ZICFILP		104
>  #define RISCV_ISA_EXT_ZICFISS		105
> +#define RISCV_ISA_EXT_ZIC64B		106
>  
>  #define RISCV_ISA_EXT_XLINUXENVCFG	127
>  
> diff --git a/arch/riscv/kernel/cpufeature.c b/arch/riscv/kernel/cpufeature.c
> index f46aa5602d74..510ea6aa66ae 100644
> --- a/arch/riscv/kernel/cpufeature.c
> +++ b/arch/riscv/kernel/cpufeature.c
> @@ -136,6 +136,19 @@ 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)
> +{
> +	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)) {
> +		pr_err("Zic64b detected in ISA string, disabling as a present CBO block size is not 64 bytes\n");
> +		return -EINVAL;
> +	}
> +
> +	return 0;
> +}
> +
>  static int riscv_ext_f_validate(const struct riscv_isa_ext_data *data,
>  				const unsigned long *isa_bitmap)
>  {
> @@ -499,6 +512,7 @@ const struct riscv_isa_ext_data riscv_isa_ext[] = {
>  	__RISCV_ISA_EXT_SUPERSET(c, RISCV_ISA_EXT_c, riscv_c_exts),
>  	__RISCV_ISA_EXT_SUPERSET_VALIDATE(v, RISCV_ISA_EXT_v, riscv_v_exts, riscv_ext_vector_float_validate),
>  	__RISCV_ISA_EXT_DATA(h, RISCV_ISA_EXT_h),
> +	__RISCV_ISA_EXT_DATA_VALIDATE(zic64b, RISCV_ISA_EXT_ZIC64B, riscv_ext_zic64b_validate),
>  	__RISCV_ISA_EXT_SUPERSET_VALIDATE(zicbom, RISCV_ISA_EXT_ZICBOM, riscv_xlinuxenvcfg_exts, riscv_ext_zicbom_validate),
>  	__RISCV_ISA_EXT_DATA_VALIDATE(zicbop, RISCV_ISA_EXT_ZICBOP, riscv_ext_zicbop_validate),
>  	__RISCV_ISA_EXT_SUPERSET_VALIDATE(zicboz, RISCV_ISA_EXT_ZICBOZ, riscv_xlinuxenvcfg_exts, riscv_ext_zicboz_validate),

If an extension is what we want to go with, then
Documentation/devicetree/bindings/riscv/extensions.yaml also needs
updating to match.

Vivian "dramforever" Wang

Re: [PATCH v1] riscv: cpufeature: Add Zic64b ISA extension support

[Qingwei Hu]

Hi Vivian,

Thanks for the feedback.

> On May 29, 2026, at 11:14, Vivian Wang <wangruikang@iscas.ac.cn> wrote:
> 
> On 5/28/26 22:16, Qingwei Hu wrote:
>> Zic64b describes a platform with 64-byte cache block sizes. It is a
>> mandatory part of RVA23U64, but a system may provide 64-byte CMO block
>> sizes without satisfying all profile requirements.
>> 
>> The ISA string parser currently ignores Zic64b because the extension is
>> not present in the cpufeature table. Add an ISA extension ID and table
>> entry for Zic64b so it can be reported in /proc/cpuinfo when firmware
>> advertises it.
> 
> I'd like to understand: What is the motivation to doing this, given that
> the very same information is already available as riscv,cbo*-block-size
> and hwprobe?

The motivation here is not to replace riscv,cbo*-block-size or hwprobe.
Those are still the right interfaces for software that needs the actual
CBO block size.

This is more about preserving the ISA extension name reported by
firmware. Some platforms report zic64b in the ISA string, but Linux
currently drops it because there is no cpufeature entry, so cpuinfo no
longer matches what firmware advertised. That makes profile/ISA-string
comparison tools a bit awkward.

So the patch only makes zic64b visible as a named ISA extension when
firmware reports it, while still validating it against any CBO block
sizes that firmware provides.

> If an extension is what we want to go with, then
> Documentation/devicetree/bindings/riscv/extensions.yaml also needs
> updating to match.

And yes, if we keep this direction, I agree extensions.yaml should be
updated in v2.

Thanks,
Qingwei Hu

Re: [PATCH v1] riscv: cpufeature: Add Zic64b ISA extension support

[Conor Dooley]

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

On Sat, May 30, 2026 at 11:36:11AM +0800, Qingwei Hu wrote:
> Hi Vivian,
> 
> Thanks for the feedback.
> 
> > On May 29, 2026, at 11:14, Vivian Wang <wangruikang@iscas.ac.cn> wrote:
> > 
> > On 5/28/26 22:16, Qingwei Hu wrote:
> >> Zic64b describes a platform with 64-byte cache block sizes. It is a
> >> mandatory part of RVA23U64, but a system may provide 64-byte CMO block
> >> sizes without satisfying all profile requirements.
> >> 
> >> The ISA string parser currently ignores Zic64b because the extension is
> >> not present in the cpufeature table. Add an ISA extension ID and table
> >> entry for Zic64b so it can be reported in /proc/cpuinfo when firmware
> >> advertises it.
> > 
> > I'd like to understand: What is the motivation to doing this, given that
> > the very same information is already available as riscv,cbo*-block-size
> > and hwprobe?
> 
> The motivation here is not to replace riscv,cbo*-block-size or hwprobe.
> Those are still the right interfaces for software that needs the actual
> CBO block size.
> 
> This is more about preserving the ISA extension name reported by
> firmware. Some platforms report zic64b in the ISA string, but Linux
> currently drops it because there is no cpufeature entry, so cpuinfo no
> longer matches what firmware advertised. That makes profile/ISA-string
> comparison tools a bit awkward.
> 
> So the patch only makes zic64b visible as a named ISA extension when
> firmware reports it, while still validating it against any CBO block
> sizes that firmware provides.
> 
> > If an extension is what we want to go with, then
> > Documentation/devicetree/bindings/riscv/extensions.yaml also needs
> > updating to match.
> 
> And yes, if we keep this direction, I agree extensions.yaml should be
> updated in v2.

And make sure that having zic64b makes the cbo*-block-size properties
mandatory so that people don't confuse themselves and omit them and
wonder why stuff doesn't work.

Does zic64b mean that all of the zicbo* extensions are supported, or
does it just mean that the supported ones use 64-byte block sizes?
The answer to that will impact how you make the cbo*-block-size
properties mandatory.

Cheers,
Conor.

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

Re: [PATCH v1] riscv: cpufeature: Add Zic64b ISA extension support

[Qingwei Hu]

> On May 31, 2026, at 07:09, Conor Dooley <conor@kernel.org> wrote:
> 
> On Sat, May 30, 2026 at 11:36:11AM +0800, Qingwei Hu wrote:
>> Hi Vivian,
>> 
>> Thanks for the feedback.
>> 
>>> On May 29, 2026, at 11:14, Vivian Wang <wangruikang@iscas.ac.cn> wrote:
>>> 
>>> On 5/28/26 22:16, Qingwei Hu wrote:
>>>> Zic64b describes a platform with 64-byte cache block sizes. It is a
>>>> mandatory part of RVA23U64, but a system may provide 64-byte CMO block
>>>> sizes without satisfying all profile requirements.
>>>> 
>>>> The ISA string parser currently ignores Zic64b because the extension is
>>>> not present in the cpufeature table. Add an ISA extension ID and table
>>>> entry for Zic64b so it can be reported in /proc/cpuinfo when firmware
>>>> advertises it.
>>> 
>>> I'd like to understand: What is the motivation to doing this, given that
>>> the very same information is already available as riscv,cbo*-block-size
>>> and hwprobe?
>> 
>> The motivation here is not to replace riscv,cbo*-block-size or hwprobe.
>> Those are still the right interfaces for software that needs the actual
>> CBO block size.
>> 
>> This is more about preserving the ISA extension name reported by
>> firmware. Some platforms report zic64b in the ISA string, but Linux
>> currently drops it because there is no cpufeature entry, so cpuinfo no
>> longer matches what firmware advertised. That makes profile/ISA-string
>> comparison tools a bit awkward.
>> 
>> So the patch only makes zic64b visible as a named ISA extension when
>> firmware reports it, while still validating it against any CBO block
>> sizes that firmware provides.
>> 
>>> If an extension is what we want to go with, then
>>> Documentation/devicetree/bindings/riscv/extensions.yaml also needs
>>> updating to match.
>> 
>> And yes, if we keep this direction, I agree extensions.yaml should be
>> updated in v2.
> 
> And make sure that having zic64b makes the cbo*-block-size properties
> mandatory so that people don't confuse themselves and omit them and
> wonder why stuff doesn't work.
> 
> Does zic64b mean that all of the zicbo* extensions are supported, or
> does it just mean that the supported ones use 64-byte block sizes?
> The answer to that will impact how you make the cbo*-block-size
> properties mandatory.
> 
> Cheers,
> Conor.

Thanks, I will check this with the RISC-V unprivileged/ISA folks first,
and then handle the binding accordingly in v2.

Re: [PATCH v1] riscv: cpufeature: Add Zic64b ISA extension support

[Conor Dooley]

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

On Wed, Jun 03, 2026 at 08:32:14PM +0800, Qingwei Hu wrote:
> 
> 
> > On May 31, 2026, at 07:09, Conor Dooley <conor@kernel.org> wrote:
> > 
> > On Sat, May 30, 2026 at 11:36:11AM +0800, Qingwei Hu wrote:
> >> Hi Vivian,
> >> 
> >> Thanks for the feedback.
> >> 
> >>> On May 29, 2026, at 11:14, Vivian Wang <wangruikang@iscas.ac.cn> wrote:
> >>> 
> >>> On 5/28/26 22:16, Qingwei Hu wrote:
> >>>> Zic64b describes a platform with 64-byte cache block sizes. It is a
> >>>> mandatory part of RVA23U64, but a system may provide 64-byte CMO block
> >>>> sizes without satisfying all profile requirements.
> >>>> 
> >>>> The ISA string parser currently ignores Zic64b because the extension is
> >>>> not present in the cpufeature table. Add an ISA extension ID and table
> >>>> entry for Zic64b so it can be reported in /proc/cpuinfo when firmware
> >>>> advertises it.
> >>> 
> >>> I'd like to understand: What is the motivation to doing this, given that
> >>> the very same information is already available as riscv,cbo*-block-size
> >>> and hwprobe?
> >> 
> >> The motivation here is not to replace riscv,cbo*-block-size or hwprobe.
> >> Those are still the right interfaces for software that needs the actual
> >> CBO block size.
> >> 
> >> This is more about preserving the ISA extension name reported by
> >> firmware. Some platforms report zic64b in the ISA string, but Linux
> >> currently drops it because there is no cpufeature entry, so cpuinfo no
> >> longer matches what firmware advertised. That makes profile/ISA-string
> >> comparison tools a bit awkward.
> >> 
> >> So the patch only makes zic64b visible as a named ISA extension when
> >> firmware reports it, while still validating it against any CBO block
> >> sizes that firmware provides.
> >> 
> >>> If an extension is what we want to go with, then
> >>> Documentation/devicetree/bindings/riscv/extensions.yaml also needs
> >>> updating to match.
> >> 
> >> And yes, if we keep this direction, I agree extensions.yaml should be
> >> updated in v2.
> > 
> > And make sure that having zic64b makes the cbo*-block-size properties
> > mandatory so that people don't confuse themselves and omit them and
> > wonder why stuff doesn't work.
> > 
> > Does zic64b mean that all of the zicbo* extensions are supported, or
> > does it just mean that the supported ones use 64-byte block sizes?
> > The answer to that will impact how you make the cbo*-block-size
> > properties mandatory.
> > 
> > Cheers,
> > Conor.
> 
> Thanks, I will check this with the RISC-V unprivileged/ISA folks first,
> and then handle the binding accordingly in v2.

I noticed that there's another series that's adding zic64b support:
https://lore.kernel.org/all/20260603-rva23u64-hwprobe-v2-v3-0-5529a7b28384@gmail.com/

Probably you should coordinate with Guodong, as your zic64b effort seems
to predate theirs.

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

Re: [External] [PATCH v1] riscv: cpufeature: Add Zic64b ISA extension support

[Qingwei Hu]

> On Jun 3, 2026, at 21:17, Conor Dooley <conor@kernel.org> wrote:
> 
> On Wed, Jun 03, 2026 at 08:32:14PM +0800, Qingwei Hu wrote:
>> 
>> 
>>> On May 31, 2026, at 07:09, Conor Dooley <conor@kernel.org> wrote:
>>> 
>>> On Sat, May 30, 2026 at 11:36:11AM +0800, Qingwei Hu wrote:
>>>> Hi Vivian,
>>>> 
>>>> Thanks for the feedback.
>>>> 
>>>>> On May 29, 2026, at 11:14, Vivian Wang <wangruikang@iscas.ac.cn> wrote:
>>>>> 
>>>>> On 5/28/26 22:16, Qingwei Hu wrote:
>>>>>> Zic64b describes a platform with 64-byte cache block sizes. It is a
>>>>>> mandatory part of RVA23U64, but a system may provide 64-byte CMO block
>>>>>> sizes without satisfying all profile requirements.
>>>>>> 
>>>>>> The ISA string parser currently ignores Zic64b because the extension is
>>>>>> not present in the cpufeature table. Add an ISA extension ID and table
>>>>>> entry for Zic64b so it can be reported in /proc/cpuinfo when firmware
>>>>>> advertises it.
>>>>> 
>>>>> I'd like to understand: What is the motivation to doing this, given that
>>>>> the very same information is already available as riscv,cbo*-block-size
>>>>> and hwprobe?
>>>> 
>>>> The motivation here is not to replace riscv,cbo*-block-size or hwprobe.
>>>> Those are still the right interfaces for software that needs the actual
>>>> CBO block size.
>>>> 
>>>> This is more about preserving the ISA extension name reported by
>>>> firmware. Some platforms report zic64b in the ISA string, but Linux
>>>> currently drops it because there is no cpufeature entry, so cpuinfo no
>>>> longer matches what firmware advertised. That makes profile/ISA-string
>>>> comparison tools a bit awkward.
>>>> 
>>>> So the patch only makes zic64b visible as a named ISA extension when
>>>> firmware reports it, while still validating it against any CBO block
>>>> sizes that firmware provides.
>>>> 
>>>>> If an extension is what we want to go with, then
>>>>> Documentation/devicetree/bindings/riscv/extensions.yaml also needs
>>>>> updating to match.
>>>> 
>>>> And yes, if we keep this direction, I agree extensions.yaml should be
>>>> updated in v2.
>>> 
>>> And make sure that having zic64b makes the cbo*-block-size properties
>>> mandatory so that people don't confuse themselves and omit them and
>>> wonder why stuff doesn't work.
>>> 
>>> Does zic64b mean that all of the zicbo* extensions are supported, or
>>> does it just mean that the supported ones use 64-byte block sizes?
>>> The answer to that will impact how you make the cbo*-block-size
>>> properties mandatory.
>>> 
>>> Cheers,
>>> Conor.
>> 
>> Thanks, I will check this with the RISC-V unprivileged/ISA folks first,
>> and then handle the binding accordingly in v2.
> 
> I noticed that there's another series that's adding zic64b support:
> https://lore.kernel.org/all/20260603-rva23u64-hwprobe-v2-v3-0-5529a7b28384@gmail.com/
> 
> Probably you should coordinate with Guodong, as your zic64b effort seems
> to predate theirs.

Thanks Conor.

Yes, I noticed Guodong's series as well. I will coordinate with Guodong
before sending v2, and check whether this should be folded into that
work or kept as a small separate patch.

I will also clarify the intended Zic64b/Zicbo* relationship with the
RISC-V unprivileged/ISA folks before updating the binding.

Best regards,
Qingwei Hu