fix: pass SMCCCv1.3 SVE hint to internal flags

This change fixes the initial support for SMCCCv1.3 SVE hint bit [1].
In the aarch64 smc handler, the FID[16] bit is improperly extracted
and results i

fix: pass SMCCCv1.3 SVE hint to internal flags

This change fixes the initial support for SMCCCv1.3 SVE hint bit [1].
In the aarch64 smc handler, the FID[16] bit is improperly extracted
and results in the corresponding flags bit to be always set.
Fix by doing the proper masking and set into the flags register.

[1] https://review.trustedfirmware.org/c/TF-A/trusted-firmware-a/+/17511

Signed-off-by: Olivier Deprez <olivier.deprez@arm.com>
Change-Id: I62b8e211d48a50f28e184ff27cd718f51d8d56bf

show more ...

Merge "fix(pmu): unconditionally save PMCR_EL0" into integration

refactor(ras): replace RAS_EXTENSION with FEAT_RAS

The current usage of RAS_EXTENSION in TF-A codebase is to cater for two
things in TF-A :
1. Pull in necessary framework and platform hooks for Firm

refactor(ras): replace RAS_EXTENSION with FEAT_RAS

The current usage of RAS_EXTENSION in TF-A codebase is to cater for two
things in TF-A :
1. Pull in necessary framework and platform hooks for Firmware first
handling(FFH) of RAS errors.
2. Manage the FEAT_RAS extension when switching the worlds.

FFH means that all the EAs from NS are trapped in EL3 first and signaled
to NS world later after the first handling is done in firmware. There is
an alternate way of handling RAS errors viz Kernel First handling(KFH).
Tying FEAT_RAS to RAS_EXTENSION build flag was not correct as the
feature is needed for proper handling KFH in as well.

This patch breaks down the RAS_EXTENSION flag into a flag to denote the
CPU architecture `ENABLE_FEAT_RAS` which is used in context management
during world switch and another flag `RAS_FFH_SUPPORT` to pull in
required framework and platform hooks for FFH.

Proper support for KFH will be added in future patches.

BREAKING CHANGE: The previous RAS_EXTENSION is now deprecated. The
equivalent functionality can be achieved by the following
2 options:
- ENABLE_FEAT_RAS
- RAS_FFH_SUPPORT

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

show more ...

fix(pmu): unconditionally save PMCR_EL0

Reading back a RES0 bit does not necessarily mean it will be read as 0.
The Arm ARM explicitly warns against doing this. The PMU initialisation
code tries to

fix(pmu): unconditionally save PMCR_EL0

Reading back a RES0 bit does not necessarily mean it will be read as 0.
The Arm ARM explicitly warns against doing this. The PMU initialisation
code tries to set such bits to 1 (in MDCR_EL3) regardless of whether
they are in use or are RES0, checking their value could be wrong and
PMCR_EL0 might not end up being saved.

Save PMCR_EL0 unconditionally to prevent this. Remove the security state
change as the outgoing state is not relevant to what the root world
context should look like.

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

show more ...

Merge changes from topic "mb/rst-to-bl31-update" into integration

* changes:
docs: update RESET_TO_BL31 documentation
fix(bl31): avoid clearing of argument registers in RESET_TO_BL31 case
Reve

Merge changes from topic "mb/rst-to-bl31-update" into integration

* changes:
docs: update RESET_TO_BL31 documentation
fix(bl31): avoid clearing of argument registers in RESET_TO_BL31 case
Revert "docs(bl31): aarch64: RESET_TO_BL31_WITH_PARAMS"
Revert "feat(bl31): aarch64: RESET_TO_BL31_WITH_PARAMS"

show more ...

fix(smccc): check smc_fid [23:17] bits

As per SMCCC spec Table 2.1 bit 23:17 must be zero (MBZ),
for all Fast Calls, when bit[31] == 1.
Adding this check to ensure SMC FIDs when get to the SMC handl

fix(smccc): check smc_fid [23:17] bits

As per SMCCC spec Table 2.1 bit 23:17 must be zero (MBZ),
for all Fast Calls, when bit[31] == 1.
Adding this check to ensure SMC FIDs when get to the SMC handler
have these bits (23:17) cleared, if not capture and report them
as an unknown SMCs at the core.

Also the C runtime stack is copied to the stackpointer well in
advance, to leverage the existing el3_exit routine for unknown SMC.

Change-Id: I9972216db5ac164815011177945fb34dadc871b0
Signed-off-by: Jayanth Dodderi Chidanand <jayanthdodderi.chidanand@arm.com>

