Abnormal signaling

Abstract

An apparatus has an interrupt detection circuit to detect a first interrupt to be handled by a processing circuit in a target execution environment. The apparatus also has exception signaling circuitry to signal an exception to the processing circuitry in response to the accepted interruption. When the first interrupt satisfies at least one criterion, including when the target execution environment is not an active execution environment of the processing circuitry, the exception signaling circuitry is configured to signal a first exception or a second exception according to an interrupt priority associated with the first interrupt. When the interrupt priority exceeds a threshold priority, the first anomaly is signaled to preemptively trigger a given action wherein switching from the active execution environment to the target execution environment depends on the given action, and when the interrupt priority does not exceed the threshold priority, the second anomaly is signaled to preemptively trigger the given action wherein switching from the active execution environment to the target execution environment depends on the given action. The given action is not preemptively triggered.

Description

[0001] This technology relates to the field of abnormal signaling.

[0002] In a data processing system, one or more interrupt sources may trigger an interrupt indicating that an interrupt event has occurred. An exception can be signaled to a processing circuit to indicate that an interrupt event has occurred, thereby triggering the processing circuit to handle the interrupt. The interrupt may need to be handled by a processing circuit operating in a target execution environment, so handling the interrupt may involve switching from an active execution environment to the target execution environment. Switching between execution environments may cause the processing to be interrupted, but it may be important for timely handling of important interrupts, so it is desirable to provide increased control over the switching between execution environments in response to an interrupt.

[0003] At least some examples provide an apparatus including:

[0004] an interrupt detection circuit configured to detect a first interrupt to be handled by a processing circuit operating in a target execution environment; and

[0005] an abnormal signaling circuit configured to signal an exception to the processing circuit in response to an accepted interrupt; wherein

[0006] in response to determining that the first interrupt meets at least one criterion, the at least one criterion including determining that the target execution environment is an execution environment other than the active execution environment of the processing circuit, the abnormal signaling circuit is configured to:

[0007] in response to determining that the interrupt priority associated with the first interrupt exceeds a threshold priority, signal a first exception to preemptively trigger a given action, wherein switching from the active execution environment to the target execution environment depends on the given action being executed; and

[0008] in response to determining that the interrupt priority does not exceed the threshold priority, signal a second exception without preemptively triggering the given action.

[0009] At least some examples provide a method including:

[0010] detecting a first interrupt to be handled by a processing circuit operating in a target execution environment; and

[0011] signaling an exception to the processing circuit in response to an accepted interrupt; wherein the method includes:

[0012] in response to determining that the first interrupt meets at least one criterion, the at least one criterion including determining that the target execution environment is an execution environment other than the active execution environment of the processing circuit:

[0013] 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, wherein switching from the active execution environment to the target execution environment depends on the given action being performed; and

[0014] In response to determining that the interrupt priority does not exceed the threshold priority, signaling a second exception without preemptively triggering the given action.

[0015] At least some examples provide a computer-readable medium for storing computer-readable code for manufacturing a device, the device including:

[0016] An interrupt detection circuit configured to detect a first interrupt to be handled by a processing circuit operating in a target execution environment; and

[0017] An exception signaling circuit configured to signal an exception to the processing circuit in response to an accepted interrupt; wherein

[0018] In response to determining that the first interrupt meets at least one criterion, the at least one criterion including determining that the target execution environment is an execution environment other than the active execution environment of the processing circuit, the exception signaling circuit is configured to:

[0019] 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, wherein switching from the active execution environment to the target execution environment depends on the given action being performed; and

[0020] In response to determining that the interrupt priority does not exceed the threshold priority, signaling a second exception without preemptively triggering the given action.

[0021] The computer-readable medium can be a non-transitory storage medium.

[0022] Additional aspects, features, and advantages of the present technology will be apparent from the following description of examples read in conjunction with the accompanying drawings, in which:

[0023] Figure 1 An example of a data processing system is schematically illustrated.

[0024] Figure 2 An example of a processor including an interrupt detection circuit and an exception signaling circuit is illustrated.

[0025] Figure 3 A first example of a security state and exception level of a processing circuit is illustrated.

[0026] Figure 4Illustrates a second example of the secure state and exception level of the processing circuitry.

[0027] Figure 5 Illustrates an example of a set of registers that can be provided in a processor.

[0028] Figure 6A and Figure 6B Illustrates examples of the behavior of the processing circuitry when a second exception and a first exception are signaled, respectively.

[0029] Figure 7 Illustrates the process of signaling an exception to the processing circuitry.

[0030] Figure 8 Illustrates an example of processing that can be performed by software executing at EL3.

[0031] Figure 9 Illustrates an example of processing that can be performed by software in an active execution environment in response to a second exception.

[0032] As introduced above, in a data processing system, an interruption may occur that requires handling by a processing circuitry system operating in a target execution environment. The processing circuitry can operate in multiple different execution environments, and when an interruption is received, the processing circuitry can operate in an active execution environment different from the target execution environment. Therefore, to handle the interruption, the processing circuitry may need to switch from the active execution environment to the target execution environment. Switching quickly to the target execution environment upon receiving an exception means that critical interruptions can be handled in a timely manner. However, immediately switching to the target execution environment may cause the processing in the active execution environment to be interrupted. In some cases, it may be desirable for the processing in the active execution environment to continue for a period of time, and the switch to the target execution environment to occur later. For example, the software in the active execution environment may be approaching a processing point where significantly fewer states need to be saved when the interruption is taken, and thus is approaching a processing point that is more suitable for handling the interruption than at the current processing point. Therefore, in some cases, it may be useful to give the software in the active execution environment the flexibility to decide when to handle the interruption.

[0033] A device can be provided that includes an interruption detection circuit for detecting that an interruption to be handled by a processing circuitry in a target execution environment is pending, and the device includes an exception signaling circuit for selectively signaling an exception to the processing circuitry in response to an accepted interruption.

[0034] In one example, a given exception can be used to signal to the processing circuitry all interruptions detected by the interruption detection circuit that are to be handled in a target execution environment other than the active execution environment.

[0035] In one example, in response to the given exception, the processing circuitry may be configured to switch from the active execution environment to handle the interrupt in a target execution environment, regardless of the processing in the active execution environment. This means that all interrupts are handled promptly, but whenever an interrupt is received that needs to be handled in an execution environment other than the active execution environment, this involves pre-empting the execution in the active execution environment.

[0036] In an alternative example, in response to the given exception, the processing circuitry may be configured to allow the software operating in the active execution environment to decide 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 pre-emption of the processing in the active execution environment. However, waiting for the active execution environment to switch to the target execution environment may mean that the handling of critical interrupts that need to be handled in an execution environment other than the current execution environment is delayed.

