Lines Matching refs:to
17 The |EHF| is selected by setting the build option ``EL3_EXCEPTION_HANDLING`` to
24 allows for asynchronous exceptions to be routed to EL3. As described in the
27 ``SCR_EL3`` register to effect this routing. For most use cases, other than for
29 FIQs and IRQs routed to EL3 are not required to be handled in EL3.
35 introduced to the Arm architecture. With RAS features implemented, various
36 components of the system may use one of the asynchronous exceptions to signal
37 error conditions to PEs. These error conditions are of critical nature, and
40 followed in response to RAS events in the system.
43 interacts with the Runtime Firmware in order to request notification of
47 first received by the EL3 firmware, and then dispatched to Normal world
51 suitably routed to EL3, and the Runtime Firmware (BL31) is extended to include
53 EL3. These components—referred to as *dispatchers* [#spd]_ in general—may
54 choose to:
62 rest of the handling to a dedicated software stack running at lower Secure
66 processing of the error to dedicated software stack running at lower secure
67 ELs (as above); additionally, the Normal world may also be required to
76 .. [#spd] Not to be confused with :ref:`Secure Payload Dispatcher
83 Corollary to the use cases cited above, the primary role of the |EHF| is to
85 enables multiple exception dispatchers in runtime firmware to co-exist, register
89 In order to arbitrate exception handling among dispatchers, the |EHF| operation
90 is based on a priority scheme. This priority scheme is closely tied to how the
91 Arm GIC architecture defines it, although it's applied to non-interrupt
94 The platform is required to `partition`__ the Secure priority space into
96 dispatchers to one or more priority levels. The dispatchers then register
108 executing in EL3, or has delegated the execution to a lower EL. For interrupts,
110 priority of the acknowledged interrupt is used to match its registered handler.
115 In order for the priority arbitration to work, the |EHF| provides APIs in order
116 for these non-interrupt exceptions to assume a priority, and to interwork with
123 interrupt to preempt a higher priority one. By extension, this means that a
125 activation and deactivation for non-interrupt exceptions, however, has to be
126 explicit. The |EHF| therefore disallows for lower priority level to be activated
128 Likewise, a panic would result if it's attempted to deactivate a lower priority
132 stack—priority levels stack up in strictly increasing fashion, and need to be
148 sufficient priority are signalled as FIQs, and therefore will be routed to
149 EL3. As a result, S-EL1 software cannot expect to handle Non-secure
153 In order for S-EL1 software to handle Non-secure interrupts while having
156 handled over to S-EL1.
159 set to ``1`` so that *Group 0* interrupts target EL3.
161 - While executing in Secure world, |EHF| sets GIC Priority Mask Register to the
165 As mentioned above, with |EHF|, the platform is required to partition *Group 0*
166 interrupts into distinct priority levels. A dispatcher that chooses to receive
168 handlers for them. A given priority level can be assigned to only one handler. A
178 Interrupts are associated to dispatchers by way of grouping and assigning
179 interrupts to a priority level. In other words, all interrupts that are to
186 - Depending on the number of dispatchers to support, the platform must choose
187 to use the top *n* of the 7 remaining bits to identify and assign interrupts
188 to individual dispatchers. Choosing *n* bits supports up to 2\ :sup:`n`
201 The priority thus assigned to an interrupt is also used to determine the
219 The size of the array might therefore be larger than what it appears to be.
220 The ``ARRAY_SIZE()`` macro therefore should be used to determine the size of
223 Finally, this array of descriptors is exposed to |EHF| via the
226 Refer to the `Interrupt handling example`_ for usage. See also: `Interrupt
237 for configuring secure interrupts. |EHF| requires the platform to enumerate
238 interrupt properties (as opposed to just numbers) of Secure interrupts. The
242 See `Limitations`_, and also refer to `Interrupt handling example`_ for
259 - The handler to be registered. The handler must be aligned to 4 bytes.
261 If a dispatcher owns more than one priority levels, it has to call the API for
268 - There are no handlers already registered by a previous call to the API.
283 example, expects the platform to allocate two different priority levels—
285 same handler to handle both levels.
290 The following annotated snippet demonstrates how a platform might choose to
291 assign interrupts to fictitious dispatchers:
325 /* Expose priority descriptors to Exception Handling Framework */
366 A priority level is said to be *active* when an exception of that priority is
369 explicit dispatches <explicit-dispatch-of-events>`, this has to be done via
373 of the exception, the corresponding priority level ought to be deactivated. As
375 for other exceptions, this has to be done via calling
378 Thanks to `different provisions`__ for exception delegation, there are
385 - The dispatcher has addressed the cause of the exception, and decided to take
387 priority level before returning to the |EHF|. Runtime firmware, upon exit
390 - The dispatcher has to delegate the execution to lower ELs, and the cause of
395 #. The dispatcher calls ``setjmp()`` to setup a jump point, and arranges to
399 to a lower EL.
406 does ``longjmp()`` to resume beyond the previous jump point.
415 panics. Also, to prevent interruption by physical interrupts of lower
416 priority, the |EHF| programs the *Priority Mask Register* corresponding to
417 the PE to the priority being activated. Dispatchers typically only need to
418 call this when handling exceptions other than interrupts, and it needs to
419 delegate execution to a lower EL at a desired priority level.
422 current active priority is equal to the given one; otherwise panics. |EHF|
423 also restores the *Priority Mask Register* corresponding to the PE to the
424 priority before the call to ``ehf_activate_priority()``. Dispatchers
425 typically only need to call this after handling exceptions other than
428 The calling of APIs are subject to allowed `transitions`__. See also the
437 be called to transition the current priority level on a PE. A given sequence of
438 calls to these APIs are subject to the following conditions:
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.
445 required to be the current priority.
462 Non-secure world to request Secure services. They're broadly classified as
468 to the caller only when the Secure world has finished serving the request.
484 to the Non-secure caller to distinguish the latter case. This return code,
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
506 Please refer to the `figure`__ above.
515 #. Platform provides interrupt properties to GIC driver, as described in
518 #. Dispatcher calling ``ehf_register_priority_handler()`` to register an
521 Also refer to the `Interrupt handling example`_.
533 interrupts belonging to different dispatchers.
539 #. When an interrupt belonging to a dispatcher fires, GIC raises an EL3/Group 0
540 interrupt, and is taken to EL3.
546 #. The |EHF| programs the *Priority Mask Register* of the PE to the priority of
549 #. The |EHF| marks that priority level *active*, and jumps to the dispatcher
552 #. Once the dispatcher handler finishes its job, it has to immediately
553 *deactivate* the priority level before returning to the |EHF|. See
565 #. The handler calls ``ehf_activate_priority()`` to activate the required
568 handler may choose to do the handling entirely in EL3 or delegate to a lower
572 ``ehf_deactivate_priority()`` to deactivate the priority level activated
573 earlier. This also has the effect of lowering GIC priority mask to what it
585 GIC, interrupt delivery to the PE is subject to GIC prioritisation rules. In
587 in *Active* state), only interrupts of higher priority are signalled to the PE,
593 should carefully consider the assignment of priorities to dispatchers integrated
594 into runtime firmware. The platform should sensibly delineate priority to
595 various dispatchers according to their nature. In particular, dispatchers of
605 - Although there could be up to 128 Secure dispatchers supported by the GIC
607 ``EHF_REGISTER_PRIORITIES()`` macro is currently limited to 32. This serves most
611 - The platform must ensure that the priority assigned to the dispatcher in the