| 553c24c3 | 07-Jul-2025 |
Boyan Karatotev <boyan.karatotev@arm.com> |
feat(cpufeat): enable FEAT_RAS for FEAT_STATE_CHECKED again
FEAT_RAS was originally converted to FEAT_STATE_CHECKED in 6503ff291. However, the ability to use it was removed with 970a4a8d8 by simply
feat(cpufeat): enable FEAT_RAS for FEAT_STATE_CHECKED again
FEAT_RAS was originally converted to FEAT_STATE_CHECKED in 6503ff291. However, the ability to use it was removed with 970a4a8d8 by simply saying it impacts execution at EL3. That's true, but FEAT_STATE_CHECKED can still be allowed by being a bit clever about it.
First, the remainder of common code can be converted to use the is_feat_ras_supported() helper instead of the `#if FEATURE` pattern. There are no corner cases to consider there. The feature is either present (and appropriate action must be taken) or the feature is not (so we can skip RAS code).
A conscious choice is taken to check the RAS code in synchronize_errors despite it being in a hot path. Any fixed platform that seeks to be performant should be setting features to 0 or 1. Then, the SCTLR_EL3.IESB bit is always set if ENABLE_FEAT_RAS != 0 since we expect FEAT_IESB to be present if FEAT_RAS is (despite the architecture not guaranteeing it). If FEAT_RAS isn't present then we don't particularly care about the status of FEAT_IESB.
Second, platforms that don't set ENABLE_FEAT_RAS must continue to work. This is true out of the box with the is_feat_xyz_supported() helpers, as they make sure to fully disable code within them.
Third, platforms that do set ENABLE_FEAT_RAS=1 must continue to work. This is also true out of the box and no logical change is undertaken in common code.
Finally, ENABLE_FEAT_RAS is set to 2 on FVP. Having RAS implies that the whole handling machinery will be built-in and registered as appropriate. However, when RAS is built-in but not present in hardware, these registrations can still happen, they will only never be invoked at runtime.
Change-Id: I949e648601dc0951ef9c2b217f34136b6ea4b3dc Signed-off-by: Boyan Karatotev <boyan.karatotev@arm.com>
show more ...
|
| 7e619ecc | 16-Jan-2023 |
Govindraj Raja <govindraj.raja@arm.com> |
refactor(aarch64): refactor usage of elx_panic
Currently we call el3_panic for panics from EL3 and elx_panic for panics from lower ELs.
When we boot into a rich OS environment and interact with BL3
refactor(aarch64): refactor usage of elx_panic
Currently we call el3_panic for panics from EL3 and elx_panic for panics from lower ELs.
When we boot into a rich OS environment and interact with BL31 using SMC/ABI calls and we can also decide to handle any lower EL panics in EL3. Panic can occur in lower EL from rich OS or during SMC/ABI calls after context switch to EL3.
But after booting into any rich OS we may land in panic either from rich OS or while servicing any SMC call, here the logic to use el3_panic or elx_panic is flawed as spsr_el3[3:0] is always EL3h and end up in elx_panic even if panic occurred from EL3 during SMC handling.
We try to decouple the elx_panic usage for its intended purpose, introduce lower_el_panic which would call elx_panic, currently lower_el_panic is called from default platform_ea_handle which would be called due to panic from any of the lower ELs.
Also remove the weak linkage for elx_panic and rename it to report_elx_panic which could be used with lower_el_panic.
Change-Id: I268bca89c01c60520d127ef6c7ba851460edc747 Signed-off-by: Govindraj Raja <govindraj.raja@arm.com>
show more ...
|