[0037] In one example technique, the processing circuitry may be configured to have settings for the following operations: select one of the two options described above and thus select whether to handle the interrupt signalled by the given exception by always pre-empting the execution in the active execution environment or by always allowing the software in the active execution environment to schedule the handling of the interrupt. This provides some control over whether interrupts are generally allowed to pre-empt the execution in the active execution environment at a given time. However, in this example, the different methods for handling interrupts are controlled by software that changes the control settings. Since the time at which an interrupt occurs cannot be controlled by software (interrupts are typically caused by external events), this would not be a practical technique for controlling whether a given interrupt can pre-empt the processing in the active execution environment at a given time.

[0038] However, it has been recognized that some interrupts that need to be handled in an execution environment other than the active execution environment may be more urgent than others. Some interrupts may be considered critical, for which prompt handling is important, while other interrupts may be considered less critical. It may be desirable to pre-empt the processing in the active execution environment to switch to the target execution environment to handle the interrupt in response to a critical interrupt and to allow the processing circuitry to decide when to switch to the target execution environment for less critical interrupts. The all-or-nothing approach described above fails to reflect that at any given time, it may be desirable to pre-empt the processing in the active execution environment in response to some interrupts that need to be handled in different execution environments rather than in response to other interrupts that need to be handled in different execution environments.

[0039] Interrupts can be associated with interrupt priorities. Interrupt priorities can be used, for example, to determine the order in which pending interrupts to be handled in the same execution environment are to be handled. Interrupt priorities can also be used to mask certain interrupts with low priority such that those interrupts are not accepted and thus not signaled to the processing circuitry. The present inventors have recognized that interrupt priorities can be used as a mechanism for identifying which interrupts to be handled in an execution environment other than the active execution environment are critical and which are less critical.

[0040] Accordingly, in some examples, the exception signaling circuitry is configured to signal a first exception or a second exception based on an interrupt priority associated with a first interrupt. In response to determining that the interrupt priority exceeds a threshold priority, the first exception can be 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 executed. In response to determining that the interrupt priority does not exceed the threshold priority, the second exception can be signaled without preemptively triggering the given action. In this way, some interrupts may cause the given action to be preemptively triggered, while other interrupts may not cause the given action to be preemptively triggered without any switching between different control settings. The given action can preempt processing in the active execution environment. Thus, the technique provides greater control over preemption of processing in the active execution environment in response to interrupts to be handled in a target execution environment other than the active execution environment.

[0041] The exception signaling circuitry can perform selective signaling of the first exception or the second exception in response to determining that the first interrupt meets at least one criterion. The at least one criterion includes determining that the target execution environment is an execution environment other than the active execution environment of the processing circuitry. For interrupts to be handled in the active execution environment, preemption of processing may not be needed because there may be no need to switch to another execution environment to handle the interrupt. The at least one criterion can also include additional criteria. For example, the at least one criterion can include determining that the first interrupt belongs to at least one interrupt category. The at least one criterion can include determining that the first interrupt will not be handled at an exception level responsible for switching between security states. As discussed below, the at least one criterion can also include determining that the target execution environment in which the first interrupt will be handled is a preemptive execution environment. In addition to the criterion that the target execution environment is an execution environment other than the active execution environment, different embodiments can have different options for applying one or more additional criteria.

[0042] There is no particular limitation on the determination of the interrupt priority exceeding the threshold. The interrupt priority and the threshold priority can be represented by numerical values, and this determination can involve the comparison of numerical values. It should be understood that a higher priority can be represented by a higher or lower numerical value, and thus in different examples, when the interrupt priority takes a higher numerical value or a lower numerical value, this interrupt priority can exceed the threshold priority. When the interrupt priority is equal to the threshold priority, this can be interpreted as exceeding or not exceeding the threshold priority based on the specific implementation.

[0043] In some examples, the execution environment is not particularly limited. The execution environment can include, for example, virtual machines, processing modes, etc. In some examples, the processing circuit can operate in one of two or more security states. The security states can be associated with different physical address spaces. Processes executed in certain security states may not be able to access data or instructions associated with certain other security states. In some examples, the target execution environment and the active execution environment include different security states. Therefore, the first interrupt may need to be handled in a security state other than the active security state.

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

[0045] The processing circuit can also operate at one of two or more exception levels. Each exception level can be associated with one of the security states. Different exception levels can be associated with different privileges (such as register access permissions). The exception levels can be hierarchical, where a higher-privilege exception level has greater privileges than a lower-privilege exception level. The mechanism for switching between exception levels can include signaling an exception to the processing circuit and performing an exception return.

[0046] In some examples, a given action includes causing the processing circuit to switch to the exception level responsible for switching between security states. Therefore, in response to the first exception, the processing circuit can be caused to preemptively switch to the exception level responsible for switching between security states, and in response to the second exception, the processing circuit may not be caused to preemptively switch to this exception level. By preemptively switching the processing circuit to the exception level responsible for switching between security states, the first exception can enable the software to switch the processing circuit to the target security state, thus disposing of the first interrupt faster than in the case where the current software being executed at the time of the first exception has the opportunity to decide to defer the switch to the exception level responsible for switching between security states.

[0047] In response to determining that the interrupt priority does not exceed a threshold priority, a second exception may be signaled without preemptively triggering a given action. However, although the given action is not preemptively triggered, it may be desirable to handle the first interrupt at some point. Additionally, sometimes it may be desirable that, in certain cases, pending interrupts to be handled in the active execution environment can be handled before the first interrupt. In some examples, this can be achieved if the second exception indicates to the processing circuitry that a second interrupt is pending, where the second interrupt can be handled by the processing circuitry in the active execution environment. Since the second interrupt can be handled in the active execution environment, the software in the active execution environment may be able to schedule the handling of the second interrupt in an appropriate manner. The second interrupt can be a doorbell interrupt that indicates to the processing circuitry that the first interrupt is pending and is to be handled in a different execution environment. Thus, the software handling the second interrupt in the active execution environment can be notified of the pending first interrupt to be handled in a different execution environment, and the software can autonomously trigger the given action such that the interrupt can be handled. In this case, when the given action is triggered, the operation is autonomously done by the software rather than being preemptively done by the hardware as in the case of the first exception (and thus non-autonomous from the perspective of the software that was executing when the first exception was signaled).

[0048] The second interrupt can be configured like any other interrupt in the active execution environment. For example, the second interrupt can be associated with a second interrupt priority defined in the interrupt priority space of the active execution environment. Thus, the software in the active execution environment can schedule the handling of the second interrupt relative to any other interrupt to be handled in the active execution environment based on the second interrupt priority. This can be contrasted with the first exception that preempts the processing of the active execution environment without software control, and thus such preemption can occur even if there are high-priority interrupts pending in the active execution environment. The second interrupt priority can be independent of the interrupt priority associated with the first interrupt. Thus, the priority of the doorbell interrupt can be independent of the priority of the first interrupt, providing greater control over the scheduling and handling of the doorbell interrupt in the active execution environment.

