From 1a0f8f3957a371b05a147cbfbd8826fa14ae407f Mon Sep 17 00:00:00 2001 From: Jeenu Viswambharan Date: Thu, 16 Nov 2017 12:34:15 +0000 Subject: [PATCH] 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 --- docs/plantuml/sdei_explicit_dispatch.puml | 12 +++++------ docs/plantuml/sdei_explicit_dispatch.svg | 2 +- docs/sdei.rst | 25 +++++++++++++---------- 3 files changed, 21 insertions(+), 18 deletions(-) diff --git a/docs/plantuml/sdei_explicit_dispatch.puml b/docs/plantuml/sdei_explicit_dispatch.puml index 51214f536..c80fcd118 100644 --- a/docs/plantuml/sdei_explicit_dispatch.puml +++ b/docs/plantuml/sdei_explicit_dispatch.puml @@ -9,7 +9,7 @@ autonumber "[#]" 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 diff --git a/docs/plantuml/sdei_explicit_dispatch.svg b/docs/plantuml/sdei_explicit_dispatch.svg index b33944e54..182df0af6 100644 --- a/docs/plantuml/sdei_explicit_dispatch.svg +++ b/docs/plantuml/sdei_explicit_dispatch.svg @@ -1 +1 @@ -SDEI clientSDEI clientEL3EL3SEL1SEL1[1]SDEI_EVENT_REGISTER(ev, handler, ...)[2]success[3]SDEI_EVENT_ENABLE(ev)[4]success[5]SDEI_PE_UNMASK()[6]1<<Business as usual>>[7]CRITICAL EVENTCritical event triage[8]dispatchCritical event handling[9]done[10]sdei_dispatch_event(ev)Prepare SDEI dispatch[11]dispatchSDEI handler[12]SDEI_EVENT_COMPLETE()Complete SDEI dispatch[13]resumes preempted execution<<Normal execution resumes>> \ No newline at end of file +SDEI clientSDEI clientEL3EL3Secure PartitionSecure Partition[1]SDEI_EVENT_REGISTER(ev, handler, ...)[2]success[3]SDEI_EVENT_ENABLE(ev)[4]success[5]SDEI_PE_UNMASK()[6]1<<Business as usual>>[7]CRITICAL EVENTCritical event triage[8]dispatchCritical event handling[9]done[10]sdei_dispatch_event(ev)Prepare SDEI dispatch[11]dispatchSDEI handler[12]SDEI_EVENT_COMPLETE()Complete SDEI dispatch[13]resumes preempted execution<<Normal execution resumes>> \ No newline at end of file diff --git a/docs/sdei.rst b/docs/sdei.rst index 0731a5a81..a67b72486 100644 --- a/docs/sdei.rst +++ b/docs/sdei.rst @@ -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 --------------------