show more ...

fix(bl31): avoid clearing of argument registers in RESET_TO_BL31 case

It was assumed that BL31 is the first bootloader to run so there's
no argument to relay from a previous bootloader in RESET_TO_B

fix(bl31): avoid clearing of argument registers in RESET_TO_BL31 case

It was assumed that BL31 is the first bootloader to run so there's
no argument to relay from a previous bootloader in RESET_TO_BL31
case, however this is not true for every platform with a non-TF-A
bootloader that might get executed before BL31 while compiling in
RESET_TO_BL31 feature.

Thus, by avoiding zeroing registers, the arguments passed from the
previous bootloader to BL31 are preserved.

Change-Id: I7bb66a10d1fd551ba3fd59a7a38ab5bde3197f72
Signed-off-by: Manish V Badarkhe <Manish.Badarkhe@arm.com>

show more ...

Revert "feat(bl31): aarch64: RESET_TO_BL31_WITH_PARAMS"

Adopted RESET_TO_BL31_WITH_PARAMS functionality in RESET_TO_BL31
in the subsequent patches hence reverted this patch.
This reverts commit 2584

Revert "feat(bl31): aarch64: RESET_TO_BL31_WITH_PARAMS"

Adopted RESET_TO_BL31_WITH_PARAMS functionality in RESET_TO_BL31
in the subsequent patches hence reverted this patch.
This reverts commit 25844ff728e4a0e5430ba2032457aba7b780a701.

Change-Id: Ia0bfa22fc45754f15c82638662dde93f604992c3
Signed-off-by: Manish V Badarkhe <Manish.Badarkhe@arm.com>

show more ...

Merge changes from topic "panic_cleanup" into integration

* changes:
refactor(bl31): use elx_panic for sysreg_handler64
refactor(aarch64): rename do_panic and el3_panic
refactor(aarch64): remo

Merge changes from topic "panic_cleanup" into integration

* changes:
refactor(bl31): use elx_panic for sysreg_handler64
refactor(aarch64): rename do_panic and el3_panic
refactor(aarch64): remove weak links to el3_panic
refactor(aarch64): refactor usage of elx_panic
refactor(aarch64): cleanup HANDLE_EA_EL3_FIRST_NS usage

show more ...

refactor(bl31): use elx_panic for sysreg_handler64

When we reach sysreg_handler64 from any trap handling we are entering
this path from lower EL and thus we should be calling lower_el_panic
reportin

refactor(bl31): use elx_panic for sysreg_handler64

When we reach sysreg_handler64 from any trap handling we are entering
this path from lower EL and thus we should be calling lower_el_panic
reporting mechanism to print panic report.

Make report_elx_panic available through assembly func elx_panic which
could be used for reporting any lower_el_panic.

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

show more ...

refactor(aarch64): rename do_panic and el3_panic

Current panic call invokes do_panic which calls el3_panic, but now panic
handles only panic from EL3 anid clear separation to use lower_el_panic()
wh

refactor(aarch64): rename do_panic and el3_panic

Current panic call invokes do_panic which calls el3_panic, but now panic
handles only panic from EL3 anid clear separation to use lower_el_panic()
which handles panic from lower ELs.

So now we can remove do_panic and just call el3_panic for all panics.

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

show more ...

refactor(aarch64): remove weak links to el3_panic

Cleanup weak links to el3_panic and restrict crash_reporting usage
to bl31.

Crash reporting is not used with bl1, bl2 and weak linkage to el3_panic

refactor(aarch64): remove weak links to el3_panic

Cleanup weak links to el3_panic and restrict crash_reporting usage
to bl31.

Crash reporting is not used with bl1, bl2 and weak linkage to el3_panic
is used, this can cause ambiguity in understanding the code so remove
this weak linkage and introduce funcs that should be used when we have
crash reporting for el3 panics.

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

show more ...

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 ...

refactor(el3_runtime): unify handle/enter_lower_el_async_ea

handle_lower_el_async_ea and enter_lower_el_async_ea are same except for
saving x30 register, with previous patch x30 is now freed before

refactor(el3_runtime): unify handle/enter_lower_el_async_ea

handle_lower_el_async_ea and enter_lower_el_async_ea are same except for
saving x30 register, with previous patch x30 is now freed before calling
these function we don't need both of them.

This patch also unifies the naming convention, now we have 3 handlers
- handle_lower_el_ea_esb
- handle_lower_el_sync_ea
- handle_lower_el_async_ea

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