[0049] Different execution environments can have different levels of security and privacy. Thus, it may not be desirable to allow the processing in one execution environment to know about interrupts raised in a different execution environment. Thus, in some examples, the exception signaling circuitry is configured to signal the second exception without exposing information about the cause of the first interrupt to the code executed by the processing circuitry in the active execution environment. Thus, while the second exception can indicate that an interrupt is pending and is to be handled in a different execution environment, the active execution environment may not have information about the cause of the interrupt. This ensures that any potential secret information about the execution of higher-privilege code in different execution environments is not exposed to lower-privilege code in the active execution environment.

[0050] In some examples (e.g., those that support more than two execution environments), the doorbell interrupt can indicate which execution environment is the target execution environment of the pending first interrupt. This can provide some information about the importance of the first interrupt to the software in the active execution environment that is responsible for deciding whether to trigger a given action. Thus, the software in the active execution environment can make a more informed choice about when to trigger a given action to allow the first interrupt to be handled (and, in examples where the software at a particular exception level is responsible for switching the security state, this information may be useful for that software to decide which execution environment to switch to). Although the target execution environment is indicated, the second interrupt may still not reveal the cause of the first interrupt, and thus the security of other execution environments can still be ensured. While the second interrupt can indicate the target execution environment of the first interrupt in different ways, one approach can be to assign different interrupt numbers to multiple variants of the second interrupt corresponding to different execution environments, such that when the first interrupt occurs, the relevant one of the variants of the second interrupt corresponding to the target execution environment of the first interrupt is selected, and the interrupt number of this second interrupt will identify to the software which execution environment is the target execution environment of the first interrupt.

[0051] As mentioned above, when it is determined that the first interrupt meets at least one criterion (including that the target execution environment is not the active execution environment), selective signaling of the first and second exceptions can be performed. However, at least one additional criterion can also be applied.

[0052] In some examples, at least one criterion also includes determining that the target execution environment is a preemptive execution environment. Thus, in some examples, the selective signaling of the first and second exceptions occurs only for interrupts to be handled in a preemptive execution environment. When the target execution environment is not a preemptive execution environment, interrupts to be handled in a target execution environment other than the active execution environment can be signaled in a different way. Specifically, in some examples, interrupts to be handled in an execution environment other than a preemptive execution environment may not be able to preempt the processing in the active execution environment, and thus once the software in the active execution environment has voluntarily triggered a given action to yield the processing time on the processing circuit so that another execution environment can handle the interrupt, these interrupts can be handled. It may be desirable to prevent certain execution environments from being able to preempt the processing in a given execution environment to reduce the performance impact on the processing in the active execution environment.

[0053] In some examples, at least one preemptive execution environment can be hardwired or set in a register that cannot be modified by software. This can provide a simple and secure way to identify whether an execution environment is a preemptive execution environment. However, software developers may wish to change which execution environments can preempt execution in an active execution environment at a given time. Thus, the exception signaling circuit can 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 can be stored in a single configuration register, or can be distributed among two or more registers, with each register storing a portion of the information.

[0054] In some examples, the preemptive execution environment indication information can indicate that several execution environments are preemptive execution environments. In this case, when the processing in the 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 can be sorted such that interrupts to be handled in a lower-ranked execution environment are handled before interrupts to be handled in a higher-ranked execution environment. The sorting can be implicit in the design of the hardware of the processing system, or in some examples can be configurable based on software-writable control information indicated in a register.

[0055] However, in some examples, the encoding of the preemptive execution environment indication information indicates that one execution environment is a preemptive execution environment at a given time. This can provide a simpler mechanism with only a single preemptive execution environment, thus avoiding conflicts between preemptive execution environments.

[0056] There are several ways to determine a threshold priority. However, in some examples, the threshold priority is indicated by threshold priority information stored in a software-writable register. Being software-writable enables the threshold priority to be set and modified by software during execution. This can be useful because it may be desirable to allow software to set different threshold priorities at different points in a program.

[0057] It may also be desirable to set different threshold priorities for different execution environments. Thus, in some examples, the encoding of the threshold priority information enables the 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 can be associated with independent threshold priority values such that a change between execution environments can also change the threshold priority used to preempt execution in that execution environment. For example, the threshold priority can be stored in a banked register, where each execution environment accesses a different version of the register.

[0058] In some examples, the software may not be given full control to modify the threshold. For example, the software in an active execution environment may set a relatively high threshold to prevent itself from being preempted, but this may risk delaying critical interrupts. Thus, in some examples, control information defines whether a given execution environment is allowed to modify the threshold priority information for a given target execution environment. For example, this can prevent certain less trusted execution environments from being allowed to modify the threshold priority information.

[0059] Since the control information determines whether an execution environment can modify 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 software executing at a given exception level is not allowed to write to the control register when 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 can be a high (higher privilege) exception level, typically the highest exception level, and can thus be trusted to set the control information.

[0060] In some examples, the first exception and the second exception can be signaled to the processing circuit in the same way, such as using the same input pin to the processing circuit. Then, a second mechanism (such as an exception type value indicating whether the signaled exception is the first exception or the second exception) can be used to distinguish between the first exception and the 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 input pin and the second input pin may already be provided (e.g., for a "fast" exception and a "normal" exception, where the "fast" exception has priority over the "normal" exception), and thus the technology can be implemented at a reduced hardware cost because no new input pins need to be provided (the first exception can reuse the "fast" exception pin, and the second exception can reuse the "normal" exception pin).

[0061] In some examples, when it is determined that a first exception is to be signaled, the exception signaling circuitry is configured to signal the first exception regardless of the current priority level of the processing being performed by the processing circuitry. For example, if the processing circuitry operating in an active execution environment is handling an interrupt with a given priority, the first exception will preemptively trigger a given action even if the given priority is higher than the interrupt priority associated with the first interrupt. This means that critical interrupts can be quickly handled in the target execution environment regardless of the current processing in the active execution environment. This also means that there is no comparison between the priority of the interrupts to be handled in the target execution environment and the priority of the interrupts in the active execution environment, such that these priorities can be set completely independently of each other. Thus, the interrupt priority space that defines the interrupt priority associated with the first interrupt to be handled in the target execution environment (which is the interrupt priority space associated with the target execution environment) can be considered independent of the interrupt priority space associated with another execution environment. Therefore, when software developers decide how to set interrupt priorities, they do not need to consider software that may be executing in different execution environments (which simplifies and reduces the cost of software development as it reduces the need for cooperation between software provided by different software developers), and additionally, they can access a wider portion of the interrupt priority space without having to try to ensure that the priorities exceed the pending priorities in another execution environment.

