Exception Notification

Abstract

The apparatus includes an interrupt detection circuit for detecting a first interrupt to be handled by a processing circuit in a target execution environment. The apparatus also includes an exception notification circuit for notifying the processing circuit of an exception in response to the accepted interrupt. If the first interrupt meets at least one criterion, including if the target execution environment is not the active execution environment of the processing circuit, the exception notification circuit is configured to signal a first or second exception depending on an interrupt priority associated with the first interrupt. If the interrupt priority exceeds a threshold priority, the first exception is signaled to preemptively trigger a given action, where switching from the active execution environment to the target execution environment depends on the given action being performed. If the interrupt priority does not exceed the threshold priority, the second exception is signaled without preemptively triggering the given action.

Description

[Technical Field]

[0001] The present technology relates to the field of exception notification.

[0002] In a data processing system, one or more interrupt sources may send an interrupt indicating that an interrupt event has occurred. An exception may be signaled to a processing circuit to indicate that an interrupt event has occurred, with the signaling triggering processing of the interrupt by the processing circuit. The interrupt may require handling by a processing circuit operating in a target execution environment, and thus handling the interrupt may involve switching from an active execution environment to a target execution environment. Switching between execution environments may be disruptive to processing, but may be important for timely handling of critical interrupts, and therefore, improving control over switching between execution environments in response to an interrupt is desirable.

[0003] At least some embodiments provide an apparatus, the apparatus comprising: an interrupt detection circuit configured to detect a first interrupt handled by a processing circuit operating in the target execution environment; an exception notification circuit configured to notify the processing circuit of an exception in response to the accepted interrupt; In response to determining that the first interrupt satisfies at least one criterion, the at least one criterion including determining that the target execution environment is an execution environment other than an active execution environment of the processing circuit, the exception notification circuit: signaling a first exception to preemptively trigger a given action in response to determining that the interrupt priority associated with the first interrupt exceeds a threshold priority, and switching from the active execution environment to the target execution environment is dependent on the given action being performed; In response to determining that the interrupt priority does not exceed the threshold priority, a second exception is configured to be signaled without preemptively triggering a given action.

[0004] At least some embodiments provide a method, the method comprising: Detecting a first interrupt handled by processing circuitry operating in the target execution environment; and notifying the processing circuit of the exception in response to the accepted interrupt, the method comprising: In response to determining that the first interrupt satisfies the at least one criterion, determining that the target execution environment is an execution environment other than the active execution environment of the processing circuitry; signaling a first exception to preemptively trigger a given action in response to determining that an interrupt priority associated with the first interrupt exceeds a threshold priority, wherein switching from the active execution environment to the target execution environment depends on the given action being performed; In response to determining that the interrupt priority does not exceed the threshold priority, signaling a second exception without preemptively triggering a given action.

[0005] At least some embodiments provide a computer readable medium for storing computer readable code for manufacturing an apparatus, the apparatus comprising: an interrupt detection circuit configured to detect a first interrupt handled by a processing circuit operating in the target execution environment; an exception notification circuit configured to notify the processing circuit of an exception in response to the accepted interrupt; In response to determining that the first interrupt satisfies at least one criterion, the at least one criterion including determining that the target execution environment is an execution environment other than an active execution environment of the processing circuit, the exception notification circuit: signaling a first exception to preemptively trigger a given action in response to determining that the interrupt priority associated with the first interrupt exceeds a threshold priority, and switching from the active execution environment to the target execution environment is dependent on the given action being performed; In response to determining that the interrupt priority does not exceed the threshold priority, a second exception is configured to be signaled without preemptively triggering a given action.

[0006] The computer-readable medium may be a non-transitory storage medium.

[0007] Further aspects, features, and advantages of the present technology will become apparent from the following description of examples, read in conjunction with the accompanying drawings. [Brief explanation of the drawings]

[0008] [Figure 1] 1 illustrates a schematic diagram of an example data processing system. [Figure 2] 1 illustrates an example of a processor including an interrupt detection circuit and an exception notification circuit. [Figure 3] 1 illustrates a first example of security states and exception levels for a processing circuit; [Figure 4] 1 illustrates a second example of security states and exception levels for a processing circuit. [Figure 5] 1 illustrates an example set of registers that may be provided in a processor. [Figure 6A] 10 illustrates an example of the behavior of the processing circuit when the second and first exceptions are signaled, respectively. [Figure 6B] 10 illustrates an example of the behavior of the processing circuit when the second and first exceptions are signaled, respectively. [Figure 7] 1 illustrates a process for notifying a processing circuit of an exception. [Figure 8] 1 illustrates an example of a process that may be performed by software running in EL3. [Figure 9] 10 illustrates an example of processing that may be performed by software in an active execution environment in response to a second exception. DETAILED DESCRIPTION OF THE INVENTION

[0009] As introduced above, in a data processing system, an interrupt may be sent that requires handling by a processing circuit operating in a target execution environment. The processing circuit may operate in several different execution environments, and when the interrupt is received, the processing circuit may be operating in an active execution environment that is different from the target execution environment. Therefore, to handle the interrupt, the processing circuit may need to switch from the active execution environment to the target execution environment. Quickly switching to the target execution environment after receiving an exception means that a critical interrupt can be handled in a timely manner. However, immediately switching to the target execution environment may cause processing in the active execution environment to be interrupted. In some cases, it may be desirable for processing in the active execution environment to continue for a while and for a switch to the target execution environment to occur later. For example, software in the active execution environment may be approaching a processing point where much less state needs to be saved when the interrupt is received, and therefore may be approaching a processing point where it is more desirable to handle the interrupt than the current processing point. Therefore, in some cases, it may be useful to give software in the active execution environment the flexibility to determine when an interrupt is handled.

[0010] An apparatus may be provided that includes an interrupt detection circuit for detecting that an interrupt is pending to be processed by a processing circuit in a target execution environment, and an exception notification circuit for selectively notifying the processing circuit of an exception in response to an accepted interrupt.

[0011] In one example, all interrupts detected by the interrupt detection circuitry that are to be handled in a target execution environment other than the active execution environment may be signaled to the handling circuitry using a given exception.

[0012] In one example, in response to a given exception, the processing circuitry may be configured to switch from the active execution environment to handle the interrupt in the target execution environment regardless of processing in the active execution environment, meaning that all interrupts are handled promptly but with preempting execution in the active execution environment whenever an interrupt is received that needs to be handled in an execution environment other than the active execution environment.

[0013] In one alternative, in response to a given exception, the processing circuitry may be configured to enable software running in the active execution environment to determine when to switch to the target execution environment to handle the interrupt. This may allow the active execution environment to complete processing operations before switching to the target execution environment and may therefore not cause preemption of processing in the active execution environment. However, waiting for the active execution environment to switch to the target execution environment may mean that processing of critical interrupts that need to be handled in an execution environment other than the current execution environment is delayed.

[0014] In one exemplary technique, a processing circuit may be configured with settings to select one of the two options described above, and thus may be configured to select whether to handle an interrupt signaled by a given exception by always preempting execution in the active execution environment or by always allowing software in the active execution environment to schedule handling of the interrupt. This generally provides some control over whether an interrupt is allowed to preempt execution in the active execution environment at a given time. However, in this example, the different ways to handle the interrupt are controlled by software that changes the control settings. Because the timing of interrupt occurrence cannot be controlled by software (interrupts are often caused by external events), this would not be a practical technique for controlling whether a given interrupt can preempt processing in the active execution environment at a given time.

