feat(cpufeat): add support for FEAT_RME_GPC2

This change adds support for FEAT_RME_GPC2 and Non-Secure-Only (NSO)
Physical Address Space.

Previously, all non-secure (NS) memory was accessible to th

feat(cpufeat): add support for FEAT_RME_GPC2

This change adds support for FEAT_RME_GPC2 and Non-Secure-Only (NSO)
Physical Address Space.

Previously, all non-secure (NS) memory was accessible to the secure
world and realm world. With GPC2 and the NSO bit in the GPT, memory
can now be restricted to the non-secure world only. This is enabled
automatically on supported systems when ENABLE_RME is true.

Change-Id: I9b70c3a23c5ec7d83bd787d0fb3edd55934f1d05
Signed-off-by: John Powell <john.powell@arm.com>
Signed-off-by: Girish Pathak <girish.pathak@arm.com>

show more ...

fix(cpufeat): extend FEAT_EBEP handling to delegate PMU control to EL2

Currently, the FEAT_EBEP feature presence check is only used for UNDEF
injection into lower ELs. However, this feature also aff

fix(cpufeat): extend FEAT_EBEP handling to delegate PMU control to EL2

Currently, the FEAT_EBEP feature presence check is only used for UNDEF
injection into lower ELs. However, this feature also affects the access
behavior of MDCR_EL2. Specifically, if the PMEE bits in MDCR_EL3 are not
set to 0b01, then the MDCR_EL2.PMEE bits cannot be configured by EL2.

This patch extends the use of FEAT_EBEP to delegate PMU IRQ and
profiling exception control to EL2 by setting MDCR_EL3.PMEE = 0b01.This
ensures that lower ELs can manage PMU configuration.

Signed-off-by: Manish Pandey <manish.pandey2@arm.com>
Change-Id: Ib7e1d5c72f017b8ffc2131fc57309dd9d811c973

show more ...

fix(cpufeat): use of additional breakpoints

Extended Breakpoints access through mdcr_el3.ebwe is available
only when there are greater than 16 breakpoints implemented.
Otherwise the EBWE Bit is RES0

fix(cpufeat): use of additional breakpoints

Extended Breakpoints access through mdcr_el3.ebwe is available
only when there are greater than 16 breakpoints implemented.
Otherwise the EBWE Bit is RES0 and we could skip enabling Extended
Breakpoint access.

Ref: https://developer.arm.com/documentation/111107/2025-09/AArch64-Registers/MDCR-EL3--Monitor-Debug-Configuration-Register--EL3-?lang=en

Change-Id: I2b2147e83d65ee9b0492d3cf3adafd5c8cbe17f5
Signed-off-by: Govindraj Raja <govindraj.raja@arm.com>

show more ...

fix(el3-runtime): allow RNDR access at EL3 even when RNG_TRAP is enabled

RNG_TRAP will also trap RNDR accesses at EL3 which we don't want as we
have no way to handle nested exceptions. Clear the tra

fix(el3-runtime): allow RNDR access at EL3 even when RNG_TRAP is enabled

RNG_TRAP will also trap RNDR accesses at EL3 which we don't want as we
have no way to handle nested exceptions. Clear the trap with root
context to always allow access at EL3.

Change-Id: I6e4cd8b5a7730f6ffbeed912d9301877d271110d
Signed-off-by: Boyan Karatotev <boyan.karatotev@arm.com>

show more ...

fix(bl1): use per-world context correctly

Currently, the configuration with BL1 and BL2 at SEL1 will transition
via el3_exit which will restore per-world context. However, that context
is never writ

fix(bl1): use per-world context correctly

Currently, the configuration with BL1 and BL2 at SEL1 will transition
via el3_exit which will restore per-world context. However, that context
is never written to and so zeroes end up in registers, which is not
necessarily correct.

This patch gets BL1 to call cm_manage_extensions_per_world() whenever
BL2 runs in a lower EL. This allows the per-world registers to have the
reset values we intend. An accompanying call to
cm_manage_extensions_el3() is also added for completeness.

Doing this shows a small deficiency in cptr_el3 - bits TFP and TCPAC
change a lot. This patch makes them consistent by always setting TCPAC
and TFP to 0 which unconditionally enable access to CPTR_EL2 and FPCR by
default as they are always accessible. Other places that manipulate the
TFP bit are removed.

