Bug fix in tspd interrupt handling when TSP_NS_INTR_ASYNC_PREEMPT is enabled
Typically, interrupts for a specific security state get handled in the
same security execption level if the execution is in the same security
state. For example, if a non-secure interrupt gets fired when CPU is
executing in NS-EL2 it gets handled in the non-secure world.
However, interrupts belonging to the opposite security state typically
demand a world(context) switch. This is inline with the security
principle which states a secure interrupt has to be handled in the
secure world. Hence, the TSPD in EL3 expects the context(handle) for a
secure interrupt to be non-secure and vice versa.
The function "tspd_sel1_interrupt_handler" is the handler registered
for S-EL1 interrupts by the TSPD. Based on the above assumption, it
provides an assertion to validate if the interrupt originated from
non-secure world and upon success arranges entry into the TSP at
'tsp_sel1_intr_entry' for handling the interrupt.
However, a race condition between non-secure and secure interrupts can
lead to a scenario where the above assumptions do not hold true and
further leading to following assert fail.
This patch fixes the bug which causes this assert fail:
ASSERT: services/spd/tspd/tspd_main.c:105
BACKTRACE: START: assert
0: EL3: 0x400c128
1: EL3: 0x400faf8
2: EL3: 0x40099a4
3: EL3: 0x4010d54
BACKTRACE: END: assert
Change-Id: I359d30fb5dbb1429a4a3c3fff37fdc64c07e9414
Signed-off-by: Madhukar Pappireddy <madhukar.pappireddy@arm.com>
Please register or sign in to comment