show more ...

refactor(el3_runtime): introduce save_x30 macro

Most of the macros/routine in vector entry need a free scratch register.
Introduce a macro "save_x30" and call it right at the begining of vector
entr

refactor(el3_runtime): introduce save_x30 macro

Most of the macros/routine in vector entry need a free scratch register.
Introduce a macro "save_x30" and call it right at the begining of vector
entries where x30 is used. It is more exlicit and less error prone

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

show more ...

refactor(el3_runtime): remove unnecessary assembly macros

Following macros removed
- handle_async_ea : It duplicates "check_and_unmask_ea" functionality
- check_if_serror_from_EL3: This macro is

refactor(el3_runtime): remove unnecessary assembly macros

Following macros removed
- handle_async_ea : It duplicates "check_and_unmask_ea" functionality
- check_if_serror_from_EL3: This macro is small and called only once,
replace this macro with instructions at the caller.

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

show more ...

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 ...

fix(el3_runtime): do not save scr_el3 during EL3 entry

scr_el3 registers cannot be modified in lower ELs which means it retains
the same value which is stored in the EL3 cpu context structure for th

fix(el3_runtime): do not save scr_el3 during EL3 entry

scr_el3 registers cannot be modified in lower ELs which means it retains
the same value which is stored in the EL3 cpu context structure for the
given world. So, we should not save the register when entering to EL3
from lower EL as we have the copy of it present in cpu context.

During EL3 execution SCR_EL3 value can be modifed for following cases
1. Changes which is required for EL3 execution, this change is temp
and do not need to be saved.
2. Changes which affects lower EL execution, these changes need to be
written to cpu context as well and will be retrieved when scr_el3
is restored as part of exiting EL3

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

show more ...

Merge changes from topic "mp/ras_refactoring" into integration

* changes:
fix(debug): decouple "get_el_str()" from backtrace
fix(bl31): harden check in delegate_async_ea

feat: pass SMCCCv1.3 SVE hint bit to dispatchers

SMCCCv1.3 introduces the SVE hint bit added to the SMC FID (bit 16)
denoting that the world issuing an SMC doesn't expect the callee to
preserve the

feat: pass SMCCCv1.3 SVE hint bit to dispatchers

SMCCCv1.3 introduces the SVE hint bit added to the SMC FID (bit 16)
denoting that the world issuing an SMC doesn't expect the callee to
preserve the SVE state (FFR, predicates, Zn vector bits greater than
127). Update the generic SMC handler to copy the SVE hint bit state
to SMC flags and mask out the bit by default for the services called
by the standard dispatcher. It is permitted by the SMCCC standard to
ignore the bit as long as the SVE state is preserved. In any case a
callee must preserve the NEON state (FPCR/FPSR, Vn 128b vectors)
whichever the SVE hint bit state.

Signed-off-by: Olivier Deprez <olivier.deprez@arm.com>
Change-Id: I2b163ed83dc311b8f81f96b23c942829ae9fa1b5

show more ...

fix(bl31): harden check in delegate_async_ea

Following hardening done around ESR_EL3 register usage
- Panic if exception is anyting other than SError
- AET bit is only valid if DFSC is 0x11, move

fix(bl31): harden check in delegate_async_ea

Following hardening done around ESR_EL3 register usage
- Panic if exception is anyting other than SError
- AET bit is only valid if DFSC is 0x11, move DFSC check before AET.

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

show more ...

fix(bl31): pass the EA bit to 'delegate_sync_ea'

During a synchronous exception, the 'enter_lower_el_sync_ea' handler
tests the ESR_EL3 EA bit and calls 'report_unhandled_exception', if
it is not se

fix(bl31): pass the EA bit to 'delegate_sync_ea'

During a synchronous exception, the 'enter_lower_el_sync_ea' handler
tests the ESR_EL3 EA bit and calls 'report_unhandled_exception', if
it is not set.

EA = 0 and IFSC = SEA, seems to be a contradiction. EA provides further
classification of a synchronous abort. A synchronous abort is determined
by the IFSC value on an instruction fetch synchronous abort. As a result,
EA will never be set to 1 on an instruction fetch synchronous abort and
'report_unhandled_exception' should not be called.

This patch removes this behavior to allow the platform to handle the
exception.

Signed-off-by: Nicolas Benech <nbenech@nvidia.com>
Signed-off-by: Varun Wadekar <vwadekar@nvidia.com>
Change-Id: I3f004447ad4316d81649063e1ffb3ac644c83ede

show more ...