[0062] As introduced above, the transition from an active security state to a target security state can be performed by software executing at a particular exception level. To enable the software at that exception level to know which security state to transition to in order to handle an interrupt, some examples can provide a pending interrupt configuration register that can be accessed by software operating at the exception level responsible for transitioning between security states, where the pending interrupt configuration register is configured to store pending interrupt information indicating one or more execution environments having pending interrupts. The pending interrupt configuration register can be provided as a system register rather than a location in memory, thereby enabling the exception level responsible for transitioning between security states to quickly determine which security state to transition to. The register can provide a flag per execution environment to indicate the execution environment having a pending interrupt. The pending interrupt configuration register is separate from any more detailed tracking of pending interrupts (such as a pending interrupt structure in memory that shows a pending interrupt queue). For example, the pending interrupt configuration register may not track the specific details of the pending interrupts, such as the interrupt number, but may simply provide a summary of whether there are any pending interrupts for a given execution environment, such that the security state transition software can quickly identify which execution environment to transition to.

[0063] Figure 1Schematically illustrates an example 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, but it should be understood that the number of processors can vary. The processors communicate with each other and with a shared memory 8 via a cache coherent interconnect 6 that supports a coherence protocol to maintain cache coherence of the data cached in the private cache of each processor 4.

[0064] An interrupt controller 10 is provided to receive incoming interrupt signals from the connected peripheral devices 14 and forward the incoming interrupt signals to the processors 4. In some cases, a processor also generates interrupts for other processors (referred to as inter-processor interrupts (IPIs)), so the processor 4 itself can also act as an interrupt source. The peripheral device can signal the interrupt to the interrupt controller 10 via a dedicated wire 11 or by reusing an existing I / O (input / output) mechanism 12 (such as a memory-mapped I / O write operation). The latter is commonly referred to as message-signaled interrupt (MSI).

[0065] Therefore, the interrupt controller needs to be able to communicate with the processors to which it can forward interrupts. As Figure 1 shown, one way to achieve this is to use a dedicated communication protocol and an interrupt communication bus 16 in the system, which is specifically designed to carry interrupt signals from the interrupt controller 10 to the processors 4. In a different approach, the existing cache coherence mechanism supported by the cache coherent interconnect 6 is utilized to distribute interrupts from the interrupt controller 10 to the processors 4, and an interrupt configuration and status are represented by a memory-based table shared by the processors and the interrupt controller. In both examples, the processing element 4 can be made aware that an interrupt event has occurred and software for handling the interrupt can be executed.

[0066] Figure 2 Illustrates Figure 1 an example of one of the processors 4 shown. The processor 4 includes processing circuitry 18 for performing processing operations. The processing circuitry 18 can operate at one of multiple exception levels and in one of multiple security states, as Figure 3 and Figure 4 illustrated.

[0067] Figure 3 Illustrates an example of processing that can be performed by the processing circuitry 18. A hypervisor 30 can manage multiple virtual machines (VMs, also referred to as guest operating systems or guest OSs) 32. Figure 3A VM 32 is shown, but it should be understood that the hypervisor can manage several VMs. Each VM 32 can manage one or more application programs 34. For example, the hypervisor 30 can control which regions of the address space are allocated to each virtual machine 32 and control the switching between virtual machines 32. Similarly, each VM 32 can control which regions of the address space are allocated to each application program 34 executing under that VM 32 and can control the switching between application programs as needed.

[0068] As Figure 3 shown, each process is associated with a given privilege level EL0, EL1, EL2, EL3. In this example, higher-numbered privilege levels have higher privileges than lower-numbered privilege levels, but in other examples, they can be numbered the other way around. In this example, the application program 34 executes at privilege level EL0, the VM 32 executes at privilege level EL1, and the hypervisor 30 executes at privilege level EL2. Generally, a process executing at a higher privilege level has permissions that are not available to a process executing at a lower privilege level.

[0069] As Figure 3 shown, the hypervisor 30, VM 32, and application program 34 can operate in a Non-secure security state. In addition, the device can support a Secure security state isolated from the Non-secure security state. There can also be processes running in the Secure security state, such as a Trusted Operating System (OS) 38 and Trusted Services (application programs) 40 executing in the Secure security state under the control of the Trusted OS 38. The Secure security state and the Non-secure security state can be associated with different physical address spaces. The processing circuit 18 operating in the secure state may be able to access both the secure and non-secure physical address spaces and both the secure and non-secure system registers. In the non-secure state, the processing circuit 18 may only be able to access the non-secure physical address space and non-secure system registers that allow non-secure access. The Trusted OS 38 and Trusted Application 40 execute at privilege levels EL1 and EL0, respectively. A Secure Partition Manager 36 can be provided at 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 the transition between the Non-secure security state and the Secure security state. The firmware 42 can be considered part of the Secure security state. An example of a technique for partitioning the Non-secure security state and the Secure security state is technique, but other examples can also be used.

[0070] Figure 4 illustrates additional examples. In Figure 4In addition to the secure state and the non-secure state, a realm security state associated with another physical address space known as the realm physical address space is provided. Processes including the realm manager 44, the operating system 46, and the application 48 can run at exception levels EL2-EL0 in the realm security state in a manner similar to the non-secure state and the secure state. When in the realm security state, the processing circuitry 18 may be able to access the realm and non-secure physical address spaces, but not the secure physical address space. The secure state may not be able to access the realm physical address space. In Figure 4 the example of a root security state independent of the other security states may be provided at the EL3 exception level for switching between the secure states. In the root state, the processing circuitry 18 may be able to access all physical address spaces. An example of a technique for partitioning the non-secure state, the secure state, the realm security state, and the root security state is the realm management extension (

[0071] Return Figure 2 , the processor 4 further includes an interrupt detection circuit 20 and an exception signaling circuit 22. The interrupt detection circuit 20 and the exception signaling circuit 22 may be considered together as a CPU interface through which the interrupt controller 10 can communicate with the processing circuitry 18. The CPU 4 has a plurality of exception input pins for signaling different types of exceptions to the processing circuitry 18. Figure 2 Two exception input pins are shown: the fast interrupt (FIQ) pin 26 and the standard interrupt (IRQ) pin 28. An exception raised on the FIQ pin may have priority over an exception raised on the IRQ pin because the FIQ pin 26 can be used for interrupt types that require faster handling than the interrupt types on the IRQ pin 28. In some examples, these pins may not be the only exception input pins, and at least one additional pin may be provided for another class of exceptions.

[0072] 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., an indication received via the interconnect 6 may be a coherence snooping message indicating that a request to write to a given address assigned by the interrupt controller 10 for interrupt notification has been detected). The interrupt may need to be handled by software executing in a particular security state of the processing circuit 18. For example, the processing circuit 18 may operate in a non-secure state, and the interrupt controller 10 indicates an interrupt that needs to be handled in a secure state. Thus, it may be necessary to switch from the active security state to a different security state to handle the interrupt.

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

