Lines Matching refs:interrupt
5 allows EL3 software to configure the interrupt routing behavior. Its main
11 the interrupt to either software in EL3 or Secure-EL1 depending upon the
32 The framework categorises an interrupt to be one of the following depending upon
35 #. Secure EL1 interrupt. This type of interrupt can be routed to EL3 or
39 #. Non-secure interrupt. This type of interrupt can be routed to EL3,
44 #. EL3 interrupt. This type of interrupt can be routed to EL3 or Secure-EL1
48 The following constants define the various interrupt types in the framework
60 A type of interrupt can be either generated as an FIQ or an IRQ. The target
61 exception level of an interrupt type is configured through the FIQ and IRQ bits
69 A routing model for a type of interrupt (generated as FIQ or IRQ) is defined as
71 single bit for each security state. A value of ``0`` means that the interrupt
72 should be routed to the FEL. A value of ``1`` means that the interrupt should be
75 The default routing model for an interrupt type is to route it to the FEL in
81 The framework considers certain routing models for each type of interrupt to be
85 for GIC version 3.0 (Arm GICv3) and only the Secure-EL1 and Non-secure interrupt
104 handover the interrupt to Secure-EL1 for handling.
107 non-secure state. This is an invalid routing model as a secure interrupt
113 can handover the interrupt to Secure-EL1 for handling.
120 interrupts, perform its book-keeping and hand the interrupt to the
128 interrupt to non-secure software. This model requires additional
133 non-secure state. This is a valid routing model as a non-secure interrupt
138 reason to route the interrupt to EL3 software and then hand it back to
149 by EL3 interrupt and can handover the interrupt to EL3 for handling.
154 handling<interrupt-handling>` documentation.
158 in EL3 can handle the interrupt.
161 non-secure state. This is an invalid routing model as a secure interrupt
167 can handle the interrupt.
169 Mapping of interrupt type to signal
172 The framework is meant to work with any interrupt controller implemented by a
173 platform. A interrupt controller could generate a type of interrupt as either an
178 interrupt. The platform provides this information through the
181 Arm GICv2 interrupt controller, Secure-EL1 interrupts are signaled through the
185 Effect of mapping of several interrupt types to one signal
188 It should be noted that if more than one interrupt type maps to a single
189 interrupt signal, and if any one of the interrupt type sets **TEL3=1** for a
190 particular security state, then interrupt signal will be routed to EL3 when in
191 that security state. This means that all the other interrupt types using the
192 same interrupt signal will be forced to the same routing model. This should be
193 borne in mind when choosing the routing model for an interrupt type.
196 Secure-EL0, both the EL3 and the non secure interrupt types map to the FIQ
197 signal. So if either one of the interrupt type sets the routing model so
200 effectively routing the other interrupt type also to EL3.
208 and Secure-EL1 interrupt), only interrupt controller architectures
218 managed by the interrupt handling framework. This entails:
221 specification of the routing model for a type of interrupt.
223 #. Implementing support to hand control of an interrupt type to its
224 registered handler when the interrupt is generated.
226 Both aspects of interrupt management involve various components in the secure
229 associated with each type of interrupt in the following data structure.
239 The ``flags`` field stores the routing model for the interrupt type in
243 the interrupt should be targeted to the FEL. A value of ``1`` implies that it
252 The framework also depends upon the platform port to configure the interrupt
255 associated interrupt numbers. It should configure the interrupt controller to
269 Roles and responsibilities for interrupt management are sub-divided between the
281 interrupt management as well. This results in a significant dependency on
301 `Software components`_) during the registration of a handler for an interrupt
309 This component declares the following prototype for a handler of an interrupt type.
319 the interrupt id of the highest pending interrupt only if there is a foolproof
325 exception level when the interrupt was generated. A value of ``1`` means
328 interrupt was generated and routed as per the routing model specified
342 A portable interrupt handler implementation must set the target context both in
349 particular type of interrupt. A Secure Payload Dispatcher service should use
352 the type of interrupt.
360 The ``type`` parameter can be one of the three interrupt types listed above i.e.
365 ``-EALREADY`` in case a handler for the interrupt type has already been
394 receiving an interrupt.
401 A SPD service is responsible for determining and maintaining the interrupt
405 runtime. It must use this information to register a handler for each interrupt
414 after receiving an interrupt from the EL3 runtime firmware. This information
450 this address when it receives a Secure-EL1 interrupt.
496 A Secure Payload must implement an interrupt handling framework at Secure-EL1
497 (Secure-EL1 IHF) to support its chosen interrupt routing model. Secure payload
500 #. In the code where IRQ, FIQ or both interrupts are enabled, if an interrupt
506 #. In the code where both interrupts are disabled, if an interrupt type is
514 The interrupt handling framework implemented by the SP should support one or
515 both these interrupt handling models depending upon the chosen routing model.
519 IHF. If the choice of the interrupt routing model is not known to the SPD
535 synchronous interrupt handling model. The SP could implement this scenario
544 non-secure state. They should be handled through the synchronous interrupt
551 Secure-EL1 IHF should then handle all Secure-EL1 interrupt through the
552 synchronous interrupt handling model described in 1. above.
560 non-secure state where the interrupt should be handled e.g the SP could
563 non-secure interrupt. If this function identifier is not known to the SPD
567 If ``PSTATE.I=1`` then the non-secure interrupt will pend until execution
572 have not effect. The SPD service should register a non-secure interrupt
574 the non-secure state where the interrupt will be handled. The Secure-EL1
582 configured at the interrupt controller by the platform port of the EL3 runtime
607 to raise a periodic interrupt (every half a second) for the purpose of testing
608 interrupt management across all the software components listed in `Software
615 Section `Software components`_) in handling an interrupt of a particular type.
631 When an interrupt is generated, the vector for each interrupt type is
645 #. Determining the type of interrupt. Secure-EL1 interrupts will be signaled
648 type of the pending interrupt.
656 #. Determining the handler for the type of interrupt that has been generated.
663 It returns the reference to the registered handler for this interrupt
666 registered for this type of interrupt. This scenario is reported as an
669 #. Calling the registered handler function for the interrupt type generated.
689 The SPD service begins handling an interrupt when the EL3 runtime firmware calls
690 the handler function for that type of interrupt. The SPD service is responsible
693 #. Validating the interrupt. This involves ensuring that the interrupt was
694 generated according to the interrupt routing model specified by the SPD
697 the interrupt was taken from to determine this. If the interrupt is not
702 interrupts. A non-secure interrupt should never be routed to EL3 from
705 S-EL1 interrupt should never be routed to EL3 from secure state. The handler
709 routing model and interrupt type. For non secure and S-EL1 interrupt,
710 if the security state of the execution context where the interrupt was
712 the interrupt, a context switch is required. The following 2 cases
715 #. A Secure-EL1 interrupt taken from the non-secure state should be
718 #. A non-secure interrupt taken from the secure state should be routed
728 per the synchronous interrupt handling model it implements. A Secure-EL1
729 interrupt can be routed to EL3 while execution is in the SP. This implies
730 that SP execution can be preempted while handling an interrupt by a
731 another higher priority Secure-EL1 interrupt or a EL3 interrupt. The SPD
732 service should be able to handle this preemption or manage secure interrupt
736 the interrupt has been successfully validated and ready to be handled at a
739 The routing model allows non-secure interrupts to interrupt Secure-EL1 when in
744 so that the interrupt can be handled.
749 When the Secure Payload has finished handling a Secure-EL1 interrupt, it could
752 exception level and the security state from where the Secure-EL1 interrupt was
755 Test secure payload dispatcher Secure-EL1 interrupt handling
766 that the secure interrupt originated from the non-secure state. It asserts
775 secure interrupt during ``yielding`` SMC processing, save the registers that
777 to re-enter TSP for Secure-EL1 interrupt processing. It does not need to
787 #. It returns the per-cpu ``cpu_context`` to indicate that the interrupt can
792 The figure below describes how the interrupt handling is implemented by the TSPD
793 when a Secure-EL1 interrupt is generated when execution is in the non-secure
799 signal completion of interrupt handling.
809 by a non secure interrupt earlier.
820 Test secure payload dispatcher non-secure interrupt handling
823 The TSP in Secure-EL1 can be preempted by a non-secure interrupt during
824 ``yielding`` SMC processing or by a higher priority EL3 interrupt during
825 Secure-EL1 interrupt processing. When ``EL3_EXCEPTION_HANDLING`` is ``0``, only
828 interrupt may preempt Secure execution.
831 the TSP either for Secure-EL1 interrupt handling or for resuming the preempted
835 The non-secure interrupt triggered in Secure-EL1 during ``yielding`` SMC
839 routing model for the non-secure interrupt to be routed to EL3 from secure state
841 non-secure interrupt handler. The ``tspd_ns_interrupt_handler()`` on being
842 invoked ensures that the interrupt originated from the secure state and disables
844 further preemption (by a non-secure interrupt) when TSP is reentered for
850 routing model for non-secure interrupt in secure state is in effect
852 exceptions are unmasked i.e. ``PSTATE.I=0``, and a non-secure interrupt will
898 The figure below describes how the TSP/TSPD handle a non-secure interrupt when
906 Secure payload interrupt handling
910 interrupt handling models depending upon the interrupt routing model it has
913 In the synchronous model, it should begin handling a Secure-EL1 interrupt after
915 time or during the registration phase. Before handling the interrupt, the SP
918 the interrupt, the SP could return control back to the exception level and
919 security state where the interrupt was originally taken from. The SP should use
925 when a non-secure interrupt is generated, the SP should coordinate with the SPD
927 level. This will allow the non-secure interrupt to be handled in the non-secure
933 The TSPD hands control of a Secure-EL1 interrupt to the TSP at the
934 ``tsp_sel1_intr_entry()``. The TSP handles the interrupt while ensuring that the
940 #. Checks whether the interrupt is the secure physical timer interrupt. It
942 interrupt number. If it is not the secure physical timer interrupt, then
943 that means that a higher priority interrupt has preempted it. Invoke
947 #. Handles the secure timer interrupt interrupt by acknowledging it using the
951 end of interrupt processing.
967 dispatcher non-secure interrupt handling`_).
976 interrupt and the execution can return to the non-secure world for handling
977 the interrupt (For details on ``yielding`` SMC refer `SMC calling convention`_).
996 /* The pending non-secure interrupt is handled by the interrupt handler
1004 interrupt causes an IRQ exception and the IRQ handler registered at the
1005 exception vector handles the non-secure interrupt and returns. The return value