A nice side effect of all of this is that we're now in a position to
enable and use any architectural extension in BL2.

Change-Id: I070d62bbf8e9d9b472caf7e2c931c303523be308
Signed-off-by: Boyan Karatotev <boyan.karatotev@arm.com>

show more ...

fix(security): add clrbhb support

TF-A mitigates spectre-bhb(CVE-2022-23960) issue with loop
workaround based on - https://developer.arm.com/documentation/110280/latest/

On platforms that support `

fix(security): add clrbhb support

TF-A mitigates spectre-bhb(CVE-2022-23960) issue with loop
workaround based on - https://developer.arm.com/documentation/110280/latest/

On platforms that support `clrbhb` instruction it is recommended to
use `clrbhb` instruction instead of the loop workaround.

Ref- https://developer.arm.com/documentation/102898/0108/

Change-Id: Ie6e56e96378503456a1617d5e5d51bc64c2e0f0b
Signed-off-by: Govindraj Raja <govindraj.raja@arm.com>

show more ...

Merge changes Ifbc5ab02,Ib9002609,I0276257d into integration

* changes:
fix(fvp): initialise the event log's size to avoid using gibberish values
fix(tsp): keep the tsp D128 unaware, not the dis

Merge changes Ifbc5ab02,Ib9002609,I0276257d into integration

* changes:
fix(fvp): initialise the event log's size to avoid using gibberish values
fix(tsp): keep the tsp D128 unaware, not the dispatcher
fix(dice): prevent compiler warnings

show more ...

feat(cpufeat): enable FEAT_PFAR support

Implement support for FEAT_PFAR, which introduces the PFAR_ELx system
register, recording the faulting physical address for some aborts.
Those system register

feat(cpufeat): enable FEAT_PFAR support

Implement support for FEAT_PFAR, which introduces the PFAR_ELx system
register, recording the faulting physical address for some aborts.
Those system registers are trapped by the SCR_EL3.PFARen bit, so set the
bit for the non-secure world context to allow OSes to use the feature.

This is controlled by the ENABLE_FEAT_PFAR build flag, which follows the
usual semantics of 2 meaning the feature being runtime detected.
Let the default for this flag be 0, but set it to 2 for the FVP.

Change-Id: I5c9ae750417e75792f693732df3869e02b6e4319
Signed-off-by: Andre Przywara <andre.przywara@arm.com>

show more ...

fix(tsp): keep the tsp D128 unaware, not the dispatcher

The tspd is a core part of the el3 runtime and it must behave the same
way, i.e. it must handle FEAT_D128. The tsp on the other hand is a bit

fix(tsp): keep the tsp D128 unaware, not the dispatcher

The tspd is a core part of the el3 runtime and it must behave the same
way, i.e. it must handle FEAT_D128. The tsp on the other hand is a bit
more special and can have carveouts, which patch f3e2b4997 added.

That incorrectly did it for the tspd instead of the tsp, so fix that.

Change-Id: Ib9002609ef9c66b0d1fcc5b3a9f012376d0c3bf4
Signed-off-by: Boyan Karatotev <boyan.karatotev@arm.com>

show more ...

feat(cpufeat): enable FEAT_AIE support

Implement support for FEAT_AIE, which introduces the AMAIR2_ELx and
MAIR2_ELx system registers, extending the memory attributes described
by {A}MAIR_ELx.
Those

feat(cpufeat): enable FEAT_AIE support

Implement support for FEAT_AIE, which introduces the AMAIR2_ELx and
MAIR2_ELx system registers, extending the memory attributes described
by {A}MAIR_ELx.
Those system registers are trapped by the SCR_EL3.AIEn bit, so set the
bit for the non-secure world context to allow OSes to use the feature.

This is controlled by the ENABLE_FEAT_AIE build flag, which follows the
usual semantics of 2 meaning the feature being runtime detected.
Let the default for this flag be 0, but set it to 2 for the FVP.

Change-Id: Iba2011719013a89f9cb3a4317bde18254f45cd25
Signed-off-by: Andre Przywara <andre.przywara@arm.com>

show more ...

feat(dsu): enable PMU registers access at EL1

- Disable trapping of write accesses to DSU cluster PMU registers
at EL3 and EL2.
- Clear the SPME bit in CLUSTERPMMDCR_EL3 to prohibit PMU event
co

feat(dsu): enable PMU registers access at EL1

- Disable trapping of write accesses to DSU cluster PMU registers
at EL3 and EL2.
- Clear the SPME bit in CLUSTERPMMDCR_EL3 to prohibit PMU event
counting in the secure state.

Change-Id: If3eb6e997330ae86f45760e0e862c003861f3d66
Signed-off-by: Amr Mohamed <amr.mohamed@arm.com>

show more ...

Merge "refactor(el3-runtime): move context security states to context.h" into integration

feat(cpufeat): enable FEAT_CPA2 for EL3

FEAT_CPA2 enables checked pointer arithmetic, which in the event
of an arithmetic overflow in pointer generation will result in a
non-canonical pointer being

feat(cpufeat): enable FEAT_CPA2 for EL3

FEAT_CPA2 enables checked pointer arithmetic, which in the event
of an arithmetic overflow in pointer generation will result in a
non-canonical pointer being generated and subsequent address fault.

Note that FEAT_CPA is a trivial implementation that exists in
some hardware purely so it can run CPA2-enabled instructions
without crashing but they don't actually have checked arithmetic,
so FEAT_CPA is not explicitly enabled in TF-A.

Change-Id: I6d2ca7a7e4b986bb9e917aa8baf8091a271c168b
Signed-off-by: John Powell <john.powell@arm.com>

show more ...

refactor(el3-runtime): move context security states to context.h

The three security states (S, NS, RL) are architecturally quite
consistent - anything that uses them has the same numerical assignmen

refactor(el3-runtime): move context security states to context.h

The three security states (S, NS, RL) are architecturally quite
consistent - anything that uses them has the same numerical assignments
(0, 1, 2) and they are quite convenient for indexing. However, we're not
as consistent in tf-a and this is defined in a few places. Since
cpu_data has a dependency on the context management library, use its
security state convention in a few more places and take away this
responsibility from cpu_data.

Change-Id: Iec73b2be2eef91975554767557de72424d0031f1
Signed-off-by: Boyan Karatotev <boyan.karatotev@arm.com>

show more ...

Merge "fix(cpufeat): configure CPTR_EL2.ZEN and CPTR_EL2.TZ to match Linux" into integration

fix(cpufeat): configure CPTR_EL2.ZEN and CPTR_EL2.TZ to match Linux

Linux Documentation/arch/arm64/booting.rst states that:
"
For CPUs with the Scalable Vector Extension (FEAT_SVE) present:
...
-

fix(cpufeat): configure CPTR_EL2.ZEN and CPTR_EL2.TZ to match Linux

Linux Documentation/arch/arm64/booting.rst states that:
"
For CPUs with the Scalable Vector Extension (FEAT_SVE) present:
...
- If the kernel is entered at EL1 and EL2 is present:
- CPTR_EL2.TZ (bit 8) must be initialised to 0b0.
- CPTR_EL2.ZEN (bits 17:16) must be initialised to 0b11.
"
Without these settings, Linux kernel hangs on boot when trying
to use SVE. Adjust the register settings to match Linux kernel
expectations.

Signed-off-by: Marek Vasut <marek.vasut+renesas@mailbox.org>
Change-Id: I9a72810dd902b08f9c61f157cc31e603aad2f73a

show more ...

refactor: unify blx_setup() and blx_main()

All BLs have a bl_setup() for things that need to happen early, a fall
back into assembly and then bl_main() for the main functionality. This
was necessary

refactor: unify blx_setup() and blx_main()

All BLs have a bl_setup() for things that need to happen early, a fall
back into assembly and then bl_main() for the main functionality. This
was necessary in order to fiddle with PAuth related things that tend to
break C calls. Since then PAuth's enablement has seen a lot of
refactoring and this is now worked around cleanly so the distinction can
be removed. The only tradeoff is that this requires pauth to not be used
for the top-level main function.

There are two main benefits to doing this: First, code is easier to
understand as it's all together and the entrypoint is smaller. Second,
the compiler gets to see more of the code and apply optimisations
(importantly LTO).

Change-Id: Iddb93551115a2048988017547eb7b8db441dbd37
Signed-off-by: Boyan Karatotev <boyan.karatotev@arm.com>

show more ...

fix(bl2): unify the BL2 EL3 and RME entrypoints

BL2 has 3(!) entrypoints:
1) the regular EL1 entrypoint (once per AArch)
2) an EL3 entrypoint
3) an EL3 entrypoint with RME

The EL1 and EL3 entryp

fix(bl2): unify the BL2 EL3 and RME entrypoints

BL2 has 3(!) entrypoints:
1) the regular EL1 entrypoint (once per AArch)
2) an EL3 entrypoint
3) an EL3 entrypoint with RME

The EL1 and EL3 entrypoints are quite distinct so it's useful to keep
them separate. But the EL3 and RME entrypoints are conceptually
identical just configured differently and having slightly different
assumptions (eg whether we can rely on BL1). So put them together with
only the configuration as a difference. This has a few benefits:
* makes the naming consistent - BL2 always runs at EL1, BL2_EL3 always
runs at EL3. This is most important for the linker script.
* paves the way for ENABLE_RME and RESET_TO_BL2 to coexist.
* allows for more general refactors

Currently, ENABLE_RME and RESET_TO_BL2 are mutually exclusive (from a
makefile constraint) so the checks are simplified to one or the other as
there is no danger of their simultaneous use.

Change-Id: Iecffab2ff3a0bd7823f8277d9f66e22e4f42cc8c
Signed-off-by: Boyan Karatotev <boyan.karatotev@arm.com>

show more ...

feat(cpufeat): enable FEAT_MPAM_PE_BW_CTRL support

Implement support for FEAT_MPAM_PE_BW_CTRL, allowing lower
Exception Levels to access MPAM_PE_BW_CTRL control registers
by disabling their traps to

feat(cpufeat): enable FEAT_MPAM_PE_BW_CTRL support

Implement support for FEAT_MPAM_PE_BW_CTRL, allowing lower
Exception Levels to access MPAM_PE_BW_CTRL control registers
by disabling their traps to EL3.

When INIT_UNUSED_NS_EL2=1, configure MPAMBW2_EL2 in EL3 so
that MPAM_PE_BW_CTRL accesses from EL0/EL1 do not trap to EL2.

At this stage, PE-side MPAM bandwidth controls remain disabled
in EL3.

Signed-off-by: Arvind Ram Prakash <arvind.ramprakash@arm.com>
Change-Id: I8e359b0eb912cff3bdda109b21727a627cac3a7e

show more ...

fix(lib): use 64-bit constants in MDCR_EL2 bit macros

Updated bitmask definitions in MDCR_EL2 macros to use ULL(1) instead
of U(1), ensuring the left operand in shift operations is of an
appropriate

fix(lib): use 64-bit constants in MDCR_EL2 bit macros

Updated bitmask definitions in MDCR_EL2 macros to use ULL(1) instead
of U(1), ensuring the left operand in shift operations is of an
appropriate width. This avoids MISRA C:2012 Rule 12.2 violations,
which prohibit shifting a value by more than 7 bits when the left-
hand operand is an unsigned int.

Change-Id: I279fb33c2ef714367953d53e61456490cd7c798b
Signed-off-by: Saivardhan Thatikonda <saivardhan.thatikonda@amd.com>

show more ...

fix(cm): disable SPE/TRBE correctly

SPE and TRBE are unusual features. They have multi-bit enables whose
function is not immediately apparent and disabling them is not
straightforward.

While attemp

fix(cm): disable SPE/TRBE correctly

SPE and TRBE are unusual features. They have multi-bit enables whose
function is not immediately apparent and disabling them is not
straightforward.

While attempting to figure this out, the disables were made a mess of.
Patch fc7dca72b began changing the owning security state of SPE and
TRBE. This was first used in patch 79c0c7fac0 with calls to
spe_disable() and trbe_disbale(). However, patch 13f4a2525 reverted the
security state ownership, making the spe_disable() and trbe_disable()
redundant and their comments incorrect - the DoS protection is achieved
by the psb/tsb barriers on context switch, introduces separately in
f80887337 and 73d98e375.

Those patches got the behaviour full circle to what it was in fc7dca72b
so the disables can be fully removed for clarity.

However, the original method for disabling these features is not fully
correct - letting the "disabled" state be all zeroes made the features
seem enabled for secure world but they would trap. That is not a problem
while secure world doesn't use them, but could lead to some confusing
debugging in the future. NS and Realm worlds were not affected. This
patch fully establishes the pattern for SPE and TRBE's enablement,
documents it, and implements it such.

The description comments in the features boil down to 2 rules. There is
a third rule possible:
3. To enable TRBE/SPE for world X with a dirty buffer:
* world X owns the buffer
* trapping enabled
This is not listed as it would not work correctly with
SMCCC_ARCH_FEATURE_AVAILABILITY which relies on trapping to be disabled
to report correctly. If that is ever implemented, the SMCCC
implementation should be considered too.

Change-Id: I5588a3d5fc074c2445470954d8c3b172bec77d43
Signed-off-by: Boyan Karatotev <boyan.karatotev@arm.com>

show more ...

refactor(cm): unify RMM context

setup_realm_context() is the de facto place to put any code that relates
to the RMM's context. It is frequently updated and contains the vast
majority of code. manage

refactor(cm): unify RMM context

setup_realm_context() is the de facto place to put any code that relates
to the RMM's context. It is frequently updated and contains the vast
majority of code. manage_extensions_realm() on the other hand is out of
date and obscure.

So absorb manage_extensions_realm() and rmm_el2_context_init() into
setup_realm_context().

We can also combine the write to sctlr_el2 for all worlds as they should
all observe the RES1 values.

Finally, the SPSR_EL2.PAN comment in the realm copy is updated.

Change-Id: I21dccad0c13301e3249db6f6e292beb5d853563e
Signed-off-by: Boyan Karatotev <boyan.karatotev@arm.com>

show more ...

feat(cpufeat): add support for FEAT_FGWTE3

Enable write traps for key EL3 system registers as per FEAT_FGWTE3,
ensuring their values remain unchanged after boot.

Excluded Registers:
MDCR_EL3 and MP

feat(cpufeat): add support for FEAT_FGWTE3

Enable write traps for key EL3 system registers as per FEAT_FGWTE3,
ensuring their values remain unchanged after boot.

Excluded Registers:
MDCR_EL3 and MPAM3_EL3: Not trapped as they are part of the EL3 context.
SCTLR_EL3: Not trapped since it is overwritten during
powerdown sequence(Included when HW_ASSISTED_COHERENCY=1)

TPIDR_EL3: Excluded due to its use in crash reporting(It is included
when CRASH_REPORTING=0)

Reference:
https://developer.arm.com/documentation/ddi0601/2025-06/AArch64-Registers/FGWTE3-EL3--Fine-Grained-Write-Traps-EL3

Change-Id: Idcb32aaac7d65a0b0e5c90571af00e01a4e9edb1
Signed-off-by: Arvind Ram Prakash <arvind.ramprakash@arm.com>

show more ...

feat(dsu): support power control and autonomous powerdown config

This patch allows platforms to enable certain DSU settings
to ensure memory retention and control over
cache power requests. We also

feat(dsu): support power control and autonomous powerdown config

This patch allows platforms to enable certain DSU settings
to ensure memory retention and control over
cache power requests. We also move the driver out of css
into drivers/arm. Platforms can configure the
CLUSTERPWRCTLR and CLUSTERPWRDN registers [1] to improve
power efficiency.

These registers enable finer-grained control of
DSU power state transitions, including
powerdown and retention.

IMP_CLUSTERPWRCTLR_EL1 provides:
- Functional retention: Allows configuration of the
duration of inactivity before the DSU uses
CLUSTERPACTIVE to request functional retention.

- Cache power request: These bits are output on
CLUSTERPACTIVE[19:16] to indicate to the power controller
which cache portions must remain powered.

IMP_CLUSTERPWRDN_EL1 includes:
- Powerdown: Triggers full cluster powerdown, including
control logic.

- Memory retention: Requests memory retention mode,
keeping L3 RAM contents while powering off
the rest of the DSU.

The DSU-120 TRM [2] provides the full field definitions,
which are used as references in the `dsu_driver_data` structure.

References:
[1]: https://developer.arm.com/documentation/100453/latest/
[2]: https://developer.arm.com/documentation/102547/0201/?lang=en

Signed-off-by: Arvind Ram Prakash <arvind.ramprakash@arm.com>
Change-Id: I2eba808b8f2a27797782a333c65dd092b03208fe

show more ...

Merge "perf(bl31): convert cpu_data fetching to C" into integration