[0074] In one example, in response to signaling of a given exception indicating that an interrupt has been received that is to be handled in a different security state, the processing circuit 18 may always switch to the EL3 exception level that is responsible for switching between security states. It should be understood that EL3 is used to mean the exception level that is responsible for switching between security states. This exception level is typically the highest privileged exception level, but may not necessarily be EL3 in some particular implementations. Once the processing has switched to EL3, the software executing at EL3 may switch to the target security state to handle the interrupt. While always switching to EL3 in response to an interrupt that is to be handled in a different security state may allow for rapid handling of the interrupt, this technique may interrupt the processing in the active security state because the transition to EL3 will occur regardless of the processing in the active security state - sometimes, it may be less efficient to service the interrupt at the current processing moment than to advance a little further before servicing the interrupt at a point where the current processing in the active security state may require saving less architectural state to memory.

[0075] In an alternative example, in response to signaling of a given exception, processing circuitry 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 voluntarily enter a higher exception level in response to the exception. For example, if operating at the EL0 exception level, a given exception may cause processing circuitry 18 to transition to the EL1 exception level. Software at the higher exception level may then determine how to handle the interrupt and may cause the processing to switch to EL3 such that the security state may be changed, or alternatively, may decide to return to the lower exception level to complete processing before switching to EL3 and later handling the interrupt. Thus, by not immediately switching to EL3 upon receipt of an interrupt to be handled in a different security state, processing in the active security state may experience fewer interruptions. However, this enables software in the active execution environment to control the timing of interrupt handling, which may result in the handling of critical interrupts being delayed.

[0076] In some examples, values stored in registers may control how processing circuitry 18 responds to a given exception, either by switching to EL3 or by allowing software to decide how to handle the exception. For example, the register may be one of the registers 24 associated with processing circuitry 18. However, even though this technique may allow software designers more design freedom in interrupt handling, at any given time, the technique is limited to always preemptively switching to EL3 in response to an interrupt to be handled in another security state (regardless of the nature of the interrupt), or always allowing software to decide when to switch to EL3 (regardless of the nature of the interrupt). It is not practical to switch the value stored in a register before receipt of a particular interrupt that requires either preemptive or non-preemptive handling because the time at which the interrupt will be received is unknown. The reasons why an interrupt that needs to be handled in another security state may be received are diverse. Some interrupts require urgent handling, which would warrant preempting execution in the active security state, while other interrupts may be less critical, in which case it may be more 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 a target security state other than the active security state may be signaled to processing circuitry 18 in different ways.

[0077] Figure 5 An example of the registers 24 that may be provided in the processor 4 is illustrated. For example, the registers 24 may be accessible by the exception signaling circuitry 22 and the processing circuitry 18. For Figure 5The suffix_ELx shown in the register indicates the minimum privilege exception level that permits writing to the register—for example, ICC_CTLR_EL1 can thus be written by software executing at EL1, EL2, or EL3, while ICC_CTLR_EL3 can be written by software at EL3. It should be understood that the indicated register names are arbitrary, and the same control information represented in these registers could be represented in other ways (e.g., in other examples, the information described in different registers in Figure 5 could be stored in the same register).

[0078] Register 24 includes at least one ICC_CTLR_EL1 register. The ICC_CTLR_EL1 register stores a priority threshold.

[0079] When interrupt controller 10 signals an interrupt event to processor 4, the interrupt is associated with an interrupt priority. Interrupt priorities can be used in some systems to select the order in which interrupts are handled. For example, each pending interrupt can be associated with an interrupt priority, and the exception signaling circuit can determine which pending interrupt to signal to the processing circuit based on which pending interrupt has the highest priority. Priorities can also be used to mask certain interrupts. When an interrupt has a priority lower than a masking priority (which can be configured by software setting a masking threshold level), it can be determined that the interrupt is not accepted, and the exception signaling circuit can refrain from signaling an exception to the processing circuit in response to the unaccepted interrupt.

[0080] Upon receiving an interrupt to be handled in a security state other than the active security state, the exception signaling circuit can compare the interrupt priority associated with the interrupt to the priority threshold stored in the ICC_CTLR_EL1 register. In some scenarios, a lower numerical value can indicate a higher priority, and if the value of the interrupt priority is numerically less than the priority threshold, the interrupt priority can thus exceed the priority threshold. If the interrupt priority is equal to or greater than the priority threshold, the interrupt priority does not exceed the threshold. In other examples, a higher numerical value of the interrupt priority can indicate a higher (more important) priority, and thus if the value of the interrupt priority is numerically higher than the priority threshold, the interrupt priority can exceed the priority threshold. Either way, depending on whether the interrupt priority exceeds the threshold (plus additional conditions discussed below), the exception signaling circuit can signal a first exception or a second exception.

[0081] A first exception can be signaled to the processing circuitry 18 on the FIQ input pin. A second exception can be signaled on the IRQ input pin. Thus, the present technique can signal two different exceptions based on a comparison between the priority of an interrupt and a threshold, rather than using a single exception to signal all received interrupts to be handled in a secure state other than the active secure state. The first exception signaled on the FIQ pin can cause the processing circuitry 18 to preemptively switch to the EL3 exception level without software control, which can subsequently allow software at EL3 to switch to the target secure 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 may instead allow software operating in the active secure state to decide when to switch to EL3 to allow the interrupt to be handled. Thus, signaling an exception to the processing circuitry can vary based on the priority of the interrupt, which allows different interrupts to be handled in different ways, thereby reducing the impact on software in the active secure state, but ensuring that critical interrupts for the target secure state can be serviced promptly.

[0082] As Figure 5 indicated, in addition to the register 50, there may be several versions of the ICC_CTLR_EL1 register. These registers may include banked copies 52, 54 of the ICC_CTLR_EL1 register, each of these storage copies being associated with a secure state. Although three banked registers are shown, it should be understood that this can vary freely based on the specific implementation. Thus, different versions of the register can be accessed based on the active secure state of the processing circuitry 18. Since the priority threshold is based on the value in the register, the priority threshold may vary depending on the secure state. The value in the register ICC_CTLR_EL1 can be written by software at EL1, EL2, or EL3 to allow the software designer to change what level of criticality an interrupt needs to reach before preempting execution in the active secure state. In some specific implementations, there may be permissions that can only be accessed by EL3, which determine how software can modify the priority threshold.

