diff --git a/docs/components/exception-handling.rst b/docs/components/exception-handling.rst
new file mode 100644
index 0000000..e3684f1
--- /dev/null
+++ b/docs/components/exception-handling.rst
@@ -0,0 +1,635 @@
+Exception Handling Framework in Trusted Firmware-A
+==================================================
+
+
+
+
+.. contents::
+    :depth: 2
+
+.. |EHF| replace:: Exception Handling Framework
+.. |TF-A| replace:: Trusted Firmware-A
+
+This document describes various aspects of handling exceptions by Runtime
+Firmware (BL31) that are targeted at EL3, other than SMCs. The |EHF| takes care
+of the following exceptions when targeted at EL3:
+
+-  Interrupts
+-  Synchronous External Aborts
+-  Asynchronous External Aborts
+
+|TF-A|'s handling of synchronous ``SMC`` exceptions raised from lower ELs is
+described in the `Firmware Design document`__. However, the |EHF| changes the
+semantics of `interrupt handling`__ and `synchronous exceptions`__ other than
+SMCs.
+
+.. __: firmware-design.rst#handling-an-smc
+.. __: `Interrupt handling`_
+.. __: `Effect on SMC calls`_
+
+The |EHF| is selected by setting the build option ``EL3_EXCEPTION_HANDLING`` to
+``1``, and is only available for AArch64 systems.
+
+Introduction
+------------
+
+Through various control bits in the ``SCR_EL3`` register, the Arm architecture
+allows for asynchronous exceptions to be routed to EL3. As described in the
+`Interrupt Framework Design`_ document, depending on the chosen interrupt
+routing model, TF-A appropriately sets the ``FIQ`` and ``IRQ`` bits of
+``SCR_EL3`` register to effect this routing. For most use cases, other than for
+the purpose of facilitating context switch between Normal and Secure worlds,
+FIQs and IRQs routed to EL3 are not required to be handled in EL3.
+
+However, the evolving system and standards landscape demands that various
+exceptions are targeted at and handled in EL3. For instance:
+
+-  Starting with ARMv8.2 architecture extension, many RAS features have been
+   introduced to the Arm architecture. With RAS features implemented, various
+   components of the system may use one of the asynchronous exceptions to signal
+   error conditions to PEs. These error conditions are of critical nature, and
+   it's imperative that corrective or remedial actions are taken at the earliest
+   opportunity. Therefore, a *Firmware-first Handling* approach is generally
+   followed in response to RAS events in the system.
+
+-  The Arm `SDEI specification`_ defines interfaces through which Normal world
+   interacts with the Runtime Firmware in order to request notification of
+   system events. The SDEI specification requires that these events are notified
+   even when the Normal world executes with the exceptions masked. This too
+   implies that firmware-first handling is required, where the events are first
+   received by the EL3 firmware, and then dispatched to Normal world through
+   purely software mechanism.
+
+For |TF-A|, firmware-first handling means that asynchronous exceptions are
+suitably routed to EL3, and the Runtime Firmware (BL31) is extended to include
+software components that are capable of handling those exceptions that target
+EL3. These components—referred to as *dispatchers* [#spd]_ in general—may
+choose to:
+
+.. _delegation-use-cases:
+
+-  Receive and handle exceptions entirely in EL3, meaning the exceptions
+   handling terminates in EL3.
+
+-  Receive exceptions, but handle part of the exception in EL3, and delegate the
+   rest of the handling to a dedicated software stack running at lower Secure
+   ELs. In this scheme, the handling spans various secure ELs.
+
+-  Receive exceptions, but handle part of the exception in EL3, and delegate
+   processing of the error to dedicated software stack running at lower secure
+   ELs (as above); additionally, the Normal world may also be required to
+   participate in the handling, or be notified of such events (for example, as
+   an SDEI event). In this scheme, exception handling potentially and maximally
+   spans all ELs in both Secure and Normal worlds.
+
+On any given system, all of the above handling models may be employed
+independently depending on platform choice and the nature of the exception
+received.
+
+.. [#spd] Not to be confused with `Secure Payload Dispatcher`__, which is an
+   EL3 component that operates in EL3 on behalf of Secure OS.
+
+.. __: firmware-design.rst#secure-el1-payloads-and-dispatchers
+
+The role of Exception Handling Framework
+----------------------------------------
+
+Corollary to the use cases cited above, the primary role of the |EHF| is to
+facilitate firmware-first handling of exceptions on Arm systems. The |EHF| thus
+enables multiple exception dispatchers in runtime firmware to co-exist, register
+for, and handle exceptions targeted at EL3. This section outlines the basics,
+and the rest of this document expands the various aspects of the |EHF|.
+
+In order to arbitrate exception handling among dispatchers, the |EHF| operation
+is based on a priority scheme. This priority scheme is closely tied to how the
+Arm GIC architecture defines it, although it's applied to non-interrupt
+exceptions too (SErrors, for example).
+
+The platform is required to `partition`__ the Secure priority space into
+priority levels as applicable for the Secure software stack. It then assigns the
+dispatchers to one or more priority levels. The dispatchers then register
+handlers for the priority levels at runtime. A dispatcher can register handlers
+for more than one priority level.
+
+.. __: `Partitioning priority levels`_
+
+
+.. _ehf-figure:
+
+.. image:: ../draw.io/ehf.svg
+
+A priority level is *active* when a handler at that priority level is currently
+executing in EL3, or has delegated the execution to a lower EL. For interrupts,
+this is implicit when an interrupt is targeted and acknowledged at EL3, and the
+priority of the acknowledged interrupt is used to match its registered handler.
+The priority level is likewise implicitly deactivated when the interrupt
+handling concludes by EOIing the interrupt.
+
+Non-interrupt exceptions (SErrors, for example) don't have a notion of priority.
+In order for the priority arbitration to work, the |EHF| provides APIs in order
+for these non-interrupt exceptions to assume a priority, and to interwork with
+interrupts. Dispatchers handling such exceptions must therefore explicitly
+activate and deactivate the respective priority level as and when they're
+handled or delegated.
+
+Because priority activation and deactivation for interrupt handling is implicit
+and involves GIC priority masking, it's impossible for a lower priority
+interrupt to preempt a higher priority one. By extension, this means that a
+lower priority dispatcher cannot preempt a higher-priority one. Priority
+activation and deactivation for non-interrupt exceptions, however, has to be
+explicit. The |EHF| therefore disallows for lower priority level to be activated
+whilst a higher priority level is active, and would result in a panic.
+Likewise, a panic would result if it's attempted to deactivate a lower priority
+level when a higher priority level is active.
+
+In essence, priority level activation and deactivation conceptually works like a
+stack—priority levels stack up in strictly increasing fashion, and need to be
+unstacked in strictly the reverse order. For interrupts, the GIC ensures this is
+the case; for non-interrupts, the |EHF| monitors and asserts this. See
+`Transition of priority levels`_.
+
+Interrupt handling
+------------------
+
+The |EHF| is a client of *Interrupt Management Framework*, and registers the
+top-level handler for interrupts that target EL3, as described in the `Interrupt
+Framework Design`_ document. This has the following implications.
+
+-  On GICv3 systems, when executing in S-EL1, pending Non-secure interrupts of
+   sufficient priority are signalled as FIQs, and therefore will be routed to
+   EL3. As a result, S-EL1 software cannot expect to handle Non-secure
+   interrupts at S-EL1. Essentially, this deprecates the routing mode described
+   as `CSS=0, TEL3=0`__.
+
+   .. __: interrupt-framework-design.rst#el3-interrupts
+
+   In order for S-EL1 software to handle Non-secure interrupts while having
+   |EHF| enabled, the dispatcher must adopt a model where Non-secure interrupts
+   are received at EL3, but are then `synchronously`__ handled over to S-EL1.
+
+   .. __: interrupt-framework-design.rst#secure-payload
+
+-  On GICv2 systems, it's required that the build option ``GICV2_G0_FOR_EL3`` is
+   set to ``1`` so that *Group 0* interrupts target EL3.
+
+-  While executing in Secure world, |EHF| sets GIC Priority Mask Register to the
+   lowest Secure priority. This means that no Non-secure interrupts can preempt
+   Secure execution. See `Effect on SMC calls`_ for more details.
+
+As mentioned above, with |EHF|, the platform is required to partition *Group 0*
+interrupts into distinct priority levels. A dispatcher that chooses to receive
+interrupts can then *own* one or more priority levels, and register interrupt
+handlers for them. A given priority level can be assigned to only one handler. A
+dispatcher may register more than one priority level.
+
+Dispatchers are assigned interrupt priority levels in two steps:
+
+Partitioning priority levels
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+Interrupts are associated to dispatchers by way of grouping and assigning
+interrupts to a priority level. In other words, all interrupts that are to
+target a particular dispatcher should fall in a particular priority level. For
+priority assignment:
+
+-  Of the 8 bits of priority that Arm GIC architecture permits, bit 7 must be 0
+   (secure space).
+
+-  Depending on the number of dispatchers to support, the platform must choose
+   to use the top *n* of the 7 remaining bits to identify and assign interrupts
+   to individual dispatchers. Choosing *n* bits supports up to 2\ :sup:`n`
+   distinct dispatchers. For example, by choosing 2 additional bits (i.e., bits
+   6 and 5), the platform can partition into 4 secure priority ranges: ``0x0``,
+   ``0x20``, ``0x40``, and ``0x60``. See `Interrupt handling example`_.
+
+Note:
+
+   The Arm GIC architecture requires that a GIC implementation that supports two
+   security states must implement at least 32 priority levels; i.e., at least 5
+   upper bits of the 8 bits are writeable. In the scheme described above, when
+   choosing *n* bits for priority range assignment, the platform must ensure
+   that at least ``n+1`` top bits of GIC priority are writeable.
+
+The priority thus assigned to an interrupt is also used to determine the
+priority of delegated execution in lower ELs. Delegated execution in lower EL is
+associated with a priority level chosen with ``ehf_activate_priority()`` API
+(described `later`__). The chosen priority level also determines the interrupts
+masked while executing in a lower EL, therefore controls preemption of delegated
+execution.
+
+.. __: `ehf-apis`_
+
+The platform expresses the chosen priority levels by declaring an array of
+priority level descriptors. Each entry in the array is of type
+``ehf_pri_desc_t``, and declares a priority level, and shall be populated by the
+``EHF_PRI_DESC()`` macro.
+
+Note:
+
+   The macro ``EHF_PRI_DESC()`` installs the descriptors in the array at a
+   computed index, and not necessarily where the macro is placed in the array.
+   The size of the array might therefore be larger than what it appears to be.
+   The ``ARRAY_SIZE()`` macro therefore should be used to determine the size of
+   array.
+
+Finally, this array of descriptors is exposed to |EHF| via the
+``EHF_REGISTER_PRIORITIES()`` macro.
+
+Refer to the `Interrupt handling example`_ for usage. See also: `Interrupt
+Prioritisation Considerations`_.
+
+Programming priority
+~~~~~~~~~~~~~~~~~~~~
+
+The text in `Partitioning priority levels`_ only describes how the platform
+expresses the required levels of priority. It however doesn't choose interrupts
+nor program the required priority in GIC.
+
+The `Firmware Design guide`__ explains methods for configuring secure
+interrupts. |EHF| requires the platform to enumerate interrupt properties (as
+opposed to just numbers) of Secure interrupts. The priority of secure interrupts
+must match that as determined in the `Partitioning priority levels`_ section above.
+
+.. __: firmware-design.rst#configuring-secure-interrupts
+
+See `Limitations`_, and also refer to `Interrupt handling example`_ for
+illustration.
+
+Registering handler
+-------------------
+
+Dispatchers register handlers for their priority levels through the following
+API:
+
+.. code:: c
+
+   int ehf_register_priority_handler(int pri, ehf_handler_t handler)
+
+The API takes two arguments:
+
+-  The priority level for which the handler is being registered;
+
+-  The handler to be registered. The handler must be aligned to 4 bytes.
+
+If a dispatcher owns more than one priority levels, it has to call the API for
+each of them.
+
+The API will succeed, and return ``0``, only if:
+
+-  There exists a descriptor with the priority level requested.
+
+-  There are no handlers already registered by a previous call to the API.
+
+Otherwise, the API returns ``-1``.
+
+The interrupt handler should have the following signature:
+
+.. code:: c
+
+   typedef int (*ehf_handler_t)(uint32_t intr_raw, uint32_t flags, void *handle,
+                   void *cookie);
+
+The parameters are as obtained from the top-level `EL3 interrupt handler`__.
+
+.. __: interrupt-framework-design.rst#el3-runtime-firmware
+
+The `SDEI dispatcher`__, for example, expects the platform to allocate two
+different priority levels—``PLAT_SDEI_CRITICAL_PRI``, and
+``PLAT_SDEI_NORMAL_PRI``—and registers the same handler to handle both levels.
+
+.. __: sdei.rst
+
+Interrupt handling example
+--------------------------
+
+The following annotated snippet demonstrates how a platform might choose to
+assign interrupts to fictitious dispatchers:
+
+.. code:: c
+
+   #include <common/interrupt_props.h>
+   #include <drivers/arm/gic_common.h>
+   #include <exception_mgmt.h>
+
+   ...
+
+   /*
+    * This platform uses 2 bits for interrupt association. In total, 3 upper
+    * bits are in use.
+    *
+    *  7 6 5   3      0
+    * .-.-.-.----------.
+    * |0|b|b|  ..0..   |
+    * '-'-'-'----------'
+    */
+   #define PLAT_PRI_BITS        2
+
+   /* Priorities for individual dispatchers */
+   #define DISP0_PRIO           0x00 /* Not used */
+   #define DISP1_PRIO           0x20
+   #define DISP2_PRIO           0x40
+   #define DISP3_PRIO           0x60
+
+   /* Install priority level descriptors for each dispatcher */
+   ehf_pri_desc_t plat_exceptions[] = {
+        EHF_PRI_DESC(PLAT_PRI_BITS, DISP1_PRIO),
+        EHF_PRI_DESC(PLAT_PRI_BITS, DISP2_PRIO),
+        EHF_PRI_DESC(PLAT_PRI_BITS, DISP3_PRIO),
+   };
+
+   /* Expose priority descriptors to Exception Handling Framework */
+   EHF_REGISTER_PRIORITIES(plat_exceptions, ARRAY_SIZE(plat_exceptions),
+        PLAT_PRI_BITS);
+
+   ...
+
+   /* List interrupt properties for GIC driver. All interrupts target EL3 */
+   const interrupt_prop_t plat_interrupts[] = {
+        /* Dispatcher 1 owns interrupts d1_0 and d1_1, so assigns priority DISP1_PRIO */
+        INTR_PROP_DESC(d1_0, DISP1_PRIO, INTR_TYPE_EL3, GIC_INTR_CFG_LEVEL),
+        INTR_PROP_DESC(d1_1, DISP1_PRIO, INTR_TYPE_EL3, GIC_INTR_CFG_LEVEL),
+
+        /* Dispatcher 2 owns interrupts d2_0 and d2_1, so assigns priority DISP2_PRIO */
+        INTR_PROP_DESC(d2_0, DISP2_PRIO, INTR_TYPE_EL3, GIC_INTR_CFG_LEVEL),
+        INTR_PROP_DESC(d2_1, DISP2_PRIO, INTR_TYPE_EL3, GIC_INTR_CFG_LEVEL),
+
+        /* Dispatcher 3 owns interrupts d3_0 and d3_1, so assigns priority DISP3_PRIO */
+        INTR_PROP_DESC(d3_0, DISP3_PRIO, INTR_TYPE_EL3, GIC_INTR_CFG_LEVEL),
+        INTR_PROP_DESC(d3_1, DISP3_PRIO, INTR_TYPE_EL3, GIC_INTR_CFG_LEVEL),
+   };
+
+   ...
+
+   /* Dispatcher 1 registers its handler */
+   ehf_register_priority_handler(DISP1_PRIO, disp1_handler);
+
+   /* Dispatcher 2 registers its handler */
+   ehf_register_priority_handler(DISP2_PRIO, disp2_handler);
+
+   /* Dispatcher 3 registers its handler */
+   ehf_register_priority_handler(DISP3_PRIO, disp3_handler);
+
+   ...
+
+See also the `Build-time flow`_ and the `Run-time flow`_.
+
+Activating and Deactivating priorities
+--------------------------------------
+
+A priority level is said to be *active* when an exception of that priority is
+being handled: for interrupts, this is implied when the interrupt is
+acknowledged; for non-interrupt exceptions, such as SErrors or `SDEI explicit
+dispatches`__, this has to be done via calling ``ehf_activate_priority()``. See
+`Run-time flow`_.
+
+.. __: sdei.rst#explicit-dispatch-of-events
+
+Conversely, when the dispatcher has reached a logical resolution for the cause
+of the exception, the corresponding priority level ought to be deactivated. As
+above, for interrupts, this is implied when the interrupt is EOId in the GIC;
+for other exceptions, this has to be done via calling
+``ehf_deactivate_priority()``.
+
+Thanks to `different provisions`__ for exception delegation, there are
+potentially more than one work flow for deactivation:
+
+.. __: `delegation-use-cases`_
+
+.. _deactivation workflows:
+
+-  The dispatcher has addressed the cause of the exception, and decided to take
+   no further action. In this case, the dispatcher's handler deactivates the
+   priority level before returning to the |EHF|. Runtime firmware, upon exit
+   through an ``ERET``, resumes execution before the interrupt occurred.
+
+-  The dispatcher has to delegate the execution to lower ELs, and the cause of
+   the exception can be considered resolved only when the lower EL returns
+   signals complete (via an ``SMC``) at a future point in time. The following
+   sequence ensues:
+
+   #. The dispatcher calls ``setjmp()`` to setup a jump point, and arranges to
+      enter a lower EL upon the next ``ERET``.
+
+   #. Through the ensuing ``ERET`` from runtime firmware, execution is delegated
+      to a lower EL.
+
+   #. The lower EL completes its execution, and signals completion via an
+      ``SMC``.
+
+   #. The ``SMC`` is handled by the same dispatcher that handled the exception
+      previously. Noticing the conclusion of exception handling, the dispatcher
+      does ``longjmp()`` to resume beyond the previous jump point.
+
+As mentioned above, the |EHF| provides the following APIs for activating and
+deactivating interrupt:
+
+.. _ehf-apis:
+
+-  ``ehf_activate_priority()`` activates the supplied priority level, but only
+   if the current active priority is higher than the given one; otherwise
+   panics. Also, to prevent interruption by physical interrupts of lower
+   priority, the |EHF| programs the *Priority Mask Register* corresponding to
+   the PE to the priority being activated.  Dispatchers typically only need to
+   call this when handling exceptions other than interrupts, and it needs to
+   delegate execution to a lower EL at a desired priority level.
+
+-  ``ehf_deactivate_priority()`` deactivates a given priority, but only if the
+   current active priority is equal to the given one; otherwise panics. |EHF|
+   also restores the *Priority Mask Register* corresponding to the PE to the
+   priority before the call to ``ehf_activate_priority()``. Dispatchers
+   typically only need to call this after handling exceptions other than
+   interrupts.
+
+The calling of APIs are subject to allowed `transitions`__. See also the
+`Run-time flow`_.
+
+.. __: `Transition of priority levels`_
+
+Transition of priority levels
+-----------------------------
+
+The |EHF| APIs ``ehf_activate_priority()`` and ``ehf_deactivate_priority()`` can
+be called to transition the current priority level on a PE. A given sequence of
+calls to these APIs are subject to the following conditions:
+
+-  For activation, the |EHF| only allows for the priority to increase (i.e.
+   numeric value decreases);
+
+-  For deactivation, the |EHF| only allows for the priority to decrease (i.e.
+   numeric value increases). Additionally, the priority being deactivated is
+   required to be the current priority.
+
+If these are violated, a panic will result.
+
+Effect on SMC calls
+-------------------
+
+In general, Secure execution is regarded as more important than Non-secure
+execution. As discussed elsewhere in this document, EL3 execution, and any
+delegated execution thereafter, has the effect of raising GIC's priority
+mask—either implicitly by acknowledging Secure interrupts, or when dispatchers
+call ``ehf_activate_priority()``. As a result, Non-secure interrupts cannot
+preempt any Secure execution.
+
+SMCs from Non-secure world are synchronous exceptions, and are mechanisms for
+Non-secure world to request Secure services. They're broadly classified as
+*Fast* or *Yielding* (see `SMCCC`__).
+
+.. __: `http://infocenter.arm.com/help/topic/com.arm.doc.den0028a/index.html`
+
+-  *Fast* SMCs are atomic from the caller's point of view. I.e., they return
+   to the caller only when the Secure world has finished serving the request.
+   Any Non-secure interrupts that become pending meanwhile cannot preempt Secure
+   execution.
+
+-  *Yielding* SMCs carry the semantics of a preemptible, lower-priority request.
+   A pending Non-secure interrupt can preempt Secure execution handling a
+   Yielding SMC. I.e., the caller might observe a Yielding SMC returning when
+   either:
+
+   #. Secure world completes the request, and the caller would find ``SMC_OK``
+      as the return code.
+
+   #. A Non-secure interrupt preempts Secure execution. Non-secure interrupt is
+      handled, and Non-secure execution resumes after ``SMC`` instruction.
+
+   The dispatcher handling a Yielding SMC must provide a different return code
+   to the Non-secure caller to distinguish the latter case. This return code,
+   however, is not standardised (unlike ``SMC_UNKNOWN`` or ``SMC_OK``, for
+   example), so will vary across dispatchers that handle the request.
+
+For the latter case above, dispatchers before |EHF| expect Non-secure interrupts
+to be taken to S-EL1 [#irq]_, so would get a chance to populate the designated
+preempted error code before yielding to Non-secure world.
+
+The introduction of |EHF| changes the behaviour as described in `Interrupt
+handling`_.
+
+When |EHF| is enabled, in order to allow Non-secure interrupts to preempt
+Yielding SMC handling, the dispatcher must call ``ehf_allow_ns_preemption()``
+API. The API takes one argument, the error code to be returned to the Non-secure
+world upon getting preempted.
+
+.. [#irq] In case of GICv2, Non-secure interrupts while in S-EL1 were signalled
+          as IRQs, and in case of GICv3, FIQs.
+
+Build-time flow
+---------------
+
+Please refer to the `figure`__ above.
+
+.. __: `ehf-figure`_
+
+The build-time flow involves the following steps:
+
+#. Platform assigns priorities by installing priority level descriptors for
+   individual dispatchers, as described in `Partitioning priority levels`_.
+
+#. Platform provides interrupt properties to GIC driver, as described in
+   `Programming priority`_.
+
+#. Dispatcher calling ``ehf_register_priority_handler()`` to register an
+   interrupt handler.
+
+Also refer to the `Interrupt handling example`_.
+
+Run-time flow
+-------------
+
+.. _interrupt-flow:
+
+The following is an example flow for interrupts:
+
+#. The GIC driver, during initialization, iterates through the platform-supplied
+   interrupt properties (see `Programming priority`_), and configures the
+   interrupts. This programs the appropriate priority and group (Group 0) on
+   interrupts belonging to different dispatchers.
+
+#. The |EHF|, during its initialisation, registers a top-level interrupt handler
+   with the `Interrupt Management Framework`__ for EL3 interrupts. This also
+   results in setting the routing bits in ``SCR_EL3``.
+
+   .. __: interrupt-framework-design.rst#el3-runtime-firmware
+
+#. When an interrupt belonging to a dispatcher fires, GIC raises an EL3/Group 0
+   interrupt, and is taken to EL3.
+
+#. The top-level EL3 interrupt handler executes. The handler acknowledges the
+   interrupt, reads its *Running Priority*, and from that, determines the
+   dispatcher handler.
+
+#. The |EHF| programs the *Priority Mask Register* of the PE to the priority of
+   the interrupt received.
+
+#. The |EHF| marks that priority level *active*, and jumps to the dispatcher
+   handler.
+
+#. Once the dispatcher handler finishes its job, it has to immediately
+   *deactivate* the priority level before returning to the |EHF|. See
+   `deactivation workflows`_.
+
+.. _non-interrupt-flow:
+
+The following is an example flow for exceptions that targets EL3 other than
+interrupt:
+
+#. The platform provides handlers for the specific kind of exception.
+
+#. The exception arrives, and the corresponding handler is executed.
+
+#. The handler calls ``ehf_activate_priority()`` to activate the required
+   priority level. This also has the effect of raising GIC priority mask, thus
+   preventing interrupts of lower priority from preempting the handling. The
+   handler may choose to do the handling entirely in EL3 or delegate to a lower
+   EL.
+
+#. Once exception handling concludes, the handler calls
+   ``ehf_deactivate_priority()`` to deactivate the priority level activated
+   earlier. This also has the effect of lowering GIC priority mask to what it
+   was before.
+
+Interrupt Prioritisation Considerations
+---------------------------------------
+
+The GIC priority scheme, by design, prioritises Secure interrupts over Normal
+world ones. The platform further assigns relative priorities amongst Secure
+dispatchers through |EHF|.
+
+As mentioned in `Partitioning priority levels`_, interrupts targeting distinct
+dispatchers fall in distinct priority levels. Because they're routed via the
+GIC, interrupt delivery to the PE is subject to GIC prioritisation rules. In
+particular, when an interrupt is being handled by the PE (i.e., the interrupt is
+in *Active* state), only interrupts of higher priority are signalled to the PE,
+even if interrupts of same or lower priority are pending. This has the side
+effect of one dispatcher being starved of interrupts by virtue of another
+dispatcher handling its (higher priority) interrupts.
+
+The |EHF| doesn't enforce a particular prioritisation policy, but the platform
+should carefully consider the assignment of priorities to dispatchers integrated
+into runtime firmware. The platform should sensibly delineate priority to
+various dispatchers according to their nature. In particular, dispatchers of
+critical nature (RAS, for example) should be assigned higher priority than
+others (SDEI, for example); and within SDEI, Critical priority SDEI should be
+assigned higher priority than Normal ones.
+
+Limitations
+-----------
+
+The |EHF| has the following limitations:
+
+-  Although there could be up to 128 Secure dispatchers supported by the GIC
+   priority scheme, the size of descriptor array exposed with
+   ``EHF_REGISTER_PRIORITIES()`` macro is currently limited to 32. This serves most
+   expected use cases. This may be expanded in the future, should use cases
+   demand so.
+
+-  The platform must ensure that the priority assigned to the dispatcher in the
+   exception descriptor and the programmed priority of interrupts handled by the
+   dispatcher match. The |EHF| cannot verify that this has been followed.
+
+----
+
+*Copyright (c) 2018, Arm Limited and Contributors. All rights reserved.*
+
+.. _Interrupt Framework Design: interrupt-framework-design.rst
+.. _SDEI specification: http://infocenter.arm.com/help/topic/com.arm.doc.den0054a/ARM_DEN0054A_Software_Delegated_Exception_Interface.pdf