[0015] However, it is recognized that some interrupts to be handled in an execution environment other than the active execution environment are more urgent than other interrupts. Some interrupts may be considered critical because prompt handling is important, while other interrupts may be considered less critical. It may be desirable to preempt processing in the active execution environment to switch to a target execution environment for interrupt handling in response to a critical interrupt, and allow the processing circuitry to decide when to switch to the target execution environment for a less critical interrupt. The all-or-nothing approach described above does not reflect the fact that, at any given time, it may be desirable to preempt processing in the active execution environment in response to some interrupts to be handled in a different execution environment, but not in response to other interrupts to be handled in a different execution environment.

[0016] Interrupts may be associated with interrupt priorities. Interrupt priorities may be used, for example, to determine the order in which pending interrupts to be handled in the same execution environment are handled. Interrupt priorities may also be used to mask certain interrupts with lower priorities so that they are not accepted and therefore notified to the processing circuitry. The inventors have recognized that interrupt priorities can be used as a mechanism to identify which interrupts are critical and which are not critical to be handled in execution environments other than the active execution environment.

[0017] Thus, in some examples, the exception notification circuitry is configured to signal a first exception or a second exception depending on an interrupt priority associated with the first interrupt. In response to determining that the interrupt priority exceeds a threshold priority, the first exception may be signaled to preemptively trigger a given action, and switching from the active execution environment to the target execution environment depends on the given action being performed. In response to determining that the interrupt priority does not exceed the threshold priority, the second exception may be signaled without preemptively triggering a given action. In this manner, some interrupts may result in preemptively triggering a given action, while other interrupts may not result in an action being preemptively triggered without any switching between different control settings. The given action may preempt processing in the active execution environment. Thus, this technique provides greater control over the preemption of processing in an active execution environment in response to an interrupt that should be handled in a target execution environment other than the active execution environment.

[0018] The exception notification circuit may selectively notify the first or second exception in response to determining that the first interrupt satisfies at least one criterion. The at least one criterion may include determining that the target execution environment is an execution environment other than the active execution environment of the processing circuit. For interrupts handled in the active execution environment, there may be no need to switch to another execution environment to handle the interrupt, and therefore, there may be no need to preempt processing. The at least one criterion may include additional criteria. For example, the at least one criterion may include determining that the first interrupt belongs to at least one class of interrupts. The at least one criterion may include determining that the first interrupt should not be handled at an exception level responsible for switching between security states. As described below, the at least one criterion may also include determining that the target execution environment in which the first interrupt should be handled is a preemptive execution environment. Different implementations may have different options for applying additional criteria or multiple criteria in addition to the criterion that the target execution environment is an execution environment other than the active execution environment.

[0019] The determination that the interrupt priority exceeds the threshold is not particularly limited. The interrupt priority and the threshold priority may be represented by numerical values, and the determination may include a comparison of the numerical values. It should be recognized that a higher priority may be represented by either a higher or lower numerical value, and thus, the threshold priority may be exceeded when the interrupt priority assumes a higher or lower numerical value in different examples. When the interrupt priority is equal to the threshold priority, this may be interpreted as exceeding or not exceeding the threshold priority, depending on the implementation.

[0020] In some examples, the execution environment is not particularly limited. The execution environment may include, for example, a virtual machine, a processing mode, etc. In some examples, the processing circuitry may operate in one of two or more security states. The security states may be associated with different physical address spaces. A process executing in a particular security state may not be able to access data or instructions associated with a particular other security state. In some examples, the target execution environment and the active execution environment include different security states. Thus, the first interrupt may require handling in a security state other than the active security state.

[0021] In some examples, the given action includes switching the security state. In some examples, the given action includes switching the security state from an active security state to a target security state.

[0022] The processing circuit may also operate at one of two or more exception levels. Each exception level may be associated with one of the security states. Different exception levels may be associated with different privileges, such as register access rights. The exception levels may be hierarchical, with higher privilege exception levels having greater privileges than lower privilege exception levels. A mechanism for switching between exception levels may include notifying the processing circuit of the exception and performing an exception return.

[0023] In some examples, the given action includes causing the processing circuit to switch to an exception level responsible for switching between security states. Thus, in response to a first exception, the processing circuit may preemptively switch to the exception level responsible for switching between security states, and in response to a second exception, the processing circuit may not preemptively switch to the exception level. By preemptively switching the processing circuit to the exception level responsible for switching between security states, the first exception may enable software to switch the processing circuit to the target security state to handle the first interrupt more quickly than if current software running when the first exception occurred had an opportunity to decide to delay switching to the exception level responsible for switching between security states.

[0024] In response to determining that the interrupt priority does not exceed the threshold priority, the second exception may be signaled without preemptively triggering a given action. However, it may be desirable for the first interrupt to be handled at some point despite not preemptively triggering a given action. Furthermore, it may be desirable in certain cases for a pending interrupt to be handled in the active execution environment to be handled before the first interrupt. In some examples, this may be achieved if the second exception indicates to the processing circuit that a second interrupt is pending, and the second interrupt may be handled by the processing circuit in the active execution environment. Because the second interrupt may be handled in the active execution environment, software in the active execution environment may be able to schedule handling of the second interrupt in an appropriate manner. The second interrupt may be a doorbell interrupt that indicates to the processing circuit that a first interrupt is pending for handling in a different execution environment. Thus, software handling a second interrupt in an active execution environment may be notified of a pending first interrupt to be handled in a different execution environment and may spontaneously trigger a given action so that the interrupt can be handled. In this case, when the given action is triggered, it is spontaneously triggered by software, rather than preemptively triggered by hardware (and therefore involuntary from the perspective of the software executing at the time the first exception is signaled) as in the case of the first exception.

[0025] The second interrupt may be configured similarly to other interrupts in the active execution environment. For example, the second interrupt may be associated with a second interrupt priority defined in the interrupt priority space of the active execution environment. Thus, software in the active execution environment may schedule handling of the second interrupt relative to any other interrupts to be handled in the active execution environment based on the second interrupt priority. This may be contrasted with the first exception, which preempts processing of the active execution environment outside of software control; thus, this preemption may occur even if there is a higher priority interrupt pending for the active execution environment. The second interrupt priority may be independent of the interrupt priority associated with the first interrupt. Thus, the priority of the doorbell interrupt may be independent of the priority of the first interrupt, providing greater control over scheduling and handling of the doorbell interrupt in the active execution environment.

[0026] Different execution environments may have different levels of security and privacy. Therefore, it may be undesirable for processing in one execution environment to be aware of an interrupt sent in a different execution environment. Thus, in some examples, the exception notification circuitry is configured to signal a second exception without exposing information about the cause of the first interrupt to code executed by the processing circuitry in the active execution environment. Thus, while the second exception may indicate that an interrupt is pending for processing in a different execution environment, the active execution environment may not have information about what caused the interrupt. This ensures that less privileged code in the active execution environment is not exposed to potentially confidential information about the execution of more privileged code in a different execution environment.