[0083] In addition to the threshold priority comparison described above, the exception signaling circuitry can also determine whether an exception is to be handled in a preemptive interrupt domain. This preemptive interrupt domain can be one of the secure states. For example, a register ICC_CTLR_EL3 56 can be provided, which indicates which of the secure states is the preemptive interrupt domain. For example, two bits can be used to select Figure 4 one of the non-secure secure state, secure secure state, and domain secure state as indicated. Writes to the register ICC_CTLR_EL3 can be limited to software executing in EL3.

[0084] In some examples, two or more security states may be considered pre-emptive interrupt domains. In some examples, each security state may be considered a pre-emptive interrupt domain. However, in some examples, the architecture complexity may be reduced by supporting only a single pre-emptive interrupt domain at a time, which may be selected by EL3 software that sets the value in ICC_CTLR_EL3.

[0085] When the target security state is a pre-emptive interrupt domain, the exception signalling circuit may signal the first exception only on the FIQ pin. Thus, in response to an interrupt to be handled in the pre-emptive interrupt domain, the handler may be caused to switch pre-emptively to EL3 (without being controlled by software executing at EL0, EL1 or EL2 in the active security state). This provides a second mechanism by which an interrupt may be evaluated to determine whether to signal the first exception or the second exception. Thus, it may be evaluated whether the target interrupt domain is a pre-emptive interrupt domain and whether the interrupt priority exceeds a priority threshold. By performing two comparisons, the software designer obtains greater control over how to signal a given interrupt to the processing circuitry, such that critical interrupts may be handled promptly while less critical interrupts may have a reduced impact on processing.

[0086] The register further includes a register ICC_DOMHPPIR_EL3 58 that can be accessed by a handler at the EL3 exception level. Once the handler has switched to EL3, due to a hardware switch in response to a FIQ exception or due to software concession control after an IRQ exception, the software at EL3 needs to determine which secure state to switch to so that the interrupt can be disposed of. 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 indicating whether there is a pending interrupt to be disposed of in the preemptive interrupt domain. The preemptive secure state can be determined from the ICC_CTLR_EL3 register, and thus when this bit indicates a pending interrupt for the preemptive interrupt domain, the software at EL3 can switch to this preemptive secure state to dispose of the interrupt. In other examples, there can be more than one interrupt domain, and thus there can be bits associated with each of the domain secure state, the secure secure state, and the non-secure secure state, where the bit indicates the presence of a pending interrupt for that secure state in one state and indicates the absence of a pending interrupt for that secure state in another state. In some examples with more than one preemptive interrupt domain, the secure states can be sorted to determine the order in which EL3 should dispose of interrupts that are pending simultaneously in more than one preemptive secure state. Regardless of the specific format of the pending interrupt information in ICC_DOMHPPIR_EL3, when a pending interrupt is detected for a given interrupt domain / secure state, this information can be set by the interrupt detection circuit 20 or the exception signaling circuit 22 (in hardware), and when there are no longer any pending interrupts for that domain / secure state, this information can be cleared by the hardware. This information is separate from any tracking of the pending interrupt queue using the structure maintained by the interrupt controller 10. ICC_DOMHPPIR_EL3 can be regarded as a summary of such a more detailed pending interrupt queue (which can track the specific interrupt numbers of the pending interrupts), because ICC_DOMHPPIR_EL3 is a summary of whether there are any pending interrupts for a given domain / secure state, and this summary can be accessed more quickly by the EL3 software compared to the more detailed interrupt tracking structure maintained by the interrupt controller 10.

[0087] Figure 6A An example illustrating the behavior of the processing circuit when signaling a second exception.

[0088] At step 600, the processing circuit 18 operates in an active secure state. Although FIG. 6 shows an application being executed at EL0, the processing circuit 18 can also execute, for example, at EL1 or EL2.

[0089] At step 602, signal a second exception to processing circuitry 18. This may involve signaling the exception on an IRQ input pin. The second exception may be signaled in response to the interrupt detection circuitry detecting a first interrupt, where the first interrupt is to be handled in a target security state different from the active security state. The second exception may be signaled when it is determined that the target security state is a security state other than a preemptive security state based on an indication of one or more preemptive security states 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 a threshold priority indicated in the active ICC_CTLR_EL1 register.

[0090] At step 604, in response to the second exception, the processing circuitry does not switch to EL3. The processing circuitry remains within the active security state and may switch to an exception level (e.g., EL1 or EL2) to handle the exception. The second exception indicates a second interrupt rather than presenting the first interrupt to software in the active security state. Unlike the first interrupt, the second interrupt may be handled in the active security state, and thus software in the active security state can schedule the handling of the second interrupt like all other interrupts to be 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 relative to other interrupts targeting the active security state. The second interrupt indicates to software in the active security state that an interrupt is pending and is to be handled in a different security state. However, the second interrupt does not expose information about the first interrupt to software in the active security state. This may be important for avoiding allowing secrets associated with one security state to be exposed to software in a different security state.

[0091] At step 606, exception handling software in the active security state may determine to return to processing in EL0 within the active security state and decide to handle the interrupt later, or may voluntarily yield processing to EL3 to allow the first interrupt to be handled.

[0092] At step 608, when it is determined to yield to EL3, software at EL3 uses the ICC_DOMHPPIR_EL3 register to determine whether there are any pending interrupts to be handled in the preemptive security state. At step 610, when it is determined that there are pending interrupts for the preemptive interrupt domain, the software then switches to (only or highest priority) the preemptive security state to handle the first interrupt.

[0093] Figure 6BAn example illustrating the behavior of the processing circuit when signaling a first exception is shown.

[0094] At step 612, the processing circuit 18 operates in the active secure state, as Figure 6A in step 600 of.

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

[0096] At step 616, in response to the first exception, the processing circuit preemptively switches to EL3 without being controlled by the software executing in the active secure state. This preempts the processing in the active secure state.

[0097] At step 618, the software at EL3 uses the ICC_DOMHPPIR_EL3 register to switch to the target secure state, as in step 608, to allow the first interrupt to be handled. By preemptively switching to EL3, the processing circuit ensures that the first interrupt is handled quickly, bypassing any decisions of the software in the active secure state (including the possible case of delaying the concession to EL3 when the processing is complete). Then, in step 620, the processing continues at the exception level in the target secure state to handle the interrupt. Comparing Figure 6A and Figure 6B the processes illustrated in, it will be seen that when signaling a FIQ exception rather than an IRQ exception, the interrupt can be handled more quickly because this bypasses the software in EL1 / EL2 of the active secure state and the software at EL1 / EL2 cannot choose whether to make a concession to EL3. Therefore, the first exception may be more suitable for interrupts that require quick handling.

[0098] Figure 7 An example of the process of signaling an exception to the processing circuit 18 is shown. For example, this process may be performed by the interrupt detection circuit 20 and the exception signaling circuit 22.

