interrupt-framework-design.rst: Cosmetic changes

Change-Id: Id2e2800af59ca35fc0c4cfdddd9f5c5afd56a4db
Signed-off-by: Jeenu Viswambharan <jeenu.viswambharan@arm.com>
This commit is contained in:
Jeenu Viswambharan 2018-01-10 14:56:03 +00:00
parent 6027796fff
commit fb750ee161
1 changed files with 9 additions and 12 deletions

View File

@ -135,7 +135,7 @@ Non-secure interrupts
former's state is correctly saved by the latter. former's state is correctly saved by the latter.
#. **CSS=1, TEL3=0**. Interrupt is routed to FEL when execution is in #. **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. is handled by non-secure software.
#. **CSS=1, TEL3=1**. Interrupt is routed to EL3 when execution is in #. **CSS=1, TEL3=1**. Interrupt is routed to EL3 when execution is in
@ -216,17 +216,14 @@ The framework makes the following assumptions to simplify its implementation.
#. Interrupt exceptions (``PSTATE.I`` and ``F`` bits) are masked during execution #. Interrupt exceptions (``PSTATE.I`` and ``F`` bits) are masked during execution
in EL3. in EL3.
#. .. rubric:: Interrupt management #. Interrupt management: the following sections describe how interrupts are
:name: interrupt-management managed by the interrupt handling framework. This entails:
The following sections describe how interrupts are managed by the interrupt #. Providing an interface to allow registration of a handler and
handling framework. This entails: specification of the routing model for a type of interrupt.
#. Providing an interface to allow registration of a handler and specification #. Implementing support to hand control of an interrupt type to its
of the routing model for a type of interrupt. 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 Both aspects of interrupt management involve various components in the secure
software stack spanning from EL3 to Secure-EL1. These components are described software stack spanning from EL3 to Secure-EL1. These components are described
@ -685,14 +682,14 @@ the handler function for that type of interrupt. The SPD service is responsible
for the following: for the following:
#. Validating the interrupt. This involves ensuring that the interrupt was #. 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 service during registration. It should use the security state of the
exception level (passed in the ``flags`` parameter of the handler) where exception level (passed in the ``flags`` parameter of the handler) where
the interrupt was taken from to determine this. If the interrupt is not the interrupt was taken from to determine this. If the interrupt is not
recognised then the handler should treat it as an irrecoverable error recognised then the handler should treat it as an irrecoverable error
condition. 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 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 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 interrupts are routed to S-EL1 when execution is in Secure state, then a