Re: [RFC PATCH v7 02/28] arm64/sysreg: Define MDCR_EL2.E2PB values

[Alexandru Elisei <alexandru.elisei@arm.com>]

Hi Lorenzo,

On Thu, Oct 15, 2026 at 02:52:32PM +0100, Lorenzo Stoakes (ARM) wrote:
> On Thu, Sep 03, 2026 at 05:05:57PM +0100, Alexandru Elisei wrote:
> > KVM will make use of the different values for MDCR_EL2.E2PB, document them.
> 
> As with 1/28, using [0] to check the definition of the register.
> 
> >
> > Reviewed-by: Suzuki K Poulose <suzuki.poulose@arm.com>
> > Signed-off-by: Alexandru Elisei <alexandru.elisei@arm.com>
> 
> Looks correct, a couple small nits below, with those addressed:
> 
> Reviewed-by: Lorenzo Stoakes (ARM) <ljs@kernel.org>
> 
> > ---
> >  arch/arm64/tools/sysreg | 7 ++++++-
> >  1 file changed, 6 insertions(+), 1 deletion(-)
> >
> > diff --git a/arch/arm64/tools/sysreg b/arch/arm64/tools/sysreg
> > index a11a968eb707..4485736a4f49 100644
> > --- a/arch/arm64/tools/sysreg
> > +++ b/arch/arm64/tools/sysreg
> > @@ -4045,7 +4045,12 @@ Field	17	HPMD
> >  Res0	16
> >  Field	15	EnSPM
> >  Field	14	TPMS
> > -Field	13:12	E2PB
> > +UnsignedEnum	13:12 E2PB
> 
> MEGA NIT: Shouldn't there be a tab rather than a space after '13:12'? :)

Fixed.

> 
> > +	0b00	EL2
> 
> So broadly - this means EL2 owns the profiling buffer right?

Yes.

> 
> This seems to align with the document (which is very verbose, obviously :):
> 
> "If EL2 is implemented and enabled in the Profiling Buffer owning Security
> state, then the Profiling Buffer owning Exception level is EL2. Otherwise,
> the Profiling Buffer owning Exception level is EL1 and, Profiling is
> prohibited at EL2."
> 
> "If EL2 is implemented and enabled in the current Security state, then
> accesses to Profiling Buffer System registers at EL1 are trapped to EL2,
> unless the access generates a higher priority exception."
> 
> > +	0b01	RESERVED
> 
> NIT: Hmm, it seems to be the convention to just omit entries that are
> missing from the definition in the docs? So is this needed?

Removed.

> 
> I see a couple named ones, e.g. in CTR_EL0.L1Ip:
> 
> 	# This was named as VPIPT in the ARM but now documented as reserved
> 	0b00	RESERVED_VPIPT
> 	# This is named as AIVIVT in the ARM but documented as reserved
> 	0b01	RESERVED_AIVIVT
> 
> Which have comments explaining why, i.e. they were defined before but are
> now reserved.
> 
> > +	0b10	EL1_TRAP
> 
> Again my understanding - EL1 owns the profiling buffer, but EL1 sysreg
> accesses trap to EL2?

Yes.

> 
> Seems to align with docs:
> 
> "Profiling Buffer owning Exception level is EL1. Profiling is prohibited at
> EL2."
> 
> "If EL2 is implemented and enabled in the current Security state, then
> accesses to Profiling Buffer System registers at EL1 are trapped to EL2,
> unless the access generates a higher priority exception."
> 
> > +	0b11	EL1
> 
> And finally - EL1, traps to EL1 too right?

Profiling buffer owning exception level is EL1, accesses to the profiling buffer
registers made at EL1 are not trapped.

For the exact trapping priority and possible trap configurations, you can have a
look at the pseudocode for accessing one of the profiling buffer system
registers (PMBSR_EL1, PMPTR_EL1 or PMBLIMITR_EL1).

> 
> Again seems to align with docs:
> 
> "Profiling Buffer owning Exception level is EL1. Profiling is prohibited at
> EL2."
> 
> "Accesses to Profiling Buffer System registers at EL1 are not trapped by
> this mechanism."
> 
> > +EndEnum
> >  Field	11	TDRA
> >  Field	10	TDOSA
> >  Field	9	TDA
> > --
> > 2.43.0
> >
> >
> 
> All LGTM!

Thanks,
Alex

> 
> --
> Cheers, Lorenzo
> 
> [0]:https://support.arm.com/documentation/ddi0601/2026-09/AArch64-Registers/MDCR-EL2--Monitor-Debug-Configuration-Register--EL2-?lang=en