Lines Matching full:priority
90 is based on a priority scheme. This priority scheme is closely tied to how the
94 The platform is required to `partition`__ the Secure priority space into
95 priority levels as applicable for the Secure software stack. It then assigns the
96 dispatchers to one or more priority levels. The dispatchers then register
97 handlers for the priority levels at runtime. A dispatcher can register handlers
98 for more than one priority level.
100 .. __: `Partitioning priority levels`_
107 A priority level is *active* when a handler at that priority level is currently
110 priority of the acknowledged interrupt is used to match its registered handler.
111 The priority level is likewise implicitly deactivated when the interrupt
114 Non-interrupt exceptions (SErrors, for example) don't have a notion of priority.
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
118 activate and deactivate the respective priority level as and when they're
121 Because priority activation and deactivation for interrupt handling is implicit
122 and involves GIC priority masking, it's impossible for a lower priority
123 interrupt to preempt a higher priority one. By extension, this means that a
124 lower priority dispatcher cannot preempt a higher-priority one. Priority
126 explicit. The |EHF| therefore disallows for lower priority level to be activated
127 whilst a higher priority level is active, and would result in a panic.
128 Likewise, a panic would result if it's attempted to deactivate a lower priority
129 level when a higher priority level is active.
131 In essence, priority level activation and deactivation conceptually works like a
132 stack—priority levels stack up in strictly increasing fashion, and need to be
135 `Transition of priority levels`_.
148 sufficient priority are signalled as FIQs, and therefore will be routed to
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
166 interrupts into distinct priority levels. A dispatcher that chooses to receive
167 interrupts can then *own* one or more priority levels, and register interrupt
168 handlers for them. A given priority level can be assigned to only one handler. A
169 dispatcher may register more than one priority level.
171 Dispatchers are assigned interrupt priority levels in two steps:
173 .. _Partitioning priority levels:
175 Partitioning priority levels
179 interrupts to a priority level. In other words, all interrupts that are to
180 target a particular dispatcher should fall in a particular priority level. For
181 priority assignment:
183 - Of the 8 bits of priority that Arm GIC architecture permits, bit 7 must be 0
190 6 and 5), the platform can partition into 4 secure priority ranges: ``0x0``,
196 security states must implement at least 32 priority levels; i.e., at least 5
198 choosing *n* bits for priority range assignment, the platform must ensure
199 that at least ``n+1`` top bits of GIC priority are writeable.
201 The priority thus assigned to an interrupt is also used to determine the
202 priority of delegated execution in lower ELs. Delegated execution in lower EL is
203 associated with a priority level chosen with ``ehf_activate_priority()`` API
204 (described `later`__). The chosen priority level also determines the interrupts
210 The platform expresses the chosen priority levels by declaring an array of
211 priority level descriptors. Each entry in the array is of type
212 ``ehf_pri_desc_t``, and declares a priority level, and shall be populated by the
229 Programming priority
232 The text in `Partitioning priority levels`_ only describes how the platform
233 expresses the required levels of priority. It however doesn't choose interrupts
234 nor program the required priority in GIC.
239 priority of secure interrupts must match that as determined in the
240 `Partitioning priority levels`_ section above.
248 Dispatchers register handlers for their priority levels through the following
257 - The priority level for which the handler is being registered;
261 If a dispatcher owns more than one priority levels, it has to call the API for
266 - There exists a descriptor with the priority level requested.
283 example, expects the platform to allocate two different priority levels—
318 /* Install priority level descriptors for each dispatcher */
325 /* Expose priority descriptors to Exception Handling Framework */
333 /* Dispatcher 1 owns interrupts d1_0 and d1_1, so assigns priority DISP1_PRIO */
337 /* Dispatcher 2 owns interrupts d2_0 and d2_1, so assigns priority DISP2_PRIO */
341 /* Dispatcher 3 owns interrupts d3_0 and d3_1, so assigns priority DISP3_PRIO */
366 A priority level is said to be *active* when an exception of that priority is
373 of the exception, the corresponding priority level ought to be deactivated. As
387 priority level before returning to the |EHF|. Runtime firmware, upon exit
413 - ``ehf_activate_priority()`` activates the supplied priority level, but only
414 if the current active priority is higher than the given one; otherwise
416 priority, the |EHF| programs the *Priority Mask Register* corresponding to
417 the PE to the priority being activated. Dispatchers typically only need to
419 delegate execution to a lower EL at a desired priority level.
421 - ``ehf_deactivate_priority()`` deactivates a given priority, but only if the
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
431 .. __: `Transition of priority levels`_
433 Transition of priority levels
437 be called to transition the current priority level on a PE. A given sequence of
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.
444 numeric value increases). Additionally, the priority being deactivated is
445 required to be the current priority.
456 delegated execution thereafter, has the effect of raising GIC's priority
472 - *Yielding* SMCs carry the semantics of a preemptible, lower-priority request.
512 #. Platform assigns priorities by installing priority level descriptors for
513 individual dispatchers, as described in `Partitioning priority levels`_.
516 `Programming priority`_.
531 interrupt properties (see `Programming priority`_), and configures the
532 interrupts. This programs the appropriate priority and group (Group 0) on
543 interrupt, reads its *Running Priority*, and from that, determines the
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
553 *deactivate* the priority level before returning to the |EHF|. See
566 priority level. This also has the effect of raising GIC priority mask, thus
567 preventing interrupts of lower priority from preempting the handling. The
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
579 The GIC priority scheme, by design, prioritises Secure interrupts over Normal
583 As mentioned in `Partitioning priority levels`_, interrupts targeting distinct
584 dispatchers fall in distinct priority levels. Because they're routed via the
587 in *Active* state), only interrupts of higher priority are signalled to the PE,
588 even if interrupts of same or lower priority are pending. This has the side
590 dispatcher handling its (higher priority) interrupts.
594 into runtime firmware. The platform should sensibly delineate priority to
596 critical nature (RAS, for example) should be assigned higher priority than
597 others (|SDEI|, for example); and within |SDEI|, Critical priority
598 |SDEI| should be assigned higher priority than Normal ones.
606 priority scheme, the size of descriptor array exposed with
611 - The platform must ensure that the priority assigned to the dispatcher in the
612 exception descriptor and the programmed priority of interrupts handled by the