TSPD: Require NS preemption along with EL3 exception handling

At present, the build option TSP_NS_INTR_ASYNC_PREEMPT controls how
Non-secure interrupt affects TSPs execution. When TSP is executing:

  1. When TSP_NS_INTR_ASYNC_PREEMPT=0, Non-secure interrupts are received
     at the TSP's exception vector, and TSP voluntarily preempts itself.

  2. When TSP_NS_INTR_ASYNC_PREEMPT=1, Non-secure interrupts causes a
     trap to EL3, which preempts TSP execution.

When EL3 exception handling is in place (i.e.,
EL3_EXCEPTION_HANDLING=1), FIQs are always trapped to EL3. On a system
with GICv3, pending NS interrupts while TSP is executing will be
signalled as FIQ (which traps to EL3). This situation necessitates the
same treatment applied to case (2) above.

Therefore, when EL3 exception handling is in place, additionally
require that TSP_NS_INTR_ASYNC_PREEMPT is set to one 1.

Strictly speaking, this is not required on a system with GICv2, but the
same model is uniformly followed regardless, for simplicity.

Relevant documentation updated.

Change-Id: I928a8ed081fb0ac96e8b1dfe9375c98384da1ccd
Signed-off-by: Jeenu Viswambharan <jeenu.viswambharan@arm.com>

2 files changed, 12 insertions, 5 deletions

diff --git a/docs/interrupt-framework-design.rst b/docs/interrupt-framework-design.rst
index d5654870..f65e0559 100644
--- a/docs/interrupt-framework-design.rst
+++ b/docs/interrupt-framework-design.rst
@@ -419,6 +419,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.
 
@@ -813,9 +816,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
@@ -998,7 +1002,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
diff --git a/docs/user-guide.rst b/docs/user-guide.rst
index ed5ba184..8cf15b8e 100644
--- a/docs/user-guide.rst
+++ b/docs/user-guide.rst
@@ -617,6 +617,9 @@ Common build options
    interrupts to TSP allowing it to save its context and hand over
    synchronously to EL3 via an SMC.
 
+   Note: when ``EL3_EXCEPTION_HANDLING`` is ``1``, ``TSP_NS_INTR_ASYNC_PREEMPT``
+   must also be set to ``1``.
+
 -  ``USE_COHERENT_MEM``: This flag determines whether to include the coherent
    memory region in the BL memory map or not (see "Use of Coherent memory in
    Trusted Firmware" section in `Firmware Design`_). It can take the value 1
@@ -1867,7 +1870,7 @@ wakeup interrupt from RTC.
 
 --------------
 
-*Copyright (c) 2013-2017, ARM Limited and Contributors. All rights reserved.*
+*Copyright (c) 2013-2018, ARM Limited and Contributors. All rights reserved.*
 
 .. _Linaro: `Linaro Release Notes`_
 .. _Linaro Release: `Linaro Release Notes`_