SDEI: Update doc to clarify delegation
The explicit event dispatch sequence currently depicts handling done in Secure EL1, although further error handling is typically done inside a Secure Partition. Clarify the sequence diagram to that effect. Change-Id: I53deedc6d5ee0706626890067950c2c541a62c78 Signed-off-by: Jeenu Viswambharan <jeenu.viswambharan@arm.com>
This commit is contained in:
parent
f1a67d0565
commit
1a0f8f3957
|
@ -9,7 +9,7 @@
|
|||
autonumber "<b>[#]</b>"
|
||||
participant "SDEI client" as EL2
|
||||
participant EL3
|
||||
participant SEL1
|
||||
participant "Secure Partition" as SP
|
||||
|
||||
activate EL2
|
||||
EL2->EL3: **SDEI_EVENT_REGISTER**(ev, handler, ...)
|
||||
|
@ -24,11 +24,11 @@ EL3->EL2: 1
|
|||
EL3<--]: **CRITICAL EVENT**
|
||||
activate EL3 #red
|
||||
note over EL3: Critical event triage
|
||||
EL3->SEL1: dispatch
|
||||
activate SEL1 #salmon
|
||||
note over SEL1: Critical event handling
|
||||
SEL1->EL3: done
|
||||
deactivate SEL1
|
||||
EL3->SP: dispatch
|
||||
activate SP #salmon
|
||||
note over SP: Critical event handling
|
||||
SP->EL3: done
|
||||
deactivate SP
|
||||
EL3-->EL3: sdei_dispatch_event(ev)
|
||||
note over EL3: Prepare SDEI dispatch
|
||||
EL3->EL2: dispatch
|
||||
|
|
File diff suppressed because one or more lines are too long
Before Width: | Height: | Size: 18 KiB After Width: | Height: | Size: 18 KiB |
|
@ -232,13 +232,20 @@ bound or dynamic events can't be explicitly dispatched (see the section below).
|
|||
|
||||
At a later point in time, a critical event [#critical-event]_ is trapped into
|
||||
EL3 [7]. EL3 performs a first-level triage of the event, and decides to dispatch
|
||||
to Secure EL1 for further handling [8]. The dispatch completes, but intends to
|
||||
involve Non-secure world in further handling, and therefore decides to
|
||||
explicitly dispatch an event [10] (which the client had already registered for
|
||||
[1]). The rest of the sequence is similar to that in the `general SDEI
|
||||
dispatch`_: the requested event is dispatched to the client (assuming all the
|
||||
conditions are met), and when the handler completes, the preempted execution
|
||||
resumes.
|
||||
to a Secure Partition [#secpart]_ for further handling [8]. The dispatch
|
||||
completes, but intends to involve Non-secure world in further handling, and
|
||||
therefore decides to explicitly dispatch an event [10] (which the client had
|
||||
already registered for [1]). The rest of the sequence is similar to that in the
|
||||
`general SDEI dispatch`_: the requested event is dispatched to the client
|
||||
(assuming all the conditions are met), and when the handler completes, the
|
||||
preempted execution resumes.
|
||||
|
||||
.. [#critical-event] Examples of critical event are *SError*, *Synchronous
|
||||
External Abort*, *Fault Handling interrupt*, or *Error
|
||||
Recovery interrupt* from one of RAS nodes in the system.
|
||||
|
||||
.. [#secpart] Dispatching to Secure Partition involves *Secure Partition
|
||||
Manager*, which isn't depicted in the sequence.
|
||||
|
||||
Conditions for event dispatch
|
||||
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
|
||||
|
@ -295,10 +302,6 @@ dispatcher:
|
|||
context is resumed (as indicated by the ``preempted_sec_state`` parameter of
|
||||
the API).
|
||||
|
||||
.. [#critical-event] Examples of critical event are *SError*, *Synchronous
|
||||
External Abort*, *Fault Handling interrupt*, or *Error
|
||||
Recovery interrupt* from one of RAS nodes in the system.
|
||||
|
||||
Porting requirements
|
||||
--------------------
|
||||
|
||||
|
|
Loading…
Reference in New Issue