[PATCH v3 1/9] arm64: Repaint ID_AA64MMFR2_EL1.IDS description

Marc Zyngier maz at kernel.org
Thu Dec 4 04:02:46 PST 2025


On Thu, 04 Dec 2025 11:13:41 +0000,
Ben Horgan <ben.horgan at arm.com> wrote:
> 
> Hi Marc,
> 
> On 12/4/25 10:48, Marc Zyngier wrote:
> > On Thu, 04 Dec 2025 10:36:54 +0000,
> > Ben Horgan <ben.horgan at arm.com> wrote:
> >>
> >> Hi Marc,
> >>
> >> On 12/4/25 09:47, Marc Zyngier wrote:
> >>> ID_AA64MMFR2_EL1.IDS, as described in the sysreg file, is pretty horrible
> >>> as it diesctly give the ESR value. Repaint it using the usual NI/IMP
> >>> identifiers to describe the absence/presence of FEAT_IDST.
> >>>
> >>> Signed-off-by: Marc Zyngier <maz at kernel.org>
> >>> ---
> >>>  arch/arm64/kvm/hyp/nvhe/sys_regs.c | 2 +-
> >>>  arch/arm64/tools/sysreg            | 4 ++--
> >>>  2 files changed, 3 insertions(+), 3 deletions(-)
> >>>
> >>> diff --git a/arch/arm64/kvm/hyp/nvhe/sys_regs.c b/arch/arm64/kvm/hyp/nvhe/sys_regs.c
> >>> index 82da9b03692d4..107d62921b168 100644
> >>> --- a/arch/arm64/kvm/hyp/nvhe/sys_regs.c
> >>> +++ b/arch/arm64/kvm/hyp/nvhe/sys_regs.c
> >>> @@ -134,7 +134,7 @@ static const struct pvm_ftr_bits pvmid_aa64mmfr2[] = {
> >>>  	MAX_FEAT(ID_AA64MMFR2_EL1, UAO, IMP),
> >>>  	MAX_FEAT(ID_AA64MMFR2_EL1, IESB, IMP),
> >>>  	MAX_FEAT(ID_AA64MMFR2_EL1, AT, IMP),
> >>> -	MAX_FEAT_ENUM(ID_AA64MMFR2_EL1, IDS, 0x18),
> >>> +	MAX_FEAT_ENUM(ID_AA64MMFR2_EL1, IDS, IMP),
> >>>  	MAX_FEAT(ID_AA64MMFR2_EL1, TTL, IMP),
> >>>  	MAX_FEAT(ID_AA64MMFR2_EL1, BBM, 2),
> >>>  	MAX_FEAT(ID_AA64MMFR2_EL1, E0PD, IMP),
> >>> diff --git a/arch/arm64/tools/sysreg b/arch/arm64/tools/sysreg
> >>> index 1c6cdf9d54bba..3261e8791ac03 100644
> >>> --- a/arch/arm64/tools/sysreg
> >>> +++ b/arch/arm64/tools/sysreg
> >>> @@ -2257,8 +2257,8 @@ UnsignedEnum	43:40	FWB
> >>>  	0b0001	IMP
> >>>  EndEnum
> >>>  Enum	39:36	IDS
> >>
> >> Should this also be changed to an UnsignedEnum?
> > 
> > I'm not sure this brings much when you only have two values. If IDS
> > was growing a third value, and that there was an actual order in the
> > numbering scheme, then yes, that'd be useful.
> 
> Joey just pointed out to me that there is a new third field. Not in the
> arm reference manual yet, but mentioned in the xml. I'm unsure if it's
> necessary to consider this at the moment though.
> 
> https://developer.arm.com/documentation/ddi0601/2025-09/AArch64-Registers/ID-AA64MMFR2-EL1--AArch64-Memory-Model-Feature-Register-2?lang=en

Ah, nice catch. In which case I agree that this should become
UnsignedEnum, as the new EL3 feature is a strict superset of 0b0001.

I'll add fix for that on top.

Thanks,

	M.

-- 
Without deviation from the norm, progress is not possible.



More information about the linux-arm-kernel mailing list