SDEI: Make dispatches synchronous

SDEI event dispatches currently only sets up the Non-secure context
before returning to the caller. The actual dispatch only happens upon
exiting EL3 next time.

However, for various error handling scenarios, it's beneficial to have
the dispatch happen synchronously. I.e. when receiving SDEI interrupt,
or for a successful sdei_dispatch_event() call, the event handler is
executed; and upon the event completion, dispatcher execution resumes
after the point of dispatch. The jump primitives introduced in the
earlier patch facilitates this feature.

With this patch:

  - SDEI interrupts and calls to sdei_dispatch_event prepares the NS
    context for event dispatch, then sets a jump point, and immediately
    exits EL3. This results in the client handler executing in
    Non-secure.

  - When the SDEI client completes the dispatched event, the SDEI
    dispatcher does a longjmp to the jump pointer created earlier. For
    the caller of the sdei_dispatch_event() in particular, this would
    appear as if call returned successfully.

The dynamic workaround for CVE_2018_3639 is slightly shifted around as
part of related minor refactoring. It doesn't affect the workaround
functionality.

Documentation updated.

NOTE: This breaks the semantics of the explicit dispatch API, and any
exiting usages should be carefully reviewed.

Change-Id: Ib9c876d27ea2af7fb22de49832e55a0da83da3f9
Signed-off-by: Jeenu Viswambharan <jeenu.viswambharan@arm.com>
diff --git a/docs/plantuml/sdei_explicit_dispatch.puml b/docs/plantuml/sdei_explicit_dispatch.puml
index c80fcd1..90ff23c 100644
--- a/docs/plantuml/sdei_explicit_dispatch.puml
+++ b/docs/plantuml/sdei_explicit_dispatch.puml
@@ -1,5 +1,5 @@
 /'
- ' Copyright (c) 2017, ARM Limited and Contributors. All rights reserved.
+ ' Copyright (c) 2017-2018, ARM Limited and Contributors. All rights reserved.
  '
  ' SPDX-License-Identifier: BSD-3-Clause
  '/
@@ -9,7 +9,8 @@
 autonumber "<b>[#]</b>"
 participant "SDEI client" as EL2
 participant EL3
-participant "Secure Partition" as SP
+participant SDEI
+participant "RAS Driver" as RAS
 
 activate EL2
 EL2->EL3: **SDEI_EVENT_REGISTER**(ev, handler, ...)
@@ -24,21 +25,26 @@
 EL3<--]: **CRITICAL EVENT**
 activate EL3 #red
 note over EL3: Critical event triage
-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
+EL3->RAS: dispatch to handle
+deactivate EL3
+activate RAS #salmon
+note over RAS: Critical event handling
+RAS-->SDEI: sdei_dispatch_event(ev)
+deactivate RAS
+activate SDEI #salmon
+note over SDEI: Prepare SDEI dispatch
+SDEI->EL2: dispatch
 activate EL2 #salmon
 note over EL2: SDEI handler
-EL2->EL3: **SDEI_EVENT_COMPLETE()**
+EL2->SDEI: **SDEI_EVENT_COMPLETE()**
 deactivate EL2
-note over EL3: Complete SDEI dispatch
+note over SDEI: Complete SDEI dispatch
+SDEI-->RAS: return
+deactivate SDEI
+activate RAS #salmon
+RAS->EL3: error handling done
+deactivate RAS
 EL3->EL2: resumes preempted execution
-deactivate EL3
 
 ... <<Normal execution resumes>> ...