[0027] In some examples (e.g., supporting more than two execution environments), the doorbell interrupt may indicate which execution environment is the target execution environment of the pending first interrupt. This may provide software in the active execution environment responsible for deciding whether to trigger a given action with some information regarding the importance of the first interrupt. Thus, the software in the active execution environment may make a more informed choice about when to trigger a given action to be able to handle the first interrupt. (Also, in examples where software in a particular exception level is responsible for switching security states, this information may be useful for that software to decide which execution environment to switch to.) Despite indicating the target execution environment, the second interrupt may still not reveal the cause of the first interrupt and, therefore, may still ensure security for the other execution environments. The second interrupt can indicate the target execution environment of the first interrupt in different ways, but one approach is to assign different interrupt numbers to several variants of the second interrupt that correspond to different execution environments, so that when the first interrupt occurs, the associated one of the second interrupt variants that corresponds to the target execution environment of the first interrupt is selected, and the interrupt number of that second interrupt identifies to software which execution environment is the target execution environment of the first interrupt.

[0028] As described above, the selective notification of the first and second exceptions may be performed when the first interrupt is determined to satisfy at least one criterion including that the target execution environment is not the active execution environment, however, at least one additional criterion may also be applied.

[0029] In some examples, the at least one criterion also includes determining that the target execution environment is a preemptive execution environment. Thus, in some examples, the selective issuance of the first and second exceptions is performed only for interrupts that should be handled in a preemptive execution environment. Interrupts that should be handled in a target execution environment other than the active execution environment may be signaled differently when the target execution environment is not a preemptive execution environment. In particular, in some examples, interrupts that should be handled in an execution environment other than a preemptive execution environment may not be able to preempt processing in the active execution environment and therefore may be handled to yield processing time on processing circuitry so that another execution environment can handle the interrupt after software in the active execution environment voluntarily triggers a given action. To reduce performance impacts on processing in the active execution environment, it may be desirable to prevent certain execution environments from being able to preempt processing in a given execution environment.

[0030] In some examples, the at least one preemptive execution environment may be hardwired or set in a register that cannot be changed by software. This may provide a simple and safe way to identify whether an execution environment is a preemptive execution environment. However, a software developer may want to change which execution environments can preempt execution in an active execution environment at a given time. Thus, the exception notification circuit may be configured to determine whether a given execution environment is a preemptive execution environment based on preemptive execution environment indication information stored in at least one software-writable configuration register. For example, the preemptive execution environment indication information may be stored in a single configuration register or may be split among two or more registers, each storing a portion of the information.

[0031] In some examples, the preemptive execution environment indication information may indicate that some execution environments are preemptive execution environments. In this case, when processing in an active execution environment is preempted to handle a first interrupt in a different execution environment, there may be two or more pending first interrupts to be handled in different preemptive execution environments. In this case, the preemptive execution environments may be ranked, such that interrupts to be handled in higher-ranked execution environments are processed before interrupts to be handled in lower-ranked execution environments. The ranking may be implicit in the design of the processing system's hardware, or in some examples, may be configurable based on software-writable control information indicated in registers.

[0032] However, in some instances, the encoding of the preemptive execution environment indication information indicates that one execution environment is a preemptive execution environment at a given time, which provides a simpler mechanism for having only a single preemptive execution environment and can avoid conflicts between preemptive execution environments.

[0033] There are several ways in which the threshold priority can be determined. However, in some examples, the threshold priority is indicated by threshold priority information stored in a software-writable register. Software-writability allows the threshold priority to be set and modified by software during run-time. This can be useful because it may be desirable to allow software to set different threshold priorities at different points in a program.

[0034] It may also be desirable to set different threshold priorities for different execution environments. Thus, in some examples, encoding of threshold priority information allows indication of a threshold priority for a given execution environment that is separate from the threshold priority associated with at least one other execution environment. For example, different active execution environments may be associated with independent threshold priority values ​​such that a change between execution environments may also change the threshold priority for preemption in that execution environment. For example, the threshold priorities may be stored in a register bank, where different versions of a register are accessed by each execution environment.

[0035] In some examples, software may not be given complete control to change the thresholds. For example, software in an active execution environment may set a relatively high threshold to prevent itself from being preempted, but this may risk critical interrupts being delayed. Thus, in some examples, the control information defines whether a given execution environment is permitted to change the threshold priority information of a given target execution environment. This may, for example, prevent certain less trusted execution environments from being permitted to modify the threshold priority information.

[0036] Because the control information determines whether the execution environment can change the threshold priority information, it may be desirable for the control information to be set only by software at a high privilege level. Thus, in some examples, the control information is stored in a control register, and writing to the control register by software executing at a given exception level is not permitted if the given exception level is lower than the exception level responsible for switching between security states. The exception level responsible for switching between security states may be a higher (more privileged) exception level, often the highest exception level, and therefore may be trusted to set the control information.

[0037] In some examples, the first and second exceptions may be signaled to the processing circuit in the same manner, e.g., using the same input pin to the processing circuit. The first and second exceptions may then be distinguished using a second mechanism, such as an exception type value indicating whether the signaled exception is the first or second exception. However, in some examples, the first exception is signaled to the processing circuit on a first input pin and the second exception is signaled to the processing circuit on a second input pin, where the first input pin is separate from the second input pin. This provides an effective mechanism for signaling different exceptions based on whether the exception should preemptively trigger a given action. In some systems, the first and second input pins may already be provided (e.g., for “fast” and “normal” exceptions, where the “fast” exception should take precedence over the “normal” exception). Therefore, the present technique may be implemented with reduced hardware cost because new input pins do not need to be provided (the first exception may reuse the “fast” exception pin, and the second exception may reuse the “normal” exception pin).

[0038] In some examples, when it is determined that a first exception should be signaled, the exception notification circuit is configured to signal the first exception regardless of the current priority level of the process being executed by the processing circuit. For example, if a processing circuit operating in an active execution environment is handling an interrupt having a given priority, the first exception preemptively triggers a given action even if the given priority is higher than the interrupt priority associated with the first interrupt. This means that a critical interrupt can be handled quickly in the target execution environment regardless of the current process in the active execution environment. This also means that there is no comparison between the priority of an interrupt handled in the target execution environment and the priority of an interrupt in the active execution environment, and as a result, these priorities can be set completely independently of each other. Therefore, an interrupt priority space defined by an interrupt priority associated with a first interrupt handled in the target execution environment, and the interrupt priority space associated with the target execution environment, can be considered independent of an interrupt priority space associated with another execution environment. Thus, when software developers decide how to set interrupt priorities, they do not need to consider software that may be running in different execution environments (which simplifies and reduces costs of software development by reducing the need for coordination between software provided by different software developers), and further, they can access a wider portion of the interrupt priority space without trying to ensure that a priority exceeds a priority pending in another execution environment.

