diff options
Diffstat (limited to 'docs/interrupt-framework-design.rst')
| -rw-r--r-- | docs/interrupt-framework-design.rst | 37 |
1 files changed, 21 insertions, 16 deletions
diff --git a/docs/interrupt-framework-design.rst b/docs/interrupt-framework-design.rst index 940bc24f0..0eb7f54f2 100644 --- a/docs/interrupt-framework-design.rst +++ b/docs/interrupt-framework-design.rst @@ -135,7 +135,7 @@ Non-secure interrupts former's state is correctly saved by the latter. #. **CSS=1, TEL3=0**. Interrupt is routed to FEL when execution is in - non-secure state. This is an valid routing model as a non-secure interrupt + non-secure state. This is a valid routing model as a non-secure interrupt is handled by non-secure software. #. **CSS=1, TEL3=1**. Interrupt is routed to EL3 when execution is in @@ -151,6 +151,10 @@ EL3 interrupts in Secure-EL1/Secure-EL0 is in control of how its execution is preempted by EL3 interrupt and can handover the interrupt to EL3 for handling. + However, when ``EL3_EXCEPTION_HANDLING`` is ``1``, this routing model is + invalid as EL3 interrupts are unconditionally routed to EL3, and EL3 + interrupts will always preempt Secure EL1/EL0 execution. + #. **CSS=0, TEL3=1**. Interrupt is routed to EL3 when execution is in Secure-EL1/Secure-EL0. This is a valid routing model as secure software in EL3 can handle the interrupt. @@ -212,17 +216,14 @@ The framework makes the following assumptions to simplify its implementation. #. Interrupt exceptions (``PSTATE.I`` and ``F`` bits) are masked during execution in EL3. -#. .. rubric:: Interrupt management - :name: interrupt-management - - The following sections describe how interrupts are managed by the interrupt - handling framework. This entails: +#. Interrupt management: the following sections describe how interrupts are + managed by the interrupt handling framework. This entails: -#. Providing an interface to allow registration of a handler and specification - of the routing model for a type of interrupt. + #. Providing an interface to allow registration of a handler and + specification of the routing model for a type of interrupt. -#. Implementing support to hand control of an interrupt type to its registered - handler when the interrupt is generated. + #. Implementing support to hand control of an interrupt type to its + registered handler when the interrupt is generated. Both aspects of interrupt management involve various components in the secure software stack spanning from EL3 to Secure-EL1. These components are described @@ -415,6 +416,9 @@ runtime. Test secure payload dispatcher behavior ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ +**Note:** where this document discusses ``TSP_NS_INTR_ASYNC_PREEMPT`` as being +``1``, the same results also apply when ``EL3_EXCEPTION_HANDLING`` is ``1``. + The TSPD only handles Secure-EL1 interrupts and is provided with the following routing model at build time. @@ -678,14 +682,14 @@ the handler function for that type of interrupt. The SPD service is responsible for the following: #. Validating the interrupt. This involves ensuring that the interrupt was - generating according to the interrupt routing model specified by the SPD + generated according to the interrupt routing model specified by the SPD service during registration. It should use the security state of the exception level (passed in the ``flags`` parameter of the handler) where the interrupt was taken from to determine this. If the interrupt is not recognised then the handler should treat it as an irrecoverable error condition. - A SPD service can register a handler for Secure-EL1 and/or Non-secure + An SPD service can register a handler for Secure-EL1 and/or Non-secure interrupts. A non-secure interrupt should never be routed to EL3 from from non-secure state. Also if a routing model is chosen where Secure-EL1 interrupts are routed to S-EL1 when execution is in Secure state, then a @@ -809,9 +813,10 @@ Test secure payload dispatcher non-secure interrupt handling The TSP in Secure-EL1 can be preempted by a non-secure interrupt during ``yielding`` SMC processing or by a higher priority EL3 interrupt during -Secure-EL1 interrupt processing. Currently only non-secure interrupts can -cause preemption of TSP since there are no EL3 interrupts in the -system. +Secure-EL1 interrupt processing. When ``EL3_EXCEPTION_HANDLING`` is ``0``, only +non-secure interrupts can cause preemption of TSP since there are no EL3 +interrupts in the system. With ``EL3_EXCEPTION_HANDLING=1`` however, any EL3 +interrupt may preempt Secure execution. It should be noted that while TSP is preempted, the TSPD only allows entry into the TSP either for Secure-EL1 interrupt handling or for resuming the preempted @@ -994,7 +999,7 @@ TSP by returning ``SMC_UNK`` error. -------------- -*Copyright (c) 2014-2015, ARM Limited and Contributors. All rights reserved.* +*Copyright (c) 2014-2018, ARM Limited and Contributors. All rights reserved.* .. _Porting Guide: ./porting-guide.rst .. _SMC calling convention: http://infocenter.arm.com/help/topic/com.arm.doc.den0028a/index.html |