[0099] At step 700, a first interrupt is detected. It is determined that the first interrupt is to be handled in a target secure state.

[0100] At steps 702 to 710, it is determined whether the first interrupt meets at least one criterion.

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

[0102] If it is determined that the first interrupt will not be handled at EL3, then at step 706, it is determined whether the target security state is the active security state. The active security state may be indicated in the system registers. If the target security state is the active security state and the interrupt is not targeted at EL3, then there is no need to switch to a different security state to handle the first interrupt. Thus, at step 708, the exception signaling circuitry signals an IRQ exception on the IRQ input pin 28. The IRQ exception does not cause the processing circuitry to switch to EL3. Instead, the IRQ may cause the processing to switch to a higher exception level within the same security state to handle the interrupt. Then, software control within the active security state handles the interrupt.

[0103] If it is determined that the target security state is different from the active security state, then at 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 the EL3 configurable control information in the register ICC_CTLR_EL3. A preemptive security state is a security state that allows interrupts (other than those to be handled at EL3) to preempt processing in the active security state. If the target security state is not a preemptive security state, then the FIQ exception is not signaled because interrupts are not allowed to preempt execution in the active security state. Thus, at step 712, an IRQ exception is signaled. This IRQ exception may signal a second interrupt that indicates to the software in the active security state that the first interrupt is pending and is to be handled in a security state other than the active security state.

[0104] When it is determined that the first interrupt meets at least one criterion, then at step 714, it is determined whether the interrupt priority associated with the first interrupt exceeds a threshold priority. The threshold priority for the active security state may be determined from one of the banked ICC_CTLR_EL1 registers 50, 52, 54 associated with the target security state of the first interrupt. The interrupt priority associated with the first interrupt may be signaled from the interrupt controller 10 to the processor 4.

[0105] When it is determined that the interrupt priority does not exceed the threshold priority, it is determined that the priority of the first interrupt is too low to preempt the processing in the active secure state. Therefore, instead of signaling the FIQ exception that would preempt the processing, at step 720, an IRQ exception is signaled to the processing circuitry 18, as in step 712. This enables the software in the active secure state to know that the interrupt is pending for different secure states and allows the software to yield to EL3 to handle the interrupt.

[0106] When it is determined that the interrupt priority does exceed the threshold, the first interrupt is considered to have a high enough priority such that the processing in the active secure state can be preempted to handle the interrupt. Therefore, at step 716, the FIQ exception is signaled. At step 718, the FIQ exception causes the processing circuitry 18 to switch to the EL3 exception level without being controlled by the software in the active secure state. This switch occurs regardless of the processing being performed in the active secure state. The switch to EL3 enables the software at EL3 to switch to the target secure state to handle the first interrupt.

[0107] Thus, by differentiating interrupts based on the target secure state and the interrupt priority, the present technique achieves greater control over whether a given interrupt should preempt processing at a given time. This provides a balance between quickly handling important interrupts and minimizing the disruption to ongoing processing.

[0108] It should be understood that Figure 7 certain of the steps shown may occur in a different order and may occur in parallel.

[0109] Figure 8 An example of processing that may be performed by software executing at EL3 is illustrated. At step 800, the processing switches to EL3 in response to an exception. This switch may be due to an FIQ exception that is not under the control of the software or due to the software yielding control to EL3 (in response to an IRQ exception or otherwise).

[0110] At step 802, the software checks the pending interrupt configuration register ICC_DOMHPPIR_EL3 to determine which secure states have pending interrupts.

[0111] At step 804, the EL3 software disposes of any pending interrupts that need to be disposed of at EL3. When there are no pending interrupts for EL3, the EL3 software determines whether the preemptive security state has a pending interrupt. If so, and if there is only one preemptive security state, it is determined to switch to the preemptive security state so that the software in that security state can dispose of the pending interrupt. If there are more than one preemptive security states, the software at EL3 determines which is the highest priority preemptive security state with a pending interrupt. If there is no preemptive security state with a pending interrupt, the EL3 software determines whether there is any other security state with a pending interrupt. In any case, at step 806, once a security state has been selected, the EL3 software causes the processing circuitry to switch to the selected security state, and then at step 808, the software yields processing to the exception level within that security state to dispose of the interrupt.

[0112] Figure 9 An example of processing that can be performed by software in an active execution environment in response to an IRQ exception is illustrated. At step 900, an IRQ exception is received on the IRQ input pin. The IRQ exception can be signaled as Figure 7 illustrated.

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

[0114] At step 904, the software notices a pending doorbell interrupt signaled by a second exception. The doorbell interrupt can be disposed of in the active security state and indicates that the interrupt is pending and awaits disposal in a different security state. The software at EL1 / EL2 schedules the disposal of the doorbell interrupt like any other interrupt to be disposed of in the active security state. The doorbell interrupt is associated with a priority for scheduling interrupts in the active security state. The doorbell interrupt can indicate which security state is the target security state for the pending interrupt (e.g., by selecting from a set of doorbell interrupts with different interrupt numbers, each interrupt number corresponding to one of the security states such that the interrupt number of the doorbell interrupt identifies which other security state is the target security state). In response to the doorbell interrupt, at step 906, the software determines whether to switch to EL3 so that the security state can be switched to dispose of the interrupt, or to continue the processing in the active security state. If it is determined to switch to EL3 at that time, at step 908, the software voluntarily yields processing to EL3, such as by raising a hypervisor call targeted at EL3.

[0115] If it is determined not to switch to EL3 at that time, the processing in the active secure state continues. For example, the processing that occurred before the IRQ exception can be resumed. At step 910, the software in the active secure state determines to switch to EL3 at a later time to enable the handling of pending interrupts. Thus, at step 912, the software in the active secure state voluntarily yields the processing to EL3.

[0116] It will be seen that in response to the IRQ exception, the software in the active secure state controls the decision on when to handle the first interrupt.

[0117] The concepts described herein can be embodied in computer-readable code for fabricating an apparatus embodying the described concepts. For example, the computer-readable code can be used in one or more stages of the semiconductor design and fabrication process, including the electronic design automation (EDA) stage, to fabricate an integrated circuit including an apparatus embodying these concepts. The above computer-readable code can additionally or alternatively enable the definition, modeling, simulation, verification, and / or testing of an apparatus embodying the concepts described herein.

[0118] For example, the computer-readable code for fabricating an apparatus embodying the concepts described herein can be embodied in code represented in a hardware description language (HDL) that defines these concepts. For example, the code can define a register transfer level (RTL) abstraction of one or more logic circuits for defining an apparatus embodying these concepts. The code can define the HDL representation of one or more logic circuits of the apparatus in Verilog, SystemVerilog, Chisel, or VHDL (Very High-Speed Integrated Circuit Hardware Description Language), as well as intermediate representations such as FIRRTL. The computer-readable code can provide a definition of the concepts or other behavioral representations of the concepts embodied using a system-level modeling language (such as SystemC and SystemVerilog), and these behavioral representations can be interpreted by a computer to enable simulation, functional, and / or formal verification and testing of the concepts.

