Lines Matching +full:implicit +full:- +full:fall +full:- +full:through
8 - Interrupts
9 - Synchronous External Aborts
10 - Asynchronous External Aborts
12 |TF-A|'s handling of synchronous ``SMC`` exceptions raised from lower ELs is
13 described in the :ref:`Firmware Design document <handling-an-smc>`. However, the
21 ------------
23 Through various control bits in the ``SCR_EL3`` register, the Arm architecture
26 interrupt routing model, TF-A appropriately sets the ``FIQ`` and ``IRQ`` bits of
34 - Starting with ARMv8.2 architecture extension, many RAS features have been
39 opportunity. Therefore, a *Firmware-first Handling* approach is generally
42 - The Arm `SDEI specification`_ defines interfaces through which Normal world
46 too implies that firmware-first handling is required, where the events are
48 through purely software mechanism.
50 For |TF-A|, firmware-first handling means that asynchronous exceptions are
56 .. _delegation-use-cases:
58 - Receive and handle exceptions entirely in EL3, meaning the exceptions
61 - Receive exceptions, but handle part of the exception in EL3, and delegate the
65 - Receive exceptions, but handle part of the exception in EL3, and delegate
81 ----------------------------------------
84 facilitate firmware-first handling of exceptions on Arm systems. The |EHF| thus
85 enables multiple exception dispatchers in runtime firmware to co-exist, register
91 Arm GIC architecture defines it, although it's applied to non-interrupt
103 .. _ehf-figure:
109 this is implicit when an interrupt is targeted and acknowledged at EL3, and the
114 Non-interrupt exceptions (SErrors, for example) don't have a notion of priority.
116 for these non-interrupt exceptions to assume a priority, and to interwork with
121 Because priority activation and deactivation for interrupt handling is implicit
124 lower priority dispatcher cannot preempt a higher-priority one. Priority
125 activation and deactivation for non-interrupt exceptions, however, has to be
134 the case; for non-interrupts, the |EHF| monitors and asserts this. See
137 .. _interrupt-handling:
140 ------------------
143 top-level handler for interrupts that target EL3, as described in the
147 - On GICv3 systems, when executing in S-EL1, pending Non-secure interrupts of
149 EL3. As a result, S-EL1 software cannot expect to handle Non-secure
150 interrupts at S-EL1. Essentially, this deprecates the routing mode described
153 In order for S-EL1 software to handle Non-secure interrupts while having
154 |EHF| enabled, the dispatcher must adopt a model where Non-secure interrupts
155 are received at EL3, but are then :ref:`synchronously <sp-synchronous-int>`
156 handled over to S-EL1.
158 - On GICv2 systems, it's required that the build option ``GICV2_G0_FOR_EL3`` is
161 - While executing in Secure world, |EHF| sets GIC Priority Mask Register to the
162 lowest Secure priority. This means that no Non-secure interrupts can preempt
180 target a particular dispatcher should fall in a particular priority level. For
183 - Of the 8 bits of priority that Arm GIC architecture permits, bit 7 must be 0
186 - Depending on the number of dispatchers to support, the platform must choose
208 .. __: `ehf-apis`_
236 The :ref:`Firmware Design guide<configuring-secure-interrupts>` explains methods
246 -------------------
248 Dispatchers register handlers for their priority levels through the following
257 - The priority level for which the handler is being registered;
259 - The handler to be registered. The handler must be aligned to 4 bytes.
266 - There exists a descriptor with the priority level requested.
268 - There are no handlers already registered by a previous call to the API.
270 Otherwise, the API returns ``-1``.
279 The parameters are as obtained from the top-level :ref:`EL3 interrupt handler
280 <el3-runtime-firmware>`.
288 --------------------------
306 * .-.-.-.----------.
308 * '-'-'-'----------'
359 See also the `Build-time flow`_ and the `Run-time flow`_.
364 --------------------------------------
368 acknowledged; for non-interrupt exceptions, such as SErrors or :ref:`SDEI
369 explicit dispatches <explicit-dispatch-of-events>`, this has to be done via
370 calling ``ehf_activate_priority()``. See `Run-time flow`_.
381 .. __: `delegation-use-cases`_
385 - The dispatcher has addressed the cause of the exception, and decided to take
388 through an ``ERET``, resumes execution before the interrupt occurred.
390 - The dispatcher has to delegate the execution to lower ELs, and the cause of
398 #. Through the ensuing ``ERET`` from runtime firmware, execution is delegated
411 .. _ehf-apis:
413 - ``ehf_activate_priority()`` activates the supplied priority level, but only
421 - ``ehf_deactivate_priority()`` deactivates a given priority, but only if the
429 `Run-time flow`_.
434 -----------------------------
440 - For activation, the |EHF| only allows for the priority to increase (i.e.
443 - For deactivation, the |EHF| only allows for the priority to decrease (i.e.
452 -------------------
454 In general, Secure execution is regarded as more important than Non-secure
458 call ``ehf_activate_priority()``. As a result, Non-secure interrupts cannot
461 SMCs from Non-secure world are synchronous exceptions, and are mechanisms for
462 Non-secure world to request Secure services. They're broadly classified as
467 - *Fast* SMCs are atomic from the caller's point of view. I.e., they return
469 Any Non-secure interrupts that become pending meanwhile cannot preempt Secure
472 - *Yielding* SMCs carry the semantics of a preemptible, lower-priority request.
473 A pending Non-secure interrupt can preempt Secure execution handling a
480 #. A Non-secure interrupt preempts Secure execution. Non-secure interrupt is
481 handled, and Non-secure execution resumes after ``SMC`` instruction.
484 to the Non-secure caller to distinguish the latter case. This return code,
488 For the latter case above, dispatchers before |EHF| expect Non-secure interrupts
489 to be taken to S-EL1 [#irq]_, so would get a chance to populate the designated
490 preempted error code before yielding to Non-secure world.
495 When |EHF| is enabled, in order to allow Non-secure interrupts to preempt
497 API. The API takes one argument, the error code to be returned to the Non-secure
500 .. [#irq] In case of GICv2, Non-secure interrupts while in S-EL1 were signalled
503 Build-time flow
504 ---------------
508 .. __: `ehf-figure`_
510 The build-time flow involves the following steps:
523 Run-time flow
524 -------------
526 .. _interrupt-flow:
530 #. The GIC driver, during initialization, iterates through the platform-supplied
535 #. The |EHF|, during its initialisation, registers a top-level interrupt handler
536 with the :ref:`Interrupt Management Framework<el3-runtime-firmware>` for EL3
542 #. The top-level EL3 interrupt handler executes. The handler acknowledges the
556 .. _non-interrupt-flow:
577 ---------------------------------------
581 dispatchers through |EHF|.
584 dispatchers fall in distinct priority levels. Because they're routed via the
601 -----------
605 - Although there could be up to 128 Secure dispatchers supported by the GIC
611 - The platform must ensure that the priority assigned to the dispatcher in the
615 --------------
617 *Copyright (c) 2018-2020, Arm Limited and Contributors. All rights reserved.*