[0039] As introduced above, switching from an active security state to a target security state can be performed by software running at a particular exception level. To allow software at that exception level to know which security state to switch to to handle an interrupt, some examples may provide a pending interrupt configuration register accessible to software operating at the exception level responsible for switching between security states, the pending interrupt configuration register configured to store pending interrupt information indicating one or more execution environments that have pending interrupts. The pending interrupt configuration register may be provided as a system register rather than a location in memory, allowing the exception level responsible for switching between security states to quickly determine which security state to switch to. The register may provide a flag for each execution environment to indicate which execution environment has a pending interrupt. The pending interrupt configuration register is separate from any more detailed tracking of pending interrupts (e.g., a pending interrupt structure in memory that indicates a queue of pending interrupts). For example, the pending interrupt configuration register may not track specific details of pending interrupts, such as interrupt numbers, but may simply provide an overview of whether there are any pending interrupts for a given execution environment, allowing security state switching software to quickly identify which execution environment to switch to.

[0040] 1 illustrates, in schematic form, one embodiment of a data processing system 2 (e.g., a system-on-chip) that includes multiple processors 4 (e.g., Central Processing Units (CPUs)). In this example, three processors 4 are shown, although it will be understood that the number of processors may vary. The processors communicate with each other and with a shared memory 8 via a cache coherent interconnect 6 that supports a coherency protocol that maintains cache coherency of data cached in each processor's 4 private cache.

[0041] An interrupt controller 10 is provided to receive incoming interrupt signals from connected peripherals 14 and forward them to the processor 4. In some cases, the processor 4 itself may also function as an interrupt source, as processors also generate interrupts for other processors, known as Inter-Processor Interrupts (IPIs). Peripherals may signal interrupts to the interrupt controller 10 via dedicated lines 11 or by reusing existing I / O mechanisms 12, such as memory-mapped I / O (Input / Output) write operations, the latter typically known as Message-Signaled Interrupts (MSIs).

[0042] Therefore, the interrupt controller needs to be able to communicate with the processor to which it can forward interrupts. As shown in Figure 1, one way to accomplish this is to use a dedicated communication protocol and interrupt communication bus 16 within the system, which is specifically designed to carry interrupt signals from the interrupt controller 10 to the processor 4. In another approach, the existing cache coherency mechanism supported by the cache coherent interconnect 6 is leveraged for the distribution of interrupts from the interrupt controller 10 to the processor 4, with the interrupt configuration and state represented by a memory-based table shared by the processor and the interrupt controller. In both examples, the processing element 4 can be made aware that an interrupt event has occurred and can execute software to handle the interrupt.

[0043] Figure 2 shows an example of one of the processors 4 shown in Figure 1. Processor 4 includes processing circuitry 18 for performing processing operations. Processing circuitry 18 may operate in one of multiple exception levels and one of multiple security states, as shown in Figures 3 and 4.

[0044] FIG. 3 illustrates an example of a process that may be performed by processing circuitry 18. Hypervisor 30 may manage several virtual machines (VMs, also known as guest operating systems or guest OSs) 32. While one VM 32 is shown in FIG. 3, it will be understood that the hypervisor may manage several VMs. Each VM 32 may manage one or more applications 34. For example, hypervisor 30 may control which region of address space is assigned to each virtual machine 32 and control switching between virtual machines 32. Similarly, each VM 32 may control which region of address space is assigned to each application 34 running under that VM 32 and control switching between applications as needed.

[0045] As shown in Figure 3, each process is associated with a given privilege level EL0, EL1, EL2, or EL3. In this example, higher-numbered privilege levels are more privileged than lower-numbered privilege levels, although in other examples the numbering may be reversed. In this example, application 34 runs at privilege level EL0, VM 32 runs at privilege level EL1, and hypervisor 30 runs at privilege level EL2. Typically, processes running at higher privilege levels have rights that are not available to processes running at lower privilege levels.

[0046] As shown in FIG. 3 , the hypervisor 30, VM 32, and applications 34 may operate in a non-secure security state. Additionally, the device may support a secure security state that is separate from the non-secure security state. Thus, there may also be processes running in the secure security state, such as a trusted operating system (OS) 38 and trusted services (applications) 40 running in the secure security state under the control of the trusted OS 38. The secure and non-secure security states may be associated with different physical address spaces. A processing circuit 18 operating in the secure state may be able to access both secure and non-secure physical address spaces and both secure and non-secure system registers. In the non-secure state, the processing circuit 18 can only access the non-secure physical address space and system registers that enable non-secure access. The trusted OS 38 and trusted applications 40 execute at privilege levels EL1 and EL0, respectively. A secure partition manager 36 may be provided in EL2 in the secure state to control execution in the secure security state in a manner similar to the hypervisor 30 in the non-secure state. Firmware 42 is also provided at privilege level EL3 to manage transitions between the non-secure and secure security states. Firmware 42 may be considered part of the secure security state. One example of a technology for partitioning non-secure and secure security states is Arm® Trustzone® technology, although other examples may also be used.

[0047] FIG. 4 illustrates a further example. In FIG. 4, in addition to the secure and non-secure security states, a realm security state associated with an additional physical address space, referred to as the realm physical address space, is also provided. Processes, including a realm manager 44, an operating system 46, and applications 48, may execute at exception levels EL2-EL0 in the realm security state in a manner similar to the non-secure and secure states. When in the realm security state, processing circuitry 18 may have access to the realm and non-secure physical address spaces but may not have access to the secure physical address space. The secure security state may not have access to the realm physical address space. In the example of FIG. 4, an EL3 exception level for switching between security states may be provided in the root security state, which is independent from other security states. In the root state, processing circuitry 18 may have access to all physical address spaces. One example of a technique for distinguishing between the non-secure, secure, realm, and root security states is the Arm® Realm Management Extension, although other examples may also be used.

[0048] Returning to FIG. 2, processor 4 also includes an interrupt detection circuit 20 and an exception notification circuit 22. Together, interrupt detection circuit 20 and exception notification circuit 22 may be considered a CPU interface through which interrupt controller 10 can communicate with processing circuit 18. CPU 4 has several exception input pins for notifying processing circuit 18 of different types of exceptions. FIG. 2 shows two exception input pins: a fast interrupt (FIQ) pin 26 and a standard interrupt (IRQ) pin 28. Because FIQ pin 26 may be used for interrupt types that require faster handling than those on IRQ pin 28, exceptions posted on the FIQ pin may take priority over exceptions posted on the IRQ pin. In some instances, these may not be the only exception input pins, and at least one additional pin may be provided for another class of exception.

[0049] The interrupt detection circuit 20 receives an indication of an interrupt from the interrupt controller 10 via the interrupt communication bus 16 or the interconnect 6, as described above (e.g., the indication received via the interconnect 6 may be a coherence snoop message indicating that a write request to a given address assigned by the interrupt controller 10 for the interrupt notification has been detected). The interrupt may require handling by software running in a particular security state of the processing circuit 18. For example, the processing circuit 18 may be operating in a non-secure state, and the interrupt controller 10 indicates an interrupt that requires handling in a secure state. Thus, it may be necessary to switch from an active security state to a different security state in order to handle the interrupt.

[0050] In one example, whenever the interrupt detection circuit detects an interrupt that is handled in a security state other than the active security state, this may be signaled to the processing circuit using a given exception, for example, this may be signaled on the FIQ input pin 26.

