| f9f4944d | 04-Jul-2025 |
Boyan Karatotev <boyan.karatotev@arm.com> |
fix(cm): do not restore spsr and elr twice on external aborts
el3_exit will restore SPSR_EL3 and ELR_EL3. There is no need to do it in
ea_proceed too as that is always followed by el3_exit.
Change-
fix(cm): do not restore spsr and elr twice on external aborts
el3_exit will restore SPSR_EL3 and ELR_EL3. There is no need to do it in
ea_proceed too as that is always followed by el3_exit.
Change-Id: I9089b3ada7785bc0d5fd1e05192f456ffe666789
Signed-off-by: Boyan Karatotev <boyan.karatotev@arm.com>
show more ...
|
| 8f152319 | 11-Aug-2025 |
Boyan Karatotev <boyan.karatotev@arm.com> |
fix(aarch64): do not print EL1 registers on EL3 panic
Lower EL execution should not be able to panic EL3. The main source of
potential panic, traps from lower ELs, are now handled gracefully with
un
fix(aarch64): do not print EL1 registers on EL3 panic
Lower EL execution should not be able to panic EL3. The main source of
potential panic, traps from lower ELs, are now handled gracefully with
undefined injection. Almost every other source of panic is something
going wrong within TF-A. Regardless, in both cases, ESR_EL3, ELR_EL3,
and SPSR_ELR provide the majority of necessary information to debug a
panic and printing a lot of lower EL register only clutters the crash
dump and makes it difficult to read.
Further, when EL3 panics, the ultimate source of that panic may be EL2
but the crash reporting functionality only prints out EL1 system
registers which are going to be quite useless to debug.
Finally, the panic may be happening due to some misconfiguration of
other EL3 system registers that have been introduced with a feature.
There are two logical choices:
a) extend crash reporting to report all EL1, EL2, and EL3 registers
depending on where an error came from, including all features
b) only print core EL3 registers and rely on the developer to add extra
prints as necessary
We have never strived to achieve a) (as evidenced by EL2 and feature
sysregs never having been added), so do b). Only non-EL3 registers that
are relevant to EL3's direct execution are kept (like SP_EL0).
Change-Id: Ife2fe86184bca9a4d66f367c516eececc57471da
Signed-off-by: Boyan Karatotev <boyan.karatotev@arm.com>
show more ...
|
| 6d22b089 | 11-Oct-2023 |
Manish Pandey <manish.pandey2@arm.com> |
fix(el3-runtime): restrict lower el EA handlers in FFH mode
This patch does following changes to restrict handling of lower EL
EA's only if FFH mode is enabled.
- Compile ea_delegate.S only if FFH
fix(el3-runtime): restrict lower el EA handlers in FFH mode
This patch does following changes to restrict handling of lower EL
EA's only if FFH mode is enabled.
- Compile ea_delegate.S only if FFH mode is enabled.
- For Sync exception from lower ELs if the EC is not SMC or SYS reg
trap it was assumed that it is an EA, which is not correct. Move
the known Sync exceptions (EL3 Impdef) out of sync EA handler.
- Report unhandled exceptions if there are SError from lower EL in
KFH mode, as this is unexpected.
- Move code out of ea_delegate.S which are used for KFH mode.
Signed-off-by: Manish Pandey <manish.pandey2@arm.com>
Change-Id: I577089677d0ec8cde7c20952172bee955573d2ed
show more ...
|
| 6597fcf1 | 26-Jun-2023 |
Manish Pandey <manish.pandey2@arm.com> |
feat(ras): use FEAT_IESB for error synchronization
For synchronization of errors at exception boundries TF-A uses "esb"
instruction with FEAT_RAS or "dsb" and "isb" otherwise. The problem
with esb i
feat(ras): use FEAT_IESB for error synchronization
For synchronization of errors at exception boundries TF-A uses "esb"
instruction with FEAT_RAS or "dsb" and "isb" otherwise. The problem
with esb instruction is, along with synching errors it might also
consume the error, which is not ideal in all scenarios. On the other
hand we can't use dsb always as its in the hot path.
To solve above mentioned problem the best way is to use FEAT_IESB
feature which provides controls to insert an implicit Error
synchronization event at exception entry and exception return.
Assumption in TF-A is, if RAS Extension is present then FEAT_IESB will
also be present and enabled.
Signed-off-by: Manish Pandey <manish.pandey2@arm.com>
Change-Id: Ie5861eec5da4028a116406bb4d1fea7dac232456
show more ...
|
| d04c04a4 | 25-May-2023 |
Manish Pandey <manish.pandey2@arm.com> |
feat(el3-runtime): modify vector entry paths
Vector entries in EL3 from lower ELs, first check for any pending
async EAs from lower EL before handling the original exception.
This happens when there
feat(el3-runtime): modify vector entry paths
Vector entries in EL3 from lower ELs, first check for any pending
async EAs from lower EL before handling the original exception.
This happens when there is an error (EA) in the system which is not
yet signaled to PE while executing at lower EL. During entry into EL3
the errors (EA) are synchronized causing async EA to pend at EL3.
On detecting the pending EA (via ISR_EL1.A) EL3 either reflects it back
to lower EL (KFH) or handles it in EL3 (FFH) based on EA routing model.
In case of Firmware First handling mode (FFH), EL3 handles the pended
EA first before returing back to handle the original exception.
While in case of Kernel First handling mode (KFH), EL3 will return back
to lower EL without handling the original exception. On returing to
lower EL, EA will be pended. In KFH mode there is a risk of back and
forth between EL3 and lower EL if the EA is masked at lower EL or
priority of EA is lower than that of original exception. This is a
limitation in current architecture but can be solved in future if EL3
gets a capability to inject virtual SError.
Signed-off-by: Manish Pandey <manish.pandey2@arm.com>
Change-Id: I3a2a31de7cf454d9d690b1ef769432a5b24f6c11
show more ...
|