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

[Lorenzo Stoakes (ARM)]

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 at arm.com>
> Signed-off-by: Alexandru Elisei <alexandru.elisei at arm.com>

Looks correct, a couple small nits below, with those addressed:

Reviewed-by: Lorenzo Stoakes (ARM) <ljs at 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'? :)

> +	0b00	EL2

So broadly - this means EL2 owns the profiling buffer right?

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?

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?

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?

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!

--
Cheers, Lorenzo

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