[0051] In one example, in response to notification of a given exception indicating receipt of an interrupt to be handled in a different security state, processing circuitry 18 may always switch to the EL3 exception level, which is responsible for switching between security states. It will be understood that EL3 is used to mean the exception level responsible for switching between security states. This is often the most privileged exception level, but in a particular implementation, it may not necessarily be EL3. Once processing switches to EL3, software executing at EL3 may switch to the target security state for handling the interrupt. While always switching to EL3 in response to an interrupt to be handled in a different security state may allow the interrupt to be handled quickly, this technique may disrupt processing in the active security state because the transition to EL3 occurs regardless of processing in the active security state. At times, accepting an interrupt at the current moment of processing may be less efficient than if current processing in the active security state could proceed a short distance before accepting the interrupt at a point where less architectural state needs to be saved to memory upon accepting the interrupt.

[0052] In an alternative example, in response to notification of a given exception, processing circuit 18 may never immediately (preemptively) switch to the EL3 exception level. Software may continue to operate in the active security state and may decide when to spontaneously trap to a higher exception level to respond to an exception. For example, when operating at the EL0 exception level, a given exception may cause processing circuit 18 to transition to the EL1 exception level. Software at the higher exception level may then determine to handle the interrupt and cause processing to switch to EL3 so that the security state may be changed, or alternatively, may decide to return to a lower exception level, terminate processing before switching to EL3, and handle the interrupt after terminating processing. Thus, by not immediately switching to EL3 when an interrupt that should be handled in a different security state is received, processing in the active security state may experience fewer interruptions. However, this places software in the active execution environment in control of the timing of interrupt handling, which may delay handling of critical interrupts.

[0053] In some examples, the value stored in a register can control processing circuit 18 to respond to a given exception by switching to EL3 or by allowing software to decide how to handle the exception. For example, the register may be one of registers 24 associated with processing circuit 18. However, while this technique may allow software designers more design freedom regarding interrupt handling, at any given time, this technique is limited to either always preemptively switching to EL3 in response to an interrupt handled in another security state (regardless of the characteristics of that interrupt) or always allowing software to decide when to switch to EL3 (regardless of the characteristics of that interrupt). Toggling the value stored in a register prior to receipt of a particular interrupt requiring either preemptive or non-preemptive handling is impractical because the timing of receipt of that interrupt is unknown. The reasons why an interrupt that needs to be handled in another security state may be received are wide-ranging. While some interrupts require urgent handling that merits preempting execution in the active security state, other interrupts may be less important, in which case it would be preferable to avoid preempting execution in the active execution environment and instead allow software in the active security state to decide when to handle the interrupt. The present technique provides a mechanism by which interrupts to be handled in target security states other than the active security state may be signaled to processing circuitry 18 in different ways.

[0054] Figure 5 shows an example of a register 24 that may be provided in the processor 4. The register 24 may be accessible to, for example, the exception notification circuit 22 and the processing circuit 18. The suffix _ELx shown for a register in Figure 5 indicates the lowest privilege exception level permitted to write to that register; for example, ICC_CTLR_EL1 may therefore be written by software running at EL1, EL2, or EL3, while ICC_CTLR_EL3 may be written by software at EL3. It will be understood that the register names shown are arbitrary and the same control information represented in these registers may be represented in other ways (e.g., information described in different registers in Figure 5 may in other examples be stored in the same register).

[0055] The registers 24 include at least one ICC_CTLR_EL1 register, which stores a priority threshold.

[0056] When the interrupt controller 10 notifies the processor 4 of an interrupt event, the interrupt is associated with an interrupt priority. Interrupt priorities may be used in some systems to select the order in which interrupts are handled. For example, each pending interrupt may be associated with an interrupt priority, and the exception notification circuit may determine which pending interrupt to notify the processing circuit based on which pending interrupt has the highest priority. Priorities may also be used to mask certain interrupts. If an interrupt has a priority below a masking priority (which may be configurable by software that sets a mask threshold level), the interrupt may be determined to be unacceptable, and the exception notification circuit may not notify the processing circuit of an exception in response to the unaccepted interrupt.

[0057] Upon receiving an interrupt to be handled in a security state other than the active security state, the exception notification circuit may compare the interrupt priority associated with the interrupt to the priority threshold stored in the ICC_CTLR_EL1 register. In some schemes, a numerically lower value may represent a higher priority, and thus, the interrupt priority may exceed the priority threshold if its value is numerically less than the priority threshold. If the interrupt priority is equal to or greater than the priority threshold, the interrupt priority may not exceed the threshold. In other examples, a numerically higher value of the interrupt priority may represent a higher (more important) priority, and thus, the interrupt priority may exceed the priority threshold if its value is numerically higher than the priority threshold. In either case, depending on whether the interrupt priority exceeds the threshold (in addition to further conditions described below), the exception notification circuit may signal either a first exception or a second exception.

[0058] The first exception may be signaled to the processing circuit 18 on the FIQ input pin. The second exception may be signaled on the IRQ input pin. Thus, rather than using a single exception to signal all received interrupts to be handled in security states other than the active security state, the technique can signal two different exceptions depending on a comparison between the priority of the interrupt and a threshold. The first exception signaled on the FIQ pin may cause the processing circuit 18 to preemptively switch to the EL3 exception level outside of software control, which may then allow software in EL3 to switch to the target security state to handle the interrupt. The second exception signaled on the IRQ pin may not cause a preemptive switch to the EL3 exception level, but instead may allow software operating in the active security state to determine when to switch to EL3 to allow the interrupt to be handled. Thus, the signaling of the exception to the processing circuit can vary based on the priority of the interrupt, allowing different interrupts to be handled differently, reducing the impact on software in the active security state but ensuring that critical interrupts for the target security state can be addressed quickly.

[0059] As shown in FIG. 5 , in addition to register 50, there may be several versions of the ICC_CTLR_EL1 register. These may include bank copies 52, 54 of the ICC_CTLR_EL1 register, each associated with a security state. While three register banks are shown, it will be understood that this may vary based on the implementation. Thus, different versions of the register may be accessed based on the active security state of processing circuit 18. Because the priority threshold is based on the value in the register, the priority threshold may change between security states. The value in register ICC_CTLR_EL1 may be written by software at EL1, EL2, or EL3, allowing a software designer to change how critical an interrupt needs to be before preempting execution in the active security state. In some implementations, there may be a permission accessible only to EL3 that determines how software may modify the priority threshold.

[0060] In addition to the threshold priority comparison described above, the exception notification circuitry may also determine whether the exception should be handled in a preemptive interrupt domain. The preemptive interrupt domain may be one of the security states. For example, a register ICC_CTLR_EL3 56 may be provided that indicates which security state is the preemptive interrupt domain. For example, two bits may be used to select one of the non-secure, secure, and realm security states shown in FIG. 4. Writing to register ICC_CTLR_EL3 may be restricted to software running at EL3.

[0061] In some examples, more than one security state may be considered a preemptive interrupt domain. In some examples, each security state may be considered a preemptive interrupt domain. However, in some examples, architectural complexity may be reduced by supporting only a single preemptive interrupt domain at a time, which may be selected by EL3 software setting a value in ICC_CTLR_EL3.

[0062] The exception notification circuitry may signal only the first exception on the FIQ pin when the target security state is a preemptive interrupt domain. Thus, processing may be caused to preemptively switch to EL3 (outside the control of software executing at EL0, EL1, or EL2 in the active security state) in response to an interrupt that should be handled in the preemptive interrupt domain. This provides a second mechanism by which an interrupt can be evaluated to determine whether to signal a first exception or a second exception. Thus, both whether the target interrupt domain is a preemptive interrupt domain and whether the interrupt priority exceeds a priority threshold can be evaluated. By performing both comparisons, software designers are presented with greater control over how a given interrupt is signaled to the processing circuitry, so that critical interrupts can be handled quickly while less critical interrupts have a reduced impact on processing.

[0063] The registers also include a register ICC_DOMHPPIR_EL3 58 accessible to processing at the EL3 exception level. After processing switches to EL3 due to a hardware switch in response to an FIQ exception or due to software yield control after an IRQ exception, software in EL3 needs to determine which security state to switch to so that it can handle the interrupt. This can be indicated in the ICC_DOMHPPIR_EL3 register. For example, if there is a single preemptive interrupt domain, there can be a single bit that indicates whether there is a pending interrupt to be handled in the preemptive interrupt domain. The preemptive security state can be determined from the ICC_CTLR_EL3 register, and thus software in EL3 can switch to the preemptive security state to handle the interrupt when the bit indicates a pending interrupt in the preemptive interrupt domain. In other examples, there may be more than one interrupt domain, and thus there may be a bit associated with each of the realm, secure, and non-secure security states, which in one state indicates that there is a pending interrupt for that security state and in another state indicates that there is no pending interrupt for that security state. In some examples with multiple preemptive interrupt domains, the security states may be ranked to determine the order in which EL3 should handle interrupts simultaneously pending in multiple preemptive security states. Regardless of the particular format of the pending interrupt information in ICC_DOMHPPIR_EL3, this information may be set (in hardware) by the interrupt detection circuit 20 or the exception notification circuit 22 when a pending interrupt is detected for a given interrupt domain / security state and cleared by hardware when there are no longer any pending interrupts for that domain / security state. This information is separate from the tracking of pending interrupt queues using structures maintained by the interrupt controller 10.ICC_DOMHPPIR_EL3 can be considered a summary of such a more detailed pending interrupt queue (which can track the specific interrupt numbers of pending interrupts), in that ICC_DOMHPPIR_EL3 is a summary of whether there are any pending interrupts for a given domain / security state that can be accessed more quickly by EL3 software than the more detailed interrupt tracking structure maintained by the interrupt controller 10.

[0064] FIG. 6A shows an example of the behavior of the processing circuit when a second exception is signaled.

[0065] At step 600, processing circuitry 18 is operating in an active security state. While Figure 6 shows the application running at EL0, processing circuitry 18 could also be running at EL1 or EL2, for example.

[0066] In step 602, a second exception is signaled to processing circuit 18. This may include signaling the exception on an IRQ input pin. The second exception may be signaled in response to the interrupt detection circuit detecting a first interrupt, where the first interrupt is handled in a target security state that is different from the active security state. The second exception may be signaled when the target security state is determined to be a security state other than a preemptive security state based on one or more preemptive security state indications stored in the ICC_CTLR_EL3 register. Alternatively, the target security state may be a preemptive security state, but the interrupt priority associated with the first interrupt may not exceed the threshold priority indicated in the active ICC_CTLR_EL1 register.

[0067] In step 604, in response to the second exception, the processing circuit does not switch to EL3. The processing circuit can remain in the active security state and switch to an exception level (e.g., EL1 or EL2) to handle the exception. Rather than presenting the first interrupt to software in the active security state, the second exception indicates a second interrupt. The second interrupt, unlike the first interrupt, can be handled in the active security state, and therefore software in the active security state can schedule handling of the second interrupt, just like all other interrupts handled in the active security state. The second interrupt has an interrupt priority defined in the interrupt priority space used by the active security state, which is independent of the interrupt priority of the first interrupt in the interrupt priority space used by the target security state. The priority of the second interrupt is used to prioritize the second interrupt over other interrupts targeted to the active security state. The second interrupt indicates to software in the active security state that an interrupt is pending to be handled in a different security state. However, the second interrupt does not reveal information about the first interrupt to software in the active security state, which can be important to avoid exposing secrets associated with one security state to software in a different security state.

[0068] In step 606, the exception handling software for the active security state may decide to return to processing at EL0 of the active security state and handle the interrupt at a later time, or may voluntarily yield processing to EL3 so that the first interrupt can be handled.

[0069] If the decision is made to yield to EL3 in step 608, the software in EL3 uses the ICC_DOMHPPIR_EL3 register to determine if there are any pending interrupts to be handled in the preemptive security state. If it determines that there are any pending interrupts for the preemptive interrupt domain, the software switches to the (only or highest priority) preemptive security state in step 610 to handle the first interrupt.

[0070] FIG. 6B shows an example of the behavior of the processing circuit when the first exception is signaled.

[0071] In step 612, processing circuitry 18 is operating in an active security state, similar to step 600 of FIG. 6A.

[0072] In step 614, a first exception is signaled to the processing circuit 18. This may include signaling the exception on an FIQ input pin. The first exception is signaled in response to the interrupt detection circuit detecting the first interrupt, and the first interrupt is handled in a target security state that is different from the active security state. The first exception may be signaled when the target security state is determined to be a preemptive security state based on one or more preemptive security state indications stored in the ICC_CTLR_EL3 register, and the interrupt priority associated with the first interrupt is determined to exceed the threshold priority indicated in the active ICC_CTLR_EL1 register. In some examples, the first exception may also be signaled when the interrupt is determined to be of a type that should be handled at the EL3 exception level.

[0073] In step 616, in response to the first exception, the processing circuitry preemptively switches to EL3 outside the control of software executing in the active security state, which preempts processing in the active security state.

[0074] In step 618, software in EL3 uses the ICC_DOMHPPIR_EL3 register to switch to the target security state as in step 608, allowing handling of the first interrupt. By preemptively switching to EL3, the processing circuit ensures that the first interrupt is handled promptly and bypasses any decisions made by software in the active security state, including the possibility of deferring yielding to EL3 while processing is completed. Processing then continues at the exception level of the target security state for handling the interrupt in step 620. Comparing the processes shown in FIGS. 6A and 6B, it can be seen that interrupts can be handled more quickly when an FIQ exception is signaled rather than an IRQ exception, because this bypasses software in EL1 / EL2 of the active security state, which has no choice as to whether yielding to EL3 occurs. Therefore, the first exception may be more appropriate for interrupts requiring prompt handling.

[0075] 7 illustrates a process for notifying the processing circuit 18 of an exception. This process may be performed by, for example, the interrupt detection circuit 20 and the exception notification circuit 22.

[0076] A first interrupt is detected in step 700. It is determined that the first interrupt is handled in the target security state.

[0077] In steps 702-710, it is determined whether the first interrupt satisfies at least one criterion.

[0078] In step 702, it is determined whether the first interrupt should be handled in EL3. In the example shown in Figure 4, this may involve, for example, determining that the target security state is the root domain. If it is determined that the interrupt should be handled in EL3, then in step 704, an FIQ exception is signaled to processing circuitry 18 on FIQ input pin 26. The FIQ signal causes processing circuitry 18 to switch to EL3 outside of software control. Thus, the hardware of processor 4 is configured such that an exception handled in EL3 causes the processing circuitry to switch to EL3.

[0079] If it is determined that the first interrupt should not be handled in EL3, then in step 706 it is determined whether the target security state is the active security state. The active security state may be indicated in a system register. If the target security state is the active security state and the interrupt is not targeted to EL3, there is no need to switch to a different security state to handle the first interrupt. Therefore, in step 708, the exception notification circuit signals an IRQ exception on IRQ input pin 28. The IRQ exception does not cause the processing circuit to switch to EL3. Instead, the IRQ may cause processing to switch to a higher exception level within the same security state for handling the interrupt. Software in the active security state then controls the handling of the interrupt.

[0080] If it is determined that the target security state is different from the active security state, then in step 710, it is determined whether the target security state of the first interrupt is a preemptive security state. One or more preemptive security states may be determined based on EL3 configurable control information in register ICC_CTLR_EL3. A preemptive security state is a security state in which interrupts (other than those to be handled in EL3) are allowed to preempt processing in the active security state. If the target security state is not a preemptive security state, then an FIQ exception is not signaled because interrupts are not allowed to preempt execution in the active security state. Thus, in step 712, an IRQ exception is signaled. The IRQ exception may signal a second interrupt indicating to software in the active security state that the first interrupt is pending for handling in a security state other than the active security state.

[0081] If it is determined that the first interrupt meets at least one criterion, then it is determined whether the interrupt priority associated with the first interrupt exceeds a threshold priority in step 714. The threshold priority of the active security state may be determined from one of the ICC_CTLR_EL1 register banks 50, 52, 54 associated with the target security state of the first interrupt. The interrupt priority associated with the first interrupt may be communicated to the processor 4 from the interrupt controller 10.

[0082] If it is determined that the interrupt priority does not exceed the threshold priority, then the first interrupt is determined to be too low a priority to preempt processing in the active security state. Therefore, an FIQ exception to preempt processing is not signaled; instead, in step 720, an IRQ exception is signaled to processing circuitry 18, similar to step 712. This allows software in the active security state to be aware that an interrupt is pending for a different security state, and the software can yield to EL3 for handling of the interrupt.

[0083] If the interrupt priority is determined to exceed the threshold, the first interrupt is deemed to be of sufficiently high priority that processing in the active security state can be preempted to handle the interrupt. Therefore, an FIQ exception is signaled in step 716. In step 718, the FIQ exception causes processing circuit 18 to switch to the EL3 exception level, which is outside the control of software in the active security state. This switch occurs regardless of processing being performed in the active security state. The switch to EL3 allows software in EL3 to switch to the target security state for handling the first interrupt.

[0084] Thus, by differentiating between interrupts based on target security state and interrupt priority, the present technique allows for greater control over whether a given interrupt should preempt a process at a given time, providing a balance between fast handling of critical interrupts and minimizing interruptions to ongoing processes.

[0085] It will be understood that certain steps illustrated in FIG. 7 may be performed in a different order or in parallel.

[0086] 8 shows an example of a process that may be performed by software executing in EL3. In step 800, processing switches to EL3 in response to an exception. This switch may be caused by an FIQ exception outside the control of the software, or by software relinquishing control to EL3 (in response to an IRQ exception or otherwise).

[0087] In step 802, the software checks the pending interrupt configuration register ICC_DOMHPPIR_EL3 to determine which security states have pending interrupts.

[0088] In step 804, the EL3 software handles any pending interrupts requiring handling in EL3. If there are no pending interrupts for EL3, the EL3 software determines whether a preemptive security state has a pending interrupt. If so, and if there is only one preemptive security state, a decision is made to switch to the preemptive security state so that the software in that security state can handle the pending interrupt. If there are two or more preemptive security states, the EL3 software determines which is the highest priority preemptive security state with a pending interrupt. If there are no preemptive security states with pending interrupts, the EL3 software determines whether there are other security states with pending interrupts. In either case, once a security state is selected, the EL3 software causes the processing circuitry to switch to the selected security state in step 806 and then yields to the exception level within that security state for handling the interrupt in step 808.

[0089] 9 illustrates an example of processing that may be performed by software in an active execution environment in response to an IRQ exception. At step 900, an IRQ exception is received on an IRQ input pin. This may be signaled as shown in FIG. 7.

[0090] In response to the IRQ exception, a process in the active security state may switch to a higher exception level within the same security state in step 902. In some cases, for example, if the process is already in EL1 or EL2 and the exception is handled at that exception level, the process may continue at the same exception level but switch to different software (e.g., a different exception handling routine) within that exception level.

[0091] In step 904, the software checks for a pending doorbell interrupt signaled by the second exception. The doorbell interrupt may be handled in the active security state, indicating that an interrupt is pending to be handled in a different security state. Software in EL1 / EL2 schedules handling of the doorbell interrupt like any other interrupt to be handled in the active security state. The doorbell interrupt is associated with a priority for scheduling the interrupt in the active security state. The doorbell interrupt may indicate which security state is the target security state of the pending interrupt (e.g., by selecting from among a set of doorbell interrupts having different interrupt numbers each corresponding to one of the security states, with the interrupt number of the doorbell interrupt identifying which other security state is the target security state). In response to the doorbell interrupt, in step 906, the software determines whether to switch to EL3 so that the security state can be switched for handling the interrupt, or to continue processing in the active security state. If it is determined at that time to switch to EL3, then in step 908 the software voluntarily yields processing to EL3, such as by sending a supervisor call targeting EL3.

[0092] If it is determined not to switch to EL3 at that time, processing continues in the active security state. For example, processing that occurred before the IRQ exception may be resumed. In step 910, the software in the active security state later determines to switch to EL3 to allow handling of the pending interrupt. Thus, in step 912, the software in the active security state voluntarily yields processing to EL3.

[0093] It can be seen that in response to an IRQ exception, software in the active security state controls the decision as to when to handle the first interrupt.

[0094] The concepts described herein may be embodied in computer-readable code for the manufacture of devices embodying the described concepts. For example, the computer-readable code may be used in one or more stages of the semiconductor design and manufacturing process, including Electronic Design Automation (EDA) stages, to manufacture integrated circuits comprising devices embodying the concepts. Such computer-readable code may additionally or alternatively enable the definition, modeling, simulation, verification, and / or testing of devices embodying the concepts described herein.

[0095] For example, computer-readable code for producing a device embodying the concepts described herein may be embodied in code defining a Hardware Description Language (HDL) representation of the concept. For example, the code may define a Register-Transfer-Level (RTL) abstraction of one or more logic circuits to define a device embodying the concept. The code may define an HDL representation of one or more logic circuits embodying the device in intermediate representations such as Verilog, SystemVerilog, Chisel, or Very High-Speed ​​Integrated Circuit Hardware Description Language (VHDL) and FIRRTL. The computer-readable code may provide a definition embodying the concept using system-level modeling languages ​​such as SystemC and SystemVerilog or other behavioral representations of the concept that can be interpreted by a computer to enable simulation, functional and / or formal verification, and testing of the concept.

[0096] Additionally or alternatively, the computer-readable code may define a low-level description of integrated circuit components embodying the concepts described herein, such as one or more netlists or integrated circuit layout definitions, including representations such as GDSII. One or more netlists or other computer-readable representations of the integrated circuit components may be generated by applying one or more logic synthesis processes to the RTL representations to generate definitions used to manufacture devices embodying the invention. Alternatively or additionally, the one or more logic synthesis processes may generate a bitstream from the computer-readable code that is loaded into a Field Programmable Gate Array (FPGA) to configure the FPGA to embody the described concepts. The FPGA may be deployed for concept verification and testing purposes prior to fabrication in an integrated circuit, or the FPGA may be deployed directly into a product.

[0097] The computer readable code may include a mixture of code representations for fabricating a device, including, for example, a mixture of one or more of an RTL representation, a netlist representation, or another computer readable definition used in a semiconductor design and manufacturing process to fabricate a device embodying the invention. Alternatively or additionally, a concept may be defined in a combination of a computer readable definition used in a semiconductor design and manufacturing process to fabricate a device and computer readable code that defines instructions to be executed by the defined device once fabricated.

[0098] Such computer readable code may be disposed on any known transitory computer readable medium (such as wired or wireless transmission of code over a network) or on a non-transitory computer readable medium such as a semiconductor, magnetic disk, or optical disk. Integrated circuits manufactured using computer readable code may include one or more components such as a central processing unit, graphics processing unit, neural processing unit, digital signal processor, or other components that individually or collectively embody the concepts.

[0099] In this application, the term "configured to" is used to mean that elements of a device have a configuration that is capable of performing a defined operation. In this context, "configuration" refers to a manner of arrangement or interconnection of hardware or software. For example, a device may have dedicated hardware that provides the defined operation, or a processor or other processing device may be programmed to perform the function. "Configured to" does not imply that device elements need to be modified in any way to provide the defined operation.

[0100] Although illustrative embodiments of the present invention are described in detail herein with reference to the accompanying drawings, it will be understood that the invention is not limited to those precise embodiments, and that various changes and modifications can be made to the embodiments by those skilled in the art without departing from the scope of the invention as defined by the appended claims.

Claims

1. 1. An apparatus comprising: an interrupt detection circuit configured to detect a first interrupt handled by a processing circuit operating in the target execution environment; an exception notification circuit configured to notify the processing circuit of an exception in response to the accepted interrupt; In response to determining that the first interrupt satisfies at least one criterion, the at least one criterion includes determining that the target execution environment is an execution environment other than an active execution environment of the processing circuit, the exception notification circuitry: signaling a first exception to preemptively trigger a given action in response to determining that an interrupt priority associated with the first interrupt exceeds a threshold priority, and switching from the active execution environment to the target execution environment is dependent on the given action being performed; In response to determining that the interrupt priority does not exceed the threshold priority, the apparatus is configured to signal a second exception without preemptively triggering the given action.

2. The apparatus of claim 1 , wherein the target execution environment and the active execution environment comprise different security states.

3. The apparatus of claim 2 , wherein the given action includes causing the processing circuitry to switch to an exception level responsible for switching between security states.

4. 4. The apparatus of claim 1, wherein the second exception indicates to the processing circuitry that a second interrupt is pending, and wherein the second interrupt can be handled by the processing circuitry of the active execution environment.

5. 5. The apparatus of claim 4, wherein the second interrupt is associated with a second interrupt priority defined in an interrupt priority space of the active execution environment, the second interrupt priority being independent from the interrupt priority associated with the first interrupt.

6. 6. The apparatus of claim 4, wherein the exception notification circuitry is configured to signal the second exception without exposing information about the cause of the first interrupt to code executed by the processing circuitry in the active execution environment.

7. The apparatus of any one of claims 4 to 6, wherein the second interrupt indicates the target execution environment of the first interrupt.

8. The apparatus of any one of claims 1 to 7, wherein determining that the interrupt satisfies at least one criterion comprises determining that the target execution environment is a preemptive execution environment.

9. 9. The apparatus of claim 8, wherein the exception notification circuitry is configured to determine whether a given execution environment is a preemptive execution environment based on preemptive execution environment indication information stored in at least one software-writeable configuration register.

10. 10. The apparatus of claim 9, wherein the encoding of the preemptive execution environment indication information indicates that one execution environment is the preemptive execution environment at a given time.

11. The apparatus of any preceding claim, wherein the threshold priority is indicated by threshold priority information stored in a software-writeable register.

12. The apparatus of claim 11 , wherein the encoding of the threshold priority information enables indication of a threshold priority of a given execution environment that is distinct from a threshold priority associated with at least one other execution environment.

13. 13. The apparatus of claim 11 or 12, wherein control information defines whether a given execution environment is permitted to modify the threshold priority information of a given target execution environment.

14. the control information is stored in a control register; 14. The apparatus of claim 13, wherein writing to a control register by software executing at a given exception level is not permitted if the given exception level is lower than an exception level responsible for switching between security states.

15. 15. The apparatus of claim 1, wherein the first exception is signaled to the processing circuit on a first input pin and the second exception is signaled to the processing circuit on a second input pin, the first input pin being separate from the second input pin.

16. 16. The apparatus of claim 1, wherein in response to determining that the first interrupt satisfies the at least one criterion, the target execution environment is an execution environment other than the active execution environment of the processing circuit, and the interrupt priority exceeds the threshold priority, the exception notification circuit is configured to signal the first exception regardless of a current priority level of a process being performed by the processing circuit.

17. the interrupt priority values ​​are defined within an interrupt priority space; and The apparatus of any preceding claim, wherein the interrupt priority space associated with the target execution environment is independent of an interrupt priority space associated with another execution environment.

18. A pending interrupt configuration register accessible to software running at the exception level responsible for switching between security states; 18. The apparatus of claim 1, wherein the pending interrupt configuration register is configured to store pending interrupt information indicative of one or more execution environments having pending interrupts.

19. 1. A method comprising: Detecting a first interrupt handled by processing circuitry operating in a target execution environment; notifying the processing circuit of an exception in response to the accepted interrupt, wherein the method comprises: in response to determining that the first interrupt satisfies at least one criterion, the at least one criterion including determining that the target execution environment is an execution environment other than an active execution environment of the processing circuit; in response to determining that an interrupt priority associated with the first interrupt exceeds a threshold priority, signaling a first exception to preemptively trigger a given action, and switching from the active execution environment to the target execution environment being dependent on the given action being performed; and in response to determining that the interrupt priority does not exceed the threshold priority, signaling a second exception without preemptively triggering the given action.

20. 1. A computer readable medium for storing computer readable code for manufacturing an apparatus, the apparatus comprising: an interrupt detection circuit configured to detect a first interrupt handled by a processing circuit operating in the target execution environment; an exception notification circuit configured to notify the processing circuit of an exception in response to the accepted interrupt; In response to determining that the first interrupt satisfies at least one criterion, the at least one criterion includes determining that the target execution environment is an execution environment other than an active execution environment of the processing circuit, the exception notification circuitry: signaling a first exception to preemptively trigger a given action in response to determining that an interrupt priority associated with the first interrupt exceeds a threshold priority, and switching from the active execution environment to the target execution environment is dependent on the given action being performed; responsive to determining that the interrupt priority does not exceed the threshold priority, signaling a second exception without preemptively triggering the given action.

Images