[0119] Additionally or alternatively, the computer-readable code may define a low-level description of an integrated circuit component embodying the concepts described herein, such as one or more netlists or integrated circuit layout definitions, including representations such as GDSII. One or more other computer-readable representations of the netlist or integrated circuit component may be generated by applying one or more logic synthesis processes to the RTL representation to generate a definition for fabricating a device embodying the invention. Alternatively or additionally, one or more logic synthesis processes may generate a bitstream to be loaded into a field-programmable gate array (FPGA) from the computer-readable code to configure the FPGA to embody the described concepts. The FPGA may be deployed for the purpose of validating and testing the concepts prior to fabricating an integrated circuit, or the FPGA may be deployed directly in a product.

[0120] The computer-readable code may include a mixture of code representations for fabricating a device, such as a mixture including one or more of an RTL representation, a netlist representation, or another computer-readable definition used in a semiconductor design and fabrication process for fabricating a device embodying the invention. Alternatively or additionally, the concepts may be defined in a combination of a computer-readable definition for fabricating a device in a semiconductor design and fabrication process and computer-readable code of instructions that will be executed by the defined device once fabricated.

[0121] Such computer-readable code may be provided on any known transient computer-readable medium (such as a wired or wireless transmission of the code over a network) or non-transient computer-readable medium such as a semiconductor, disk, or optical disc. An integrated circuit fabricated using the computer-readable code may include components such as one or more of the following: a central processing unit, a graphics processing unit, a neural processing unit, a digital signal processor, or other components that individually or jointly embody the concepts.

[0122] In this application, the phrase "configured to..." is used to mean that an element of a device has a configuration capable of performing the defined operation. In this context, "configuration" means an arrangement or manner of interconnection of hardware or software. For example, the 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 mean that the device element needs to be changed in any way to provide the defined operation.

[0123] Although the exemplary embodiments of the present invention have been described in detail herein with reference to the accompanying drawings, it should be understood that the present invention is not limited to those exact embodiments, and various changes and modifications may be made by those skilled in the art without departing from the scope of the present invention as defined by the appended claims.

Claims

1. A device, the device comprising: an interrupt detection circuit configured to detect a first interrupt to be handled by a processing circuit operating in a target execution environment; and an exception signaling circuit configured to signal an exception to the processing circuit in response to an accepted interrupt; wherein in response to determining that the first interrupt meets at least one criterion, the at least one criterion including determining that the target execution environment is an execution environment other than the active execution environment of the processing circuit, the exception signaling circuit is configured to: in response to determining that an interrupt priority associated with the first interrupt exceeds a threshold priority, signal a first exception to preemptively trigger a given action, wherein switching from the active execution environment to the target execution environment depends on the given action being executed; and in response to determining that the interrupt priority does not exceed the threshold priority, signal a second exception without preemptively triggering the given action.

2. The device according to claim 1, wherein the target execution environment and the active execution environment include different security states.

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

4. The device according to any one of the preceding claims, wherein the second exception indicates to the processing circuit that a second interrupt is pending, wherein the second interrupt can be handled by the processing circuit in the active execution environment.

5. The device according to claim 4, wherein the second interrupt is associated with a second interrupt priority defined in the interrupt priority space of the active execution environment, wherein the second interrupt priority is independent of the interrupt priority associated with the first interrupt.

6. The device according to any one of claims 4 and 5, wherein the exception signaling circuit is configured to signal the second exception without exposing information about the cause of the first interrupt to code executed by the processing circuit in the active execution environment.

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

8. The device according to any one of the preceding claims, wherein determining that the interrupt meets at least one criterion includes determining that the target execution environment is a preemptive execution environment.

9. The device according to claim 8, wherein the exception signaling circuit 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-writable configuration register.

10. The device according to claim 9, wherein the encoding of the preemptive execution environment indication information indicates that an execution environment is the preemptive execution environment at a given time.

11. The device according to any one of the preceding claims, wherein the threshold priority is indicated by threshold priority information stored in a software-writable register.

12. The apparatus according to claim 11, wherein the encoding of the threshold priority information enables indication of a threshold priority for a given execution environment, the threshold priority being separate from threshold priorities associated with at least one other execution environment.

13. The apparatus according to any one of claims 11 and 12, wherein the control information defines whether a given execution environment is permitted to modify the threshold priority information for a given target execution environment.

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

15. The apparatus according to any one of the preceding claims, 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, wherein the first input pin is separate from the second input pin.

16. The apparatus according to any one of the preceding claims, wherein in response to determining that the first interrupt meets the at least one criterion, the target execution environment is an execution environment other than the active execution environment of the processing circuit, and in response to determining that the interrupt priority exceeds the threshold priority, the exception signaling circuit is configured to signal the first exception regardless of the current priority level of the processing being performed by the processing circuit.

17. The apparatus according to any one of the preceding claims, wherein the value of the interrupt priority is defined within an interrupt priority space; and the interrupt priority space associated with the target execution environment is independent of the interrupt priority space associated with another execution environment.

18. The apparatus according to any one of the preceding claims, the apparatus including a pending interrupt configuration register accessible by software operating at an exception level responsible for switching between security states; wherein the pending interrupt configuration register is configured to store pending interrupt information indicative of one or more execution environments having pending interrupts.

19. A method, the method comprising: detecting a first interrupt to be handled by a processing circuit operating in a target execution environment; and signaling an exception to the processing circuit in response to the received interrupt; wherein the method comprises: in response to determining that the first interrupt meets at least one criterion, the at least one criterion including determining that the target execution environment is an execution environment other than the active execution environment of the processing circuit: 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; and signaling a second exception without preemptively triggering the given action in response to determining that the interrupt priority does not exceed the threshold priority.

20. A computer-readable medium for storing computer-readable code for manufacturing a device, the device comprising: an interrupt detection circuit configured to detect a first interrupt to be handled by a processing circuit operating in a target execution environment; and an exception signaling circuit configured to signal an exception to the processing circuit in response to an accepted interrupt; wherein in response to determining that the first interrupt meets at least one criterion, the at least one criterion including determining that the target execution environment is an execution environment other than the active execution environment of the processing circuit, the exception signaling circuit is configured to: in response to determining that an interrupt priority associated with the first interrupt exceeds a threshold priority, signal a first exception to preemptively trigger a given action, wherein switching from the active execution environment to the target execution environment depends on the given action being performed; and in response to determining that the interrupt priority does not exceed the threshold priority, signal a second exception without preemptively triggering the given action.

Images