History log of /rk3399_ARM-atf/include/bl31/sync_handle.h (Results 1 – 13 of 13)
Revision Date Author Comments
# ef397720 10-Nov-2025 Manish Pandey <manish.pandey2@arm.com>

Merge changes from topic "ar/idte3" into integration

* changes:
feat(cpufeat): add support for FEAT_IDTE3
feat(cpufeat): include enabled security state scope
feat(cpufeat): add ID register def

Merge changes from topic "ar/idte3" into integration

* changes:
feat(cpufeat): add support for FEAT_IDTE3
feat(cpufeat): include enabled security state scope
feat(cpufeat): add ID register defines and read helpers

show more ...


# f396aec8 09-Sep-2025 Arvind Ram Prakash <arvind.ramprakash@arm.com>

feat(cpufeat): add support for FEAT_IDTE3

This patch adds support for FEAT_IDTE3, which introduces support
for handling the trapping of Group 3 and Group 5 (only GMID_EL1)
registers to EL3 (unless t

feat(cpufeat): add support for FEAT_IDTE3

This patch adds support for FEAT_IDTE3, which introduces support
for handling the trapping of Group 3 and Group 5 (only GMID_EL1)
registers to EL3 (unless trapped to EL2). IDTE3 allows EL3 to
modify the view of ID registers for lower ELs, and this capability
is used to disable fields of ID registers tied to disabled features.

The ID registers are initially read as-is and stored in context.
Then, based on the feature enablement status for each world, if a
particular feature is disabled, its corresponding field in the
cached ID register is set to Res0. When lower ELs attempt to read
an ID register, the cached ID register value is returned. This
allows EL3 to prevent lower ELs from accessing feature-specific
system registers that are disabled in EL3, even though the hardware
implements them.

The emulated ID register values are stored primarily in per-world
context, except for certain debug-related ID registers such as
ID_AA64DFR0_EL1 and ID_AA64DFR1_EL1, which are stored in the
cpu_data and are unique to each PE. This is done to support feature
asymmetry that is commonly seen in debug features.

FEAT_IDTE3 traps all Group 3 ID registers in the range
op0 == 3, op1 == 0, CRn == 0, CRm == {2–7}, op2 == {0–7} and the
Group 5 GMID_EL1 register. However, only a handful of ID registers
contain fields used to detect features enabled in EL3. Hence, we
only cache those ID registers, while the rest are transparently
returned as is to the lower EL.

This patch updates the CREATE_FEATURE_FUNCS macro to generate
update_feat_xyz_idreg_field() functions that disable ID register
fields on a per-feature basis. The enabled_worlds scope is used to
disable ID register fields for security states where the feature is
not enabled.

This EXPERIMENTAL feature is controlled by the ENABLE_FEAT_IDTE3
build flag and is currently disabled by default.

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

show more ...


# d0fa53fb 07-Nov-2025 Govindraj Raja <govindraj.raja@arm.com>

Merge changes from topic "ar/pre-idte3" into integration

* changes:
feat(el3-runtime): add flags argument to handle_sysreg_trap
fix(cpufeat): remove unused FEAT_NV feature functions


# 88655be9 21-Oct-2025 Arvind Ram Prakash <arvind.ramprakash@arm.com>

feat(el3-runtime): add flags argument to handle_sysreg_trap

Extend handle_sysreg_trap() to accept an additional flags
parameter indicating the caller’s security state.
The EL3 synchronous exception

feat(el3-runtime): add flags argument to handle_sysreg_trap

Extend handle_sysreg_trap() to accept an additional flags
parameter indicating the caller’s security state.
The EL3 synchronous exception handler now passes this value
when dispatching trapped system register accesses.
This allows handle_sysreg_trap() to handle traps based on
the originating security context.

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

show more ...


# e3ecd731 14-Mar-2024 Lauren Wehrmeister <lauren.wehrmeister@arm.com>

Merge "refactor(sdei): use common create_spsr() in SDEI library" into integration


# 03fafc0b 20-Feb-2024 Arvind Ram Prakash <arvind.ramprakash@arm.com>

refactor(sdei): use common create_spsr() in SDEI library

The current SPSR updation code as part of the SDEI interrupt handler
code is outdated. This patch replaces the legacy code with a call to
an

refactor(sdei): use common create_spsr() in SDEI library

The current SPSR updation code as part of the SDEI interrupt handler
code is outdated. This patch replaces the legacy code with a call to
an up-to-date create_spsr()

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

show more ...


# c2f9ba88 28-Feb-2024 Manish V Badarkhe <manish.badarkhe@arm.com>

Merge changes from topic "mp/undef_injection" into integration

* changes:
feat(el3-runtime): introduce UNDEF injection to lower EL
feat(cpufeat): added few helper functions


# 3c789bfc 08-Dec-2023 Manish Pandey <manish.pandey2@arm.com>

feat(el3-runtime): introduce UNDEF injection to lower EL

For a feature to be used at lower ELs, EL3 generally needs to disable
the trap so that lower ELs can access the system registers associated
w

feat(el3-runtime): introduce UNDEF injection to lower EL

For a feature to be used at lower ELs, EL3 generally needs to disable
the trap so that lower ELs can access the system registers associated
with the feature. Lower ELs generally check ID registers to dynamically
detect if a feature is present (in HW) or not while EL3 Firmware relies
statically on feature build macros to enable a feature.

If a lower EL accesses a system register for a feature that EL3 FW is
unaware of, EL3 traps the access and panics. This happens mostly with
EL2 but sometimes VMs can also cause EL3 panic.

To provide platforms with capability to mitigate this problem, UNDEF
injection support has been introduced which injects a synchronous
exception into the lower EL which is supposed to handle the
synchronous exception.

The current support is only provided for aarch64.

The implementation does the following on encountering sys reg trap

- Get the target EL, which can be either EL2 or EL1
- Update ELR_ELx with ELR_EL3, so that after UNDEF handling in lower EL
control returns to original location.
- ESR_ELx with EC_UNKNOWN
- Update ELR_EL3 with vector address of sync exception handler with
following possible causes
- Current EL with SP0
- Current EL with SPx
- Lower EL using AArch64
- Re-create SPSR_EL3 which will be used to generate PSTATE at ERET

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

show more ...


# d494b0ef 02-May-2023 Manish Pandey <manish.pandey2@arm.com>

Merge "feat(el3-runtime): handle traps for IMPDEF registers accesses" into integration


# 0ed3be6f 13-Apr-2023 Varun Wadekar <vwadekar@nvidia.com>

feat(el3-runtime): handle traps for IMPDEF registers accesses

This patch introduces support to handle traps from lower ELs for
IMPDEF system register accesses. The actual support is left to the
plat

feat(el3-runtime): handle traps for IMPDEF registers accesses

This patch introduces support to handle traps from lower ELs for
IMPDEF system register accesses. The actual support is left to the
platforms to implement.

Signed-off-by: Varun Wadekar <vwadekar@nvidia.com>
Change-Id: I623d5c432b4ce4328b68f238c15b1c83df97c1e5

show more ...


# 0c6a0854 04-Jan-2023 Manish Pandey <manish.pandey2@arm.com>

Merge changes from topic "fvp_trap_rng" into integration

* changes:
feat(fvp): emulate trapped RNDR
feat(el3-runtime): introduce system register trap handler


# 1ae75529 21-Nov-2022 Andre Przywara <andre.przywara@arm.com>

feat(fvp): emulate trapped RNDR

When a platform decides to use FEAT_RNG_TRAP, every RNDR or RNDRSS read
will trap into EL3. The platform can then emulate those instructions, by
either executing the

feat(fvp): emulate trapped RNDR

When a platform decides to use FEAT_RNG_TRAP, every RNDR or RNDRSS read
will trap into EL3. The platform can then emulate those instructions, by
either executing the real CPU instructions, potentially conditioning the
results, or use rate-limiting or filtering to protect the hardware
entropy pool. Another possiblitiy would be to use some platform specific
TRNG device to get entropy and returning this.

To demonstrate platform specific usage, add a demo implementation for the
FVP: It will execute the actual CPU instruction and just return the
result. This should serve as reference code to implement platform specific
policies.

We change the definition of read_rndr() and read_rndrrs() to use the
alternative sysreg encoding, so that all assemblers can handle that.

Add documentation about the new platform specific RNG handler function.

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

show more ...


# ccd81f1e 21-Nov-2022 Andre Przywara <andre.przywara@arm.com>

feat(el3-runtime): introduce system register trap handler

At the moment we only handle SMC traps from lower ELs, but ignore any
other synchronous traps and just panic.
To cope with system register t

feat(el3-runtime): introduce system register trap handler

At the moment we only handle SMC traps from lower ELs, but ignore any
other synchronous traps and just panic.
To cope with system register traps, which we might need to emulate,
introduce a C function to handle those traps, and wire that up in the
exception handler to be called.

We provide a dispatcher function (in C), that will call platform
specific implementation for certain (classes of) system registers.
For now this is empty.

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

show more ...