Lines Matching refs:interrupt
11 allows EL3 software to configure the interrupt routing behavior. Its main
17 the interrupt to either software in EL3 or Secure-EL1 depending upon the
38 The framework categorises an interrupt to be one of the following depending upon
41 #. Secure EL1 interrupt. This type of interrupt can be routed to EL3 or
45 #. Non-secure interrupt. This type of interrupt can be routed to EL3,
50 #. EL3 interrupt. This type of interrupt can be routed to EL3 or Secure-EL1
54 The following constants define the various interrupt types in the framework
66 A type of interrupt can be either generated as an FIQ or an IRQ. The target
67 exception level of an interrupt type is configured through the FIQ and IRQ bits
75 A routing model for a type of interrupt (generated as FIQ or IRQ) is defined as
77 single bit for each security state. A value of ``0`` means that the interrupt
78 should be routed to the FEL. A value of ``1`` means that the interrupt should be
81 The default routing model for an interrupt type is to route it to the FEL in
87 The framework considers certain routing models for each type of interrupt to be
91 for GIC version 3.0 (ARM GICv3) and only the Secure-EL1 and Non-secure interrupt
109 handover the interrupt to Secure-EL1 for handling.
112 non-secure state. This is an invalid routing model as a secure interrupt
118 can handover the interrupt to Secure-EL1 for handling.
125 interrupts, perform its book-keeping and hand the interrupt to the
133 interrupt to non-secure software. This model requires additional
138 non-secure state. This is an valid routing model as a non-secure interrupt
143 reason to route the interrupt to EL3 software and then hand it back to
152 by EL3 interrupt and can handover the interrupt to EL3 for handling.
156 in EL3 can handle the interrupt.
159 non-secure state. This is an invalid routing model as a secure interrupt
165 can handle the interrupt.
167 Mapping of interrupt type to signal
170 The framework is meant to work with any interrupt controller implemented by a
171 platform. A interrupt controller could generate a type of interrupt as either an
176 interrupt. The platform provides this information through the
179 interrupt controller, Secure-EL1 interrupts are signaled through the FIQ signal
183 Effect of mapping of several interrupt types to one signal
186 It should be noted that if more than one interrupt type maps to a single
187 interrupt signal, and if any one of the interrupt type sets **TEL3=1** for a
188 particular security state, then interrupt signal will be routed to EL3 when in
189 that security state. This means that all the other interrupt types using the
190 same interrupt signal will be forced to the same routing model. This should be
191 borne in mind when choosing the routing model for an interrupt type.
194 Secure-EL0, both the EL3 and the non secure interrupt types map to the FIQ
195 signal. So if either one of the interrupt type sets the routing model so
198 effectively routing the other interrupt type also to EL3.
206 and Secure-EL1 interrupt), only interrupt controller architectures
216 :name: interrupt-management
218 The following sections describe how interrupts are managed by the interrupt
222 of the routing model for a type of interrupt.
224 #. Implementing support to hand control of an interrupt type to its registered
225 handler when the interrupt is generated.
227 Both aspects of interrupt management involve various components in the secure
230 of interrupt in the following data structure.
240 The ``flags`` field stores the routing model for the interrupt type in
243 state. As mentioned in Section 1.2.2, a value of ``0`` implies that the interrupt
253 The framework also depends upon the platform port to configure the interrupt
256 associated interrupt numbers. It should configure the interrupt controller to
270 Roles and responsibilities for interrupt management are sub-divided between the
283 interrupt management as well. This results in a significant dependency on
303 during the registration of a handler for an interrupt type.
308 This component declares the following prototype for a handler of an interrupt type.
318 the interrupt id of the highest pending interrupt only if there is a foolproof
324 exception level when the interrupt was generated. A value of ``1`` means
327 interrupt was generated and routed as per the routing model specified
341 A portable interrupt handler implementation must set the target context both in
348 particular type of interrupt. A Secure Payload Dispatcher service should use
351 the type of interrupt.
359 The ``type`` parameter can be one of the three interrupt types listed above i.e.
364 ``-EALREADY`` in case a handler for the interrupt type has already been
393 receiving an interrupt.
398 A SPD service is responsible for determining and maintaining the interrupt
402 runtime. It must use this information to register a handler for each interrupt
411 after receiving an interrupt from the EL3 runtime firmware. This information
443 this address when it receives a Secure-EL1 interrupt.
487 A Secure Payload must implement an interrupt handling framework at Secure-EL1
488 (Secure-EL1 IHF) to support its chosen interrupt routing model. Secure payload
491 #. In the code where IRQ, FIQ or both interrupts are enabled, if an interrupt
497 #. In the code where both interrupts are disabled, if an interrupt type is
505 The interrupt handling framework implemented by the SP should support one or
506 both these interrupt handling models depending upon the chosen routing model.
510 the interrupt routing model is not known to the SPD service at compile time,
526 synchronous interrupt handling model. The SP could implement this scenario
535 non-secure state. They should be handled through the synchronous interrupt
542 Secure-EL1 IHF should then handle all Secure-EL1 interrupt through the
543 synchronous interrupt handling model described in 1. above.
551 non-secure state where the interrupt should be handled e.g the SP could
554 non-secure interrupt. If this function identifier is not known to the SPD
558 If ``PSTATE.I=1`` then the non-secure interrupt will pend until execution
563 have not effect. The SPD service should register a non-secure interrupt
565 the non-secure state where the interrupt will be handled. The Secure-EL1
573 configured at the interrupt controller by the platform port of the EL3 runtime
595 to raise a periodic interrupt (every half a second) for the purpose of testing
596 interrupt management across all the software components listed in 2.1
602 Section 2.1) in handling an interrupt of a particular type.
618 When an interrupt is generated, the vector for each interrupt type is
632 #. Determining the type of interrupt. Secure-EL1 interrupts will be signaled
635 type of the pending interrupt.
643 #. Determining the handler for the type of interrupt that has been generated.
650 It returns the reference to the registered handler for this interrupt
653 registered for this type of interrupt. This scenario is reported as an
656 #. Calling the registered handler function for the interrupt type generated.
676 The SPD service begins handling an interrupt when the EL3 runtime firmware calls
677 the handler function for that type of interrupt. The SPD service is responsible
680 #. Validating the interrupt. This involves ensuring that the interrupt was
681 generating according to the interrupt routing model specified by the SPD
684 the interrupt was taken from to determine this. If the interrupt is not
689 interrupts. A non-secure interrupt should never be routed to EL3 from
692 S-EL1 interrupt should never be routed to EL3 from secure state. The handler
696 routing model and interrupt type. For non secure and S-EL1 interrupt,
697 if the security state of the execution context where the interrupt was
699 the interrupt, a context switch is required. The following 2 cases
702 #. A Secure-EL1 interrupt taken from the non-secure state should be
705 #. A non-secure interrupt taken from the secure state should be routed
715 per the synchronous interrupt handling model it implements. A Secure-EL1
716 interrupt can be routed to EL3 while execution is in the SP. This implies
717 that SP execution can be preempted while handling an interrupt by a
718 another higher priority Secure-EL1 interrupt or a EL3 interrupt. The SPD
719 service should be able to handle this preemption or manage secure interrupt
723 the interrupt has been successfully validated and ready to be handled at a
726 The routing model allows non-secure interrupts to interrupt Secure-EL1 when in
731 so that the interrupt can be handled.
736 When the Secure Payload has finished handling a Secure-EL1 interrupt, it could
739 exception level and the security state from where the Secure-EL1 interrupt was
742 Test secure payload dispatcher Secure-EL1 interrupt handling
753 that the secure interrupt originated from the non-secure state. It asserts
762 secure interrupt during ``yielding`` SMC processing, save the registers that
764 to re-enter TSP for Secure-EL1 interrupt processing. It does not need to
774 #. It returns the per-cpu ``cpu_context`` to indicate that the interrupt can
779 The figure below describes how the interrupt handling is implemented by the TSPD
780 when a Secure-EL1 interrupt is generated when execution is in the non-secure
786 signal completion of interrupt handling.
796 by a non secure interrupt earlier.
807 Test secure payload dispatcher non-secure interrupt handling
810 The TSP in Secure-EL1 can be preempted by a non-secure interrupt during
811 ``yielding`` SMC processing or by a higher priority EL3 interrupt during
812 Secure-EL1 interrupt processing. Currently only non-secure interrupts can
817 the TSP either for Secure-EL1 interrupt handling or for resuming the preempted
821 The non-secure interrupt triggered in Secure-EL1 during ``yielding`` SMC processing
824 the TSPD will set the routing model for the non-secure interrupt to be routed to
826 ``tspd_ns_interrupt_handler()`` as the non-secure interrupt handler. The
827 ``tspd_ns_interrupt_handler()`` on being invoked ensures that the interrupt
830 interrupt) when TSP is reentered for handling Secure-EL1 interrupts that
836 routing model for non-secure interrupt in secure state is in effect
838 exceptions are unmasked i.e. ``PSTATE.I=0``, and a non-secure interrupt will
883 The figure below describes how the TSP/TSPD handle a non-secure interrupt when
893 interrupt handling models depending upon the interrupt routing model it has
896 In the synchronous model, it should begin handling a Secure-EL1 interrupt after
898 time or during the registration phase. Before handling the interrupt, the SP
901 interrupt, the SP could return control back to the exception level and security
902 state where the interrupt was originally taken from. The SP should use an SMC32
908 when a non-secure interrupt is generated, the SP should coordinate with the SPD
910 level. This will allow the non-secure interrupt to be handled in the non-secure
916 The TSPD hands control of a Secure-EL1 interrupt to the TSP at the
917 ``tsp_sel1_intr_entry()``. The TSP handles the interrupt while ensuring that the
922 #. Checks whether the interrupt is the secure physical timer interrupt. It
924 interrupt number. If it is not the secure physical timer interrupt, then
925 that means that a higher priority interrupt has preempted it. Invoke
929 #. Handles the secure timer interrupt interrupt by acknowledging it using the
933 end of interrupt processing.
957 interrupt and the execution can return to the non-secure world for handling
958 the interrupt (For details on ``yielding`` SMC refer `SMC calling convention`_).
977 /* The pending non-secure interrupt is handled by the interrupt handler
985 interrupt causes an IRQ exception and the IRQ handler registered at the
986 exception vector handles the non-secure interrupt and returns. The return value