GB2624384A

GB2624384A - Exception signalling

Info

Publication number: GB2624384A
Application number: GB2217003.9A
Authority: GB
Inventors: Dall Christoffer; Gupta Achin; Garcia-Tobin Carlos
Original assignee: ARM Ltd; Advanced Risc Machines Ltd
Current assignee: ARM Ltd
Priority date: 2022-11-15
Filing date: 2022-11-15
Publication date: 2024-05-22
Also published as: GB202217003D0; WO2024105351A1

Abstract

An apparatus 4 has interrupt detection circuitry 20 to detect a first interrupt to be handled by processing circuitry 18 in a target execution environment, and exception signalling circuitry 22 to signal exceptions to the processing circuitry in response to taken interrupts. When the first interrupt meets at least one criterion, including when the target execution environment is not an active execution environment of the processing circuitry, the exception signalling circuitry is configured to signal a first or second exception depending on an interrupt priority associated with the first interrupt. When it exceeds a threshold priority, the first exception 26 is signalled to pre-emptively trigger a given action, where switching from the active execution environment to the target execution environment is dependent on the given action being performed, and when it does not exceed the threshold priority, a second exception 28 is signalled without pre-emptively triggering the given action.

Description

EXCEPTION SIGNALLING

The present technique relates to the field of exception signalling.

In a data processing system, one or more interrupt sources may raise interrupts indicating that an interrupt event has occurred. An exception may be signalled to processing circuitry to indicate that an interrupt event has occurred, to trigger handling of the interrupt by the processing circuitry. An interrupt may require handling by processing circuitry operating in a target execution environment, and therefore handling of interrupts may involve switching from an active execution environment to the target execution environment. Switching between execution environments may cause processing to be disrupted but may be important for timely handling of important interrupts, and therefore it is desirable to provide increased control over switching between execution environments in response to interrupts.

At least some examples provide an apparatus comprising: interrupt detection circuitry configured to detect a first interrupt to be handled by processing circuitry operating in a target execution environment; and exception signalling circuitry configured to signal exceptions to the processing circuitry in response to taken interrupts; wherein in response to determining that the first interrupt meets at least one criterion, the at least one criterion comprising determining that the target execution environment is an execution environment other than an active execution environment of the processing circuitry, the exception signalling circuitry is configured to: in response to a determination that an interrupt priority associated with the first interrupt exceeds a threshold priority, signal a first exception to pre-emptively trigger a given action, wherein switching from the active execution environment to the target execution environment is dependent on the given action being performed; and in response to a determination that the interrupt priority does not exceed the threshold priority, signal a second exception without pre-emptively triggering the given action.

At least some examples provide a method comprising: detecting a first interrupt to be handled by processing circuitry operating in a target execution environment; and signalling exceptions to the processing circuitry in response to taken interrupts; wherein the method comprises in response to determining that the first interrupt meets at least one criterion, the at least one criterion comprising determining that the target execution environment is an execution environment other than an active execution environment of the processing circuitry: in response to a determination that an interrupt priority associated with the first interrupt exceeds a threshold priority, signalling a first exception to pre-emptively trigger a given action, wherein switching from the active execution environment to the target execution environment is dependent on the given action being performed; and in response to a determination that the interrupt priority does not exceed the threshold priority, signalling a second exception without pre-emptively triggering the given action.

At least some examples provide a computer-readable medium to store computer-readable code for fabrication of an apparatus comprising: interrupt detection circuitry configured to detect a first interrupt to be handled by processing circuitry operating in a target execution environment; and exception signalling circuitry configured to signal exceptions to the processing circuitry in response to taken interrupts; wherein in response to determining that the first interrupt meets at least one criterion, the at least one criterion comprising determining that the target execution environment is an execution environment other than an active execution environment of the processing circuitry, the exception signalling circuitry is configured to: in response to a determination that an interrupt priority associated with the first interrupt exceeds a threshold priority, signal a first exception to pre-emptively trigger a given action, wherein switching from the active execution environment to the target execution environment is dependent on the given action being performed; and in response to a determination that the interrupt priority does not exceed the threshold priority, signal a second exception without pre-emptively triggering the given action.

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

Further aspects, features and advantages of the present technique will be apparent from the following description of examples, which is to be read in conjunction with the accompanying drawings, in which: Figure 1 schematically illustrates an example of a data processing system.

Figure 2 illustrates an example of a processor comprising interrupt detection circuitry and exception signalling circuitry.

Figure 3 illustrates a first example of security states and exception levels of processing circuitry.

Figure 4 illustrates a second example of security states and exception levels of processing circuitry.

Figure 5 illustrates an example of a set of registers which may be provided in a processor.

Figures 6A and 63 illustrate examples of the behaviour of the processing circuitry when a second and first exception are signalled respectively.

Figure 7 illustrates a process of signalling exceptions to processing circuitry. Figure 8 illustrates an example of processing which may be performed by software executing at EL3.

Figure 9 illustrates an example of processing which may be performed by software in an active execution environment in response to a second exception.

As introduced above, in a data processing system, interrupts may be raised which require handling by processing circuitry operating in a target execution environment. The processing circuitry may operate in a number of different execution environments, and when an interrupt is received the processing circuitry may be operating in an active execution environment which differs from the target execution environment. Therefore, to handle the interrupt the processing circuitry may need to switch from an active execution environment to the target execution environment. Switching to the target execution environment promptly upon receiving the exception means that critical interrupts 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 disrupted. It may be desirable in some cases for processing in the active execution environment to continue for some time, and for the switch to the target execution environment to take place later. For example, software in the active execution environment may be nearing a point of processing at which much less state needs to be saved when the interrupt is taken, and therefore a point of processing where it would be more desirable to handle the interrupt than at the current point of processing. Therefore, it can be useful in some cases to give the software in the active execution environment flexibility to decide when the interrupt is dealt with.

An apparatus may be provided which comprises interrupt detection circuitry to detect that an interrupt to be handled by processing circuitry in a target execution environment is pending, and which comprises exception signalling circuitry to selectively signal exceptions to the processing circuitry in response to taken interrupts.

In one example, all interrupts detected by the interrupt detection circuitry to be handled in a target execution environment other than the active execution environment could be signalled to the processing circuitry using a given exception.

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 the target execution environment regardless of the processing in the active execution environment. This means that all interrupts are handled promptly, but involves pre-empting execution in the active execution environment whenever an interrupt is received that needs handling in an execution environment other than an active execution environment.

In an alternative example, in response to the given exception the processing circuitry may be configured to allow 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 therefore may not cause pre-emption of 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 needing to be handled in an execution environment other than the current execution environment is delayed.

In one example technique, the processing circuitry could be configured to have a setting to select one of the two options described above, and therefore to select whether to handle an interrupt signalled by the given exception by always pre-empting execution in the active execution environment or by always allowing software in the active execution environment to schedule handling of the interrupt. This provides some control over whether interrupts in general are allowed to pre-empt execution in the active execution environment at a given time. However, in this example the different methods for handling the interrupt are controlled by software changing the control setting. Since the timing of interrupts occurring 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 may pre-empt processing in the active execution environment at a given time.

However, it has been recognised that certain interrupts 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, whilst other interrupts may be considered less critical. It may be desirable to pre-empt processing in the active execution environment to switch to the target execution environment for interrupt handling in response to critical interrupts, and 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 desired to pre-empt processing in the active execution environment in response to some interrupts to be handled in a different execution environment and not in response to other interrupts to be handled in a different execution environment.

Interrupts may be associated with an interrupt priority. The interrupt priority could, for example, be used to determine an order in which to handle pending interrupts that are to be handled in a same execution environment. The interrupt priority could also be used to mask certain interrupts having a low priority, causing those interrupts not to be taken, and therefore not to be signalled to processing circuitry. The inventors have realised that the interrupt priority may 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.

Therefore, in some examples, the exception signalling circuitry is configured to signal a first exception or a second exception in dependence on an interrupt priority associated with the first interrupt. In response to a determination that the interrupt priority exceeds a threshold priority, a first exception may be signalled to pre-emptively trigger a given action, wherein switching from the active execution environment to the target execution environment is dependent on the given action being performed. In response to a determination that the interrupt priority does not exceed the threshold priority, a second exception may be signalled without pre-emptively triggering the given action. In this way, some interrupts may lead to pre-emptive triggering of the given action, whilst other interrupts may not lead to the action being pre-emptively triggered without any switch between different control settings. The given action may pre-empt processing in the active execution environment. This technique therefore gives greater control over the pre-emption 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.

The exception signalling circuitry may perform the selective signalling of the first or 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 an active execution environment of the processing circuitry.

For interrupts to be handled in the active execution environment, it may not be necessary to pre-empt processing since there may be no need to switch to another execution environment to handle the interrupt. The at least one criterion may also comprise further criteria. For example, the at least one criterion may comprise determining that the first interrupt belongs to at least one class of interrupts. The at least one criterion may comprise determining that the first interrupt is not to be handled in an exception level responsible for switching between security states. As discussed below, the at least one criterion may also comprise determining that the target execution environment in which the first interrupt is to be handled is a preemptive execution environment. Different implementations may have different options for which further criterion or criteria are applied, in addition to the criterion that the target execution environment is an execution environment other than the active execution environment. The determination that the interrupt priority exceeds the threshold is not particularly limited. The interrupt priority and threshold priority may be represented by numerical values, and the determination may involve a comparison of the numerical values. It will be appreciated that a higher priority may be represented by either a higher or lower numerical value, and therefore the interrupt priority may exceed the threshold priority when it takes a higher numerical value or a lower numerical value in different examples. When the interrupt priority equals the threshold priority, this could be interpreted as exceeding or not exceeding the threshold priority based on implementation.

In some examples, execution environments are not particularly limited. Execution environments could, for example, include virtual machines, processing modes, and so on. In some examples, processing circuitry may operate in one of two or more security states.

Security states may be associated with different physical address spaces. Processes executing in certain security states may be unable to access data or instructions associated with certain other security states. In some examples, the target execution environment and active execution environment comprise different security states. Hence, the first interrupt may require handling in a security state other than the active security state.

In some examples, the given action comprises switching the security state. In some examples, the given action comprises switching the security state from the active security state to the target security state.

Processing circuitry may also operate in 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. Exception levels may be hierarchical, with higher privilege exception levels having greater privileges than lower privilege exception levels. The mechanisms for switching between exception levels may include signalling an exception to the processing circuitry and performing an exception return.

In some examples, the given action comprises causing the processing circuitry to switch to an exception level responsible for switching between security states. Therefore, in response to the first exception the processing circuitry may be caused to pre-emptively switch to the exception level responsible for switching between security states, and in response to the second exception the processing circuitry may not be caused to pre-emptively switch to said exception level. By pre-emptively switching the processing circuitry to the exception level responsible for switching between security states, the first exception may enable software to switch the processing circuitry to the target security state to handle the first interrupt more quickly than if the current software executing at the time that the first exception occurs has the opportunity to decide to delay the switch to the exception level responsible for switching between security states.

In response to a determination that the interrupt priority does not exceed the threshold priority, the second exception may be signalled without pre-emptively triggering the given action. However, despite not pre-emptively triggering the given action, it may be desirable that the first interrupt is handled at some point. In addition, it may sometimes be desirable that pending interrupts to be handled in the active execution environment may be handled before the first interrupt in certain cases. In some examples, this may be achieved if the second exception indicates to the processing circuitry that a second interrupt is pending, wherein 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, software in the active execution environment may be able to schedule handling of the second interrupt in an appropriate way. The second interrupt may be a doorbell interrupt indicating to the processing circuitry that the first interrupt is pending to be handled in a different execution environment. The software handling the second interrupt in the active execution environment may therefore be notified of a pending first interrupt to be handled in a different execution environment, and may trigger the given action voluntarily so that the interrupt can be handled. In this case, when the given action is triggered it is done so voluntarily by software, rather than pre-emptively by hardware (and therefore involuntarily from the point of view of the software executing at the time the first exception is signalled) as in the case of the first exception. The second interrupt may be configured like any other interrupt of the active execution environment. For example, the second interrupt may be associated with a second interrupt priority defined in an interrupt priority space of the active execution environment. Therefore, the software of 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 can be contrasted to the first exception which preempts processing of the active execution environment outside of the control of software, so this pre-emption may occur even if there is a high priority interrupt pending for the active execution environment. The second interrupt priority may be independent of the interrupt priority associated with the first interrupt. Therefore, the priority of the doorbell interrupt may 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.

Different execution environments may have different levels of security and privacy.

Hence, it may not be desirable to allow processing in one execution environment to be aware of the interrupts raised in a different execution environment. Therefore, in some examples the exception signalling 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. Therefore, whilst the second exception may indicate that an interrupt is pending to be handled in a different execution environment, the active execution environment may have no information about what caused the interrupt. This ensures that less privileged code in the active execution environment is not exposed to any potentially secret information about the execution of more privileged code in a different execution environment.

In some examples (e.g. which support 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 some information regarding the importance of the first interrupt to the software in the active execution environment responsible for deciding whether to trigger the given action. Hence, software in the active execution environment can make a more informed choice about when to trigger the given action to allow the first interrupt to be handled (also, in an example where software in a certain exception level is responsible for switching security state, this information can 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 other execution environments. 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 a number of variants of the second interrupt corresponding to different execution environments, so that when the first interrupt occurs, the relevant one of the second interrupt variants corresponding to the target execution environment of the first interrupt is selected, and the interrupt number of that second interrupt will identify to software which execution environment is the target execution environment for the first interrupt.

As mentioned above, the selective signalling of the first and second exceptions may be performed 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. However, at least one further criterion may also be applied.

In some examples, the at least one criterion also comprises determining that the target execution environment is a pre-emptive execution environment. Hence, in some examples the selective issuing of the first and second exceptions only takes place for interrupts that are to be handled in a pre-emptive execution environment. Interrupts to be handled in a target execution environment other than the active execution environment, when the target execution environment is not a pre-emptive execution environment, may be signalled in a different way.

In particular, interrupts to be handled in an execution environment other than a pre-emptive execution environment may in some examples not be able to pre-empt processing in the active execution environment, so may be processed once the software in the active execution environment has voluntarily triggered the given action, to yield processing time on the processing circuitry so that another execution environment can handle the interrupt. It may be desirable to prevent certain execution environments from being able to pre-empt processing in a given execution environment to reduce the performance impact on processing in the active execution environment.

In some examples, at least one pre-emptive execution environment may be hardwired or set in a register that cannot be modified by software. This may provide a simple and secure way of identifying whether an execution environment is a pre-emptive execution environment.

However, a software developer may wish to vary which execution environments can pre-empt execution in the active execution environment at a given time. Hence, the exception signalling circuitry may be configured to determine whether a given execution environment is a preemptive execution environment based on pre-emptive execution environment indication information stored in at least one software-writeable configuration register. For example, the pre-emptive execution environment indication information may be stored in a single configuration register, or could be split between two or more registers each storing part of the information.

In some examples, the pre-emptive execution environment indication information may indicate that several execution environments are pre-emptive execution environments. In this case, when the processing in the active execution environment is pre-empted to handle a first interrupt in a different execution environment, there may be two or more pending first interrupts to be handled in different pre-emptive execution environments. In the case, the pre-emptive execution environments may be ranked, such that interrupts to be handled in a higher ranked execution environment are handled in advance of interrupts to be handled in a lower ranked execution environment. The ranking may be implicit in the design of the hardware of the processing system or in some examples may be configurable based on software-writable control information indicated in a register.

However, in some examples the encoding of the pre-emptive execution environment indication information indicates that one execution environment is the pre-emptive execution environment at a given time. This may provide a simpler mechanism having only a single pre-emptive execution environment, avoiding conflict between pre-emptive execution environments.

There are several ways that a threshold priority can be determined. However, in some examples the threshold priority is indicated by threshold priority information stored in a software-writeable register. Being software-writeable 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 a different threshold priority at different points in a program.

It may also be desirable to set a different threshold priority for different execution environments. Therefore, in some examples an encoding of the threshold priority information enables indication of a threshold priority for a given execution environment which is separate from a 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 changing between execution environments may also change the threshold priority for pre-empting execution in that execution environment. For example, the threshold priority could be stored in a banked register, where a different version of the register is accessed by each execution environment.

In some examples, software may not be given full control to modify the threshold value. For example, software in the active execution environment could set a relatively high threshold value to prevent itself from being pre-empted, but this may risk critical interrupts being delayed. Therefore, in some examples control information defines whether a given execution environment is permitted to modify the threshold priority information for a given target execution environment. This may prevent certain less trusted execution environments being permitted to modify the threshold priority information, for example.

Since the control information determines whether an execution environment can modify the threshold priority information, it may be desirable that the control information can only be set by software at a high privilege level. Therefore, in some examples the control information is stored in a control register, and writes to the control register by software executing at a given exception level are not permitted when the given exception level is lower than an exception level responsible for switching between security states. The exception level responsible for switching between security states may be a high (more privileged) exception level, often the highest exception level, and therefore may be trusted to set the control information.

In some examples, the first and second exceptions may be signalled to the processing circuitry in the same way, for example using the same input pin to the processing circuitry. Then, the first and second exceptions may be differentiated using a second mechanism such as an exception type value indicating whether the signalled exception is a first exception or a second exception. However, in some examples the first exception is signalled on a first input pin to the processing circuitry and the second exception is signalled on a second input pin to the processing circuitry, wherein the first input pin is separate from the second input pin. This provides an effective mechanism to signal different exceptions based on whether the exception should pre-emptively trigger the given action or not. In some systems, the first and second input pins may already be provided (e.g. for "fast" and "normal" exceptions, where "fast" exceptions are to be prioritised over "normal" exceptions), and therefore the technique can be implemented with a 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).

In some examples, when it is determined that a first exception is to be signalled, the exception signalling circuitry is configured to signal the first exception regardless of a current priority level of processing being performed by the processing circuitry. For example, if the processing circuitry operating in the active execution environment is handling an interrupt with a given priority, then the first exception will pre-emptively trigger the given action even if the given priority is higher than the interrupt priority associated with the first interrupt. This means that, regardless of the current processing in the active execution environment, critical interrupts can be handled promptly in the target execution environment. It also means that there is no comparison between the priority of the interrupt to be handled in the target execution environment and the priority of interrupts in the active execution environment, so that these priorities can be set entirely independently of one another. Therefore, an interrupt priority space in which the interrupt priority associated with the first interrupt to be handled in the target execution environment is defined, which is an interrupt priority space associated with the target execution environment, can be considered independent from an interrupt priority space associated with another execution environment. Therefore, when a software developer is deciding how to set interrupt priorities, they do not need to consider software that may be executing in different execution environments (which simplifies and reduces cost of software development because it reduces need for cooperation between software provided by different software developers), and further they may have access to a wider portion of the interrupt priority space without trying to ensure that the priority exceeds a pending priority in another execution environment.

As introduced above, switching from an active security state to a target security state may be performed by software executing at a particular exception level. In order for the software at that exception level to know which security state to switch to in order to handle the interrupt, some examples may provide a pending interrupt configuration register accessible to 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 indicating one or more execution environments having a pending interrupt. The pending interrupt configuration register may be provided as a system register rather than a location in memory, enabling the exception level responsible for switching between security states to quickly determine which security state to switch to. The register may provide flags per execution environment, to indicate the execution environments having pending interrupts. The pending interrupt configuration register is separate from any more detailed tracking of pending interrupts (e.g. a pending interrupt structure in memory showing queues of pending interrupts). For example, the pending interrupt configuration register may not track the specific details of the pending interrupts, such as interrupt number, but may simply provide a summary of whether there is any pending interrupt for a given execution environment, so that the security state switching software can quickly identify which execution environment to switch to.

Figure 1 schematically illustrates an example of a data processing system 2 (e.g. a system on chip) comprising a number of processors 4 (e.g. central processing units, CPUs). In this example three processors 4 are shown, but it will be appreciated that the number of processors could vary. The processors communicate with each other and with shared memory 8 via a cache coherent interconnect 6 which supports a coherency protocol to maintain cache coherency of data cached in private caches of each processor 4.

An interrupt controller 10 is provided, to receive incoming interrupt signals from connected peripherals 14 and forward them to the processors 4. In some cases, processors also generate interrupts for other processors known as Inter-Processor Interrupts (IPIs), so the processors 4 themselves can also act as interrupt sources. Peripherals can signal interrupts to the interrupt controller 10 either via dedicated wires 11 or by reusing an existing I/O (input/output) mechanism 12 such as memory-mapped I/O write operations. The latter is typically known as message-signalled interrupts (MSIs).

The interrupt controller therefore needs to be able to communicate with the processors to which it can forward interrupts. As shown in Figure 1, one way to implement this is to use a dedicated communication protocol and interrupt communications 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 coherency mechanism supported by the cache coherent interconnect 6 is leveraged for distribution of interrupts from the interrupt controller 10 to the processor 4, and the interrupt configuration and state are represented by memory-based tables which are shared by the processors and the interrupt controller. In both examples, the processing elements 4 can be made aware that an interrupt event has occurred, and can execute software for handling the interrupt.

Figure 2 illustrates an example of one of the processors 4 shown in Figure 1. The processor 4 comprises processing circuitry 18 for performing processing operations. The processing circuitry 18 may operate in one of a plurality of exception levels and one of a plurality of security states, as illustrated in Figures 3 and 4.

Figure 3 illustrates an example of processes which can be executed by the processing circuitry 18. A hypervisor 30 may manage a number of virtual machines (VMs, also known as guest operating systems or guest OS) 32. One VM 32 is shown in Figure 3, but it will be appreciated that the hypervisor may manage several VMs. Each VM 32 may manage one or more applications 34. For example the hypervisor 30 may control which regions of an address space are allocated to each virtual machine 32 and control switching between the virtual machines 32. Similarly, each VM 32 may control which regions of the address space are allocated to each application 34 executing under that VM 32, and may control switching between the applications as required.

As shown in Figure 3, each process is associated with a given privilege level ELO, EL1, EL2, EL3. In this example higher numbered privilege levels are more privileged than lower numbered privilege levels, although it could be numbered the other way round in other examples. In this example, the applications 34 execute at privilege level ELO, the VMs 32 execute at privilege level EL1 and the hypervisor 30 executes at privilege level EL2. Typically, a process executing at a higher privilege level has rights not available to a process executing at a lower privilege level.

As shown in Figure 3, the hypervisor 30, VMs 32 and applications 34 may operate in a Non-secure security state. In addition, the apparatus may support a Secure security state which is partitioned from the Non-secure security state. There may also be processes running in the Secure security state, such as a trusted operating system (OS) 38 and trusted services (applications) 40 executing in the Secure security state under control of the trusted OS 38.

The Secure and Non-secure security states may be associated with different physical address spaces. The processing circuitry 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 circuitry 18 may only be able to access the Non-secure physical address space and system registers that allow non-secure accesses. The trusted OS 38 and trusted applications 40 execute at privilege levels EU, ELO respectively. A Secure partition manager 36 may be provided at EL2 in the Secure state to control execution in the Secure security state in a similar way 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 security state and the Secure security state. The firmware 42 may be considered to be part of the Secure security state. An example of a technique for partitioning the non-secure and Secure security states is the Arm® Trustzone® technology, although other examples could also be used.

Figure 4 illustrates a further example. In Figure 4, in addition to the Secure and Non-secure security states, a Realm security state is also provided, associated with a further physical address space called the Realm physical address space. Processes including a realm manager 44, operating system 46, and applications 48 may be run at exception levels EL2-ELO in the Realm security state in a similar way to the Non-Secure and Secure states. 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 security state may be unable to access the Realm physical address space. In the example of Figure 4, the EL3 exception level for switching between security states may be provided in a Root security state independent from the other security 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, Secure, Realm, and Root security states is the Arm® Realm Management Extension, although other examples could also be used. Returning to Figure 2, the processor 4 also comprises interrupt detection circuitry 20 and exception signalling circuitry 22. The interrupt detection circuitry 20 and exception signalling circuitry 22 may together be considered a CPU interface through which the interrupt controller 10 can communicate with the processing circuitry 18. The CPU 4 has a number of exception input pins for signalling different types of exceptions to the processing circuitry 18. Figure 2 shows two exception input pins: a fast interrupt (FIQ) pin 26 and a standard interrupt (IRO) pin 28. Exceptions raised on the FIQ pin can be prioritised over exceptions raised on the IRQ pin, as the FIQ pin 26 may be used for interrupt types which require faster handling than those on the IRO pin 28. In some examples, these may not be the only exception input pins, and at least one further pin could also be provided for another class of exceptions.

The interrupt detection circuitry 20 receives an indication of a interrupt from the interrupt controller 10 through the interrupt communication bus 16 or the interconnect 6 as described above (e.g. the indication received via the interconnect 6 could be a coherency snoop message indicating that a request to write to a given address assigned for interrupt notification by the interrupt controller 10 has been detected). The interrupt may require handling by software executing in a particular security state of the processing circuitry 18. For example, the processing circuitry 18 may be operating in the Non-secure state and the interrupt controller 10 indicates an interrupt that requires handling in the Secure state. Therefore, there may be a need to switch from the active security state to a different security state to handle the interrupt.

In one example, every time the interrupt detection circuitry detects an interrupt to be handled in a security state other than the active security state, this may be signalled to the processing circuitry using a given exception. For example, this could be signalled on the FIQ input pin 26.

In one example, in response to the signalling of the given exception indicating receipt of an interrupt to be handled in a different security state, the processing circuitry 18 may always switch to the EL3 exception level responsible for switching between security states. It will be appreciated that EL3 is used to mean the exception level responsible for switching between security states. This is often the most privileged exception level, but may not necessarily be EL3 in certain implementations. Once processing has switched to EL3, software executing at EL3 may switch to the target security state for handling of the interrupt. Whilst 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 could disrupt processing in the active security state since the transition to EL3 takes place regardless of the processing in the active security state -sometimes taking the interrupt at the current moment of processing may be less efficient than if the current processing in the active security state could progress a little further before taking the interrupt at a point where less architectural state needs to be saved to memory on taking the interrupt.

In an alternative example, in response to the signalling of the given exception, the processing circuitry 18 may never immediately (pre-emptively) switch to the EL3 exception level. Software may continue to operate in the active security state, and may decide when to voluntarily trap to a higher exception level to respond to the exception. For example, if operating at the ELO exception level, the given exception could cause processing circuitry 18 to transition to the EL1 exception level. Software at the higher exception level may then determine to handle the interrupt, and may cause processing to switch to EL3 so that the security state can be changed, or alternatively may decide to return to the lower exception level to finish processing before switching to EL3 and handling the interrupt later. Therefore, by not immediately switching to EL3 when an interrupt to be handled in a different security state is received, the processing in the active security state may encounter less disruption. However, this leaves software in the active execution environment in control of the timing of interrupt handling, which may cause the handling of critical interrupts to be delayed.

In some examples, a value stored in a register could control the processing circuitry 18 to respond to the given exception by either 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 the processing circuitry 18. However, even though this technique may allow a software designer more design freedom regarding the handling of interrupts, at any given time the technique is limited to either always pre-emptively switching to EL3 in response to an interrupt to be handled in another security state (regardless of the properties of that interrupt), or always allowing software to decide when to switch to EL3 (regardless of the properties of that interrupt). It is not practical to switch the value stored in the register ahead of receipt of a particular interrupt that requires either the pre-emptive or non-pre-emptive handling, as the timing of receipt of that interrupt is not known. There are a wide range of reasons why an interrupt may be received which needs to be handled in another security state. Some interrupts require urgent handling which would be worth pre-empting execution in the active security state, whilst others may be less critical where it would be preferable to avoid pre-empting 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 an active security state can be signalled to the processing circuitry 18 in different ways.

Figure 5 illustrates an example of registers 24 which may be provided in the processor 4. The registers 24 may be accessible to the exception signalling circuitry 22 and the processing circuitry 18, for example. The suffix _ELx shown for the registers in Figure 5 denotes the least privileged exception level allowed to write to that register -e.g. ICC_CTLR_EL1 can therefore be written to by software executing at EL1, EL2 or EL3, while ICC_CTLR_EL3 can be written to by software at EL3. It will be appreciated that the register names indicated are arbitrary and that the same control information represented in these registers could also be represented in other ways (e.g. information described in different registers in Figure 5 could be stored in the same register in other examples).

The registers 24 include at least one ICC_CTLR_EL1 register. The ICC_CTLR_EL1 register stores a priority threshold value.

When the interrupt controller 10 signals an interrupt event to the processor 4, the interrupt is associated with an interrupt priority. The interrupt priority may be used in some systems for selecting an order to handle interrupts. For example, each pending interrupt may be associated with an interrupt priority and the exception signalling circuitry may determine which pending interrupt to signal to processing circuitry based on which pending interrupt has the highest priority. The priority may also be used for masking certain interrupts. When an interrupt has a priority below a masking priority (which can be configurably set by software setting a mask threshold level), that interrupt may be determined to be not taken, and the exception signalling circuitry may not signal an exception to the processing circuitry in response to said not taken interrupt.

Upon receiving an interrupt to be handled in a security state other than the active security state, the exception signalling circuitry may compare the interrupt priority associated with the interrupt with the priority threshold value stored in the ICC_CTLR_EL1 register. In some schemes, a numerically lower value may represent a higher priority, and the interrupt priority may therefore 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, numerically higher values of interrupt priority may represent the higher (more important) priority, and so the interrupt priority may exceed the priority threshold if its value is numerically higher than the priority threshold. Either way, depending on whether the interrupt priority exceeds the threshold (in addition to further conditions discussed below), the exception signalling circuitry may signal either a first exception or a second exception.

The first exception may be signalled on the FIQ input pin to the processing circuitry 18. The second exception may be signalled on the IRO input pin. Hence, rather than signalling all taken interrupts which are to be handled in a security state other than the active security state using a single exception, the present technique can signal two different exceptions depending on a comparison between a priority of the interrupt and a threshold. The first exception signalled on the FIQ pin may cause processing circuitry 18 to pre-emptively switch to the EL3 exception level outside of the control of software, which may then allow software at EL3 to switch to the target security state for handling the interrupt. The second exception signalled on the IRQ pin may not cause a pre-emptive switch to the EL3 exception level, but may instead allow software operating in the active security state to decide when to switch to EL3 to allow the interrupt to be handled. Therefore, the signalling of exceptions to processing circuitry can vary based on the priority of an interrupt, which allows different interrupts to be handled in different ways, mitigating the impact for the software in the active security state but ensuring that critical interrupts for the target security state can be serviced promptly.

As indicated in Figure 5, there may be several versions of the ICC_CTLR_EL1 register in addition to the register 50. These may include banked copies 52, 54 of the ICC_CTLR_EL1 register, which are each associated with a security state. Although 3 banked registers are shown, it will be appreciated that this may vary freely based on implementation. Therefore, different versions of the register may be accessed based on the active security state of the processing circuitry 18. Since the priority threshold is based on a value in the register, the priority threshold may vary between security states. The values in the registers ICC_CTLR_EL1 may be written by software at ELI, EL2 or EL3 to allow a software designer to vary how critical an interrupt needs to be before it pre-empts execution in the active security state. In some implementations, there may be permissions accessible only to EL3 which determine how software may modify the priority threshold values.

In addition to the threshold priority comparison described above, the exception signalling circuitry may also determine whether the exception is to be handled in a pre-emptive interrupt domain. The pre-emptive interrupt domain may be one of the security states. For example, a register ICC_CTLR_EL3 56 may be provided indicating which of the security states is a pre-emptive interrupt domain. For example, two bits may be used to select one of the Non-secure, Secure, and Realm security states indicated in Figure 4. Writes to register ICC_CTLR_EL3 may be restricted to software executing in EL3.

In some examples, two or more security states may be considered to be a pre-emptive interrupt domain. In some examples, each security state may be considered to be a pre-emptive interrupt domain. However, in some examples the complexity of the architecture may be reduced by supporting only a single pre-emptive interrupt domain at a time, which can be selected by EL3 software setting a value in ICC_CTLR_EL3.

The exception signalling circuitry may only signal the first exception, on the FIG pin, when the target security state is a pre-emptive interrupt domain. Therefore, processing may pre-emptively be caused to switch to EL3 (outside of the control of software executing at ELO, EL1 or EL2 in the active security state) in response to an interrupt to be handled in a preemptive interrupt domain. This provides a second mechanism by which interrupts can be assessed to determine whether to signal a first or second exception. Therefore, it can be assessed both whether the target interrupt domain is a pre-emptive interrupt domain, and whether the interrupt priority exceeds a priority threshold. By performing both comparisons, software designers are presented with greater control over how a given interrupt is signalled to processing circuitry, so that critical interrupts can be handled promptly whilst less critical interrupts can have a reduced impact on processing.

The registers also include a register ICC_DOMHPPIR_EL3 58 accessible to processing in the EL3 exception level. Once processing has switched to EL3, either due to hardware switching in response to the FIG exception or due to software yielding control after an IRO exception, the software at EL3 needs to determine which security state to switch to so that the interrupt can be handled. This may be indicated in the ICC_DOMHPPIR_EL3 register. For example, if there is a single pre-emptive interrupt domain, there may be a single bit indicating whether there is a pending interrupt to be handled in the pre-emptive interrupt domain. The pre-emptive security state may be determined from the ICC_CTLR_EL3 register and therefore the software at EL3 can switch to the pre-emptive security state for handling the interrupt when the bit indicates a pending interrupt for the pre-emptive interrupt domain. In other examples there may be more than one interrupt domain, and therefore 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 not a pending interrupt for that security state. In some examples having more than one pre-emptive interrupt domain, the security states may be ranked to determine the order in which EL3 should handle interrupts simultaneously pending in more than one preemptive security state. Regardless of the particular format of the pending interrupt information in the ICC DOMHPPIR_EL3, this information can be set On hardware) by the interrupt detection circuitry 20 or exception signalling circuitry 22 when a pending interrupt is detected for a given interrupt domain/security state, and cleared by the hardware when there are no longer any pending interrupt for that domain/security state. This information is separate from any tracking of pending interrupt queues using structures maintained by the interrupt controller 10. The ICC DOMHPPIR EL3 can be seen as a summary of such more detailed pending interrupt queues (which may track the specific interrupt numbers of the pending interrupts), in that the ICC DOMHPPIR EL3 is a summary of whether there is any pending interrupt for a given domain/security state, which can be accessed more quickly by the EL3 software than the more detailed interrupt tracking structures maintained by the interrupt controller 10.

Figure 6A illustrates an example of the behaviour of the processing circuitry when the second exception is signalled.

At step 600, the processing circuitry 18 is operating in the active security state. Whilst Figure 6 shows that an application is being executed at ELO, the processing circuitry 18 could also be executing at ELI or EL2, for example.

At step 602, the second exception is signalled to the processing circuitry 18. This may involve signalling the exception on the IRO input pin. The second exception may be signalled in response to the interrupt detection circuitry detecting a first interrupt where the first interrupt is to be handled in a target security state which is different from the active security state. The second exception may be signalled when it is determined that the target security state is a security state other than a pre-emptive security state based on an indication of one or more pre-emptive security states stored in the ICC_CTLR_EL3 register. Alternatively, the target security state may be a pre-emptive 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.

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) for handling the exception. Rather than presenting the first interrupt to the software in the active security state, the second exception indicates a second interrupt. The second interrupt can be handled in the active security state, unlike the first interrupt, and therefore software in the active security state is able to schedule handling of the second interrupt like all of the 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 from the interrupt priority of the first interrupt in the interrupt priority space used by the target security state. The second interrupt's priority is used to prioritise the second interrupt relative to other interrupts targeting the active security state. The second interrupt indicates to the 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 expose information about the first interrupt to the software in the active security state. This can be important to avoid allowing secrets associated with one security state being exposed to software in a different security state.

At step 606, the exception handling software in the active security state may either determine to return to processing in ELO in the active security state and decide to handle the interrupt later, or voluntarily yield processing to EL3 to allow the first interrupt to be handled. 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 a pre-emptive security state. Upon determining that there is a pending interrupt for the pre-emptive interrupt domain, the software then switches to the (only or highest priority) pre-emptive security state for handling of the first interrupt at step 610.

Figure 6B illustrates an example of the behaviour of the processing circuitry when the first exception is signalled.

At step 612, the processing circuitry 18 is operating in the active security state as in step 600 of Figure 6A.

At step 614, the first exception is signalled to the processing circuitry 18. This may involve signalling the exception on the FIQ input pin. The first exception is signalled in response to the interrupt detection circuitry detecting a first interrupt where the first interrupt is to be handled in a target security state which is different from the active security state. The first exception may be signalled when it is determined that the target security state is a pre-emptive security state based on an indication of one or more pre-emptive security states stored in the ICC_CTLR_EL3 register, and that 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 signalled when it is determined that the interrupt is of a type that should be handled at the EL3 exception level.

At step 616, in response to the first exception the processing circuitry pre-emptively switches to EL3 outside of the control of software executing in the active security state. This pre-empts processing in the active security state.

At step 618, software at EL3 uses the ICC_DOMHPPIR_EL3 register to switch to the target security state as in step 608, to allow handling of the first interrupt. By pre-emptively switching to EL3, the processing circuitry ensures that the first interrupt is handled promptly, bypassing any decisions by software in the active security state, including the possibility of yielding to EL3 being delayed whilst processing is completed. Processing then continues in an exception level in the target security state for handling of the interrupt in step 620. Comparing the processes illustrated in Figures 6A and 6B, it will be seen that interrupts may be handled more quickly when the FIQ exception is signalled rather than the IRQ exception, since this bypasses software in EL1/EL2 of the active security state and the software at EL1/EL2 has no choice over whether the yield to EL3 occurs. Hence, the first exception may be more appropriate for interrupts which require quick handling.

Figure 7 illustrates a process of signalling exceptions to processing circuitry 18. The process may be performed by the interrupt detection circuitry 20 and exception signalling circuitry 22, for example.

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

At steps 702-710 it is determined whether the first interrupt meets at least one criterion. At step 702 it is determined whether the first interrupt is to be handled in EL3. In the example shown in Figure 4, this may involve determining that the target security state is the Root domain, for example. When it is determined that the interrupt is to be handled at EL3, then at step 704 an FIQ exception is signalled to the processing circuitry 18 on the FIQ input pin 26. The FIQ signal causes the processing circuitry 18 to switch to EL3 outside of the control of software. Hence, the hardware of the processor 4 is configured such that exceptions to be handled in EL3 cause the processing circuitry to switch to EL3.

If it is determined that the first interrupt is not to 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 a system register. If the target security state is the active security state and the interrupt is not targeting EL3, then there is no need to switch to a different security state for handling of the first interrupt. Therefore, at step 708 the exception signalling 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, IRQ may cause processing to switch to a higher exception level within the same security state for handling of the interrupt. Software within the active security state then has control over handling of the interrupt.

If it is determined that the target security state differs from the active security state, then at step 710 it is determined whether the target security state of the first interrupt is a pre-empfive security state. One or more pre-emptive security states may be determined based on EL3-configurable control information in register ICC_CTLR_EL3. Pre-emptive security states are security states for which interrupts (other than those to be handled at EL3) are permitted to pre-empt processing in the active security state. If the target security state is not a preemptive security state, then the FIQ exception is not signalled because the interrupt is not permitted to pre-empt execution in the active security state. Therefore, at step 712 the IRO exception is signalled. The IRO exception may signal a second interrupt indicating to the software in the active security state that the first interrupt is pending to be handled in a security state other than the active security state.

When it is determined that the first interrupt meets at least one criterion, then at step 714 it is determined whether an 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 signalled to the processor 4 from the interrupt controller 10.

When it is determined that the interrupt priority does not exceed the threshold priority, the first interrupt is determined to be too low priority to pre-empt processing in the active security state. As such, the FIQ exception which would pre-empt processing is not signalled, and instead at step 720 the ISO exception is signalled to the processing circuitry 18 as in step 712. This enables software in the active security state to be aware that an interrupt is pending for a different security state, and allows the software to yield to EL3 for handling of the interrupt.

When it is determined that the interrupt priority does exceed the threshold, the first interrupt is deemed to be of high enough priority that processing in the active security state may be pre-empted to handle the interrupt. Therefore, the FIQ exception is signalled at step 716. At step 718, the FIQ exception causes the processing circuitry 18 to switch to the EL3 exception level outside of the control of software in the active security state. This switch occurs regardless of the processing being performed in the active security state. The switch to EL3 enables software at EL3 to switch to the target security state for handling of the first interrupt. Hence, by differentiating between interrupts based on a target security state and an interrupt priority, the present technique enables greater control over whether a given interrupt should pre-empt processing at a given time. This provides a balance between fast handling of important interrupts and minimising disruption to ongoing processing.

It will be appreciated that certain steps shown in Figure 7 may take place in a different order and may take place in parallel.

Figure 8 illustrates an example of processing which may be performed by software executing at EL3. At step 800, processing switches to EL3 in response to an exception. This switch may have been caused due to an FIQ exception outside the control of software, or due to software yielding control to EL3 (in response to an IRQ exception or otherwise).

At step 802 the software examines the pending interrupt configuration register ICC_DOMHPPIR_EL3 to determine which security states have pending interrupts.

At step 804, the EL3 software handles any pending interrupts which require handling at EL3. When there are no pending interrupts for EL3, the EL3 software determines whether a pre-emptive security state has a pending interrupt. If so, and if there is only one pre-emptive security state, then it is determined to switch to the pre-emptive security state so software at that security state can handle the pending interrupt. If there is more than one pre-emptive security state, software at EL3 determines which is the highest priority pre-emptive security state for which there is a pending interrupt. If there are no pre-emptive security states having pending interrupts, the EL3 software determines whether there are any other security states having pending interrupts. In any case, once a security state has been selected, the EL3 software causes the processing circuitry to switch to the selected security state at step 806 and then yields processing to an exception level within that security state at step 808 for handling of the interrupt.

Figure 9 illustrates an example of processing which may be performed by software in the active execution environment in response to the IRQ exception. At step 900, the IRQ exception is received on the IRQ input pin. This may be signalled as illustrated in Figure 7.

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

At step 904, software sees a pending doorbell interrupt signalled by the second exception. The doorbell interrupt can be handled in the active security state and indicates that an interrupt is pending to be handled in a different security state. The software at 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 being selected from among a set of doorbell interrupts with different interrupt numbers, each corresponding to one of the security states, so 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 for handling of the interrupt, or continue with the processing in the active security state. If it is determined to switch to EL3 at that time, then at step 908 the software voluntarily yields processing to EL3, such as by raising a supervisor call targeting EL3.

If it is determined not to switch to EL3 at that time, then processing continues in the active security state. For example, the processing occurring before the IRQ exception may be resumed. At step 910, software in the active security state determines at a later time to switch to EL3 to enable handling of the pending interrupt. Therefore, at step 912 software in the active security state voluntarily yields processing to EL3.

It will be seen that in response to the IRO exception, the software in the active security state is in control of the decision about when to handle the first interrupt.

Concepts described herein may be embodied in computer-readable code for fabrication of an apparatus that embodies the described concepts. For example, the computer-readable code can be used at one or more stages of a semiconductor design and fabrication process, including an electronic design automation (EDA) stage, to fabricate an integrated circuit comprising the apparatus embodying the concepts. The above computer-readable code may additionally or alternatively enable the definition, modelling, simulation, verification and/or testing of an apparatus embodying the concepts described herein.

For example, the computer-readable code for fabrication of an apparatus embodying the concepts described herein can be embodied in code defining a hardware description language (H DL) representation of the concepts. For example, the code may define a registertransfer-level (RTL) abstraction of one or more logic circuits for defining an apparatus embodying the concepts. The code may define a H DL representation of the one or more logic circuits embodying the apparatus in Verilog, SystemVerilog, Chisel, or VHDL (Very High-Speed Integrated Circuit Hardware Description Language) as well as intermediate representations such as FIRRTL. Computer-readable code may provide definitions embodying the concept using system-level modelling languages such as SystemC and SystemVerilog or other behavioural representations of the concepts that can be interpreted by a computer to enable simulation, functional and/or formal verification, and testing of the concepts.

Additionally or alternatively, the computer-readable code may define a low-level description of integrated circuit components that embody concepts described herein, such as one or more netlists or integrated circuit layout definitions, including representations such as GDSII. The one or more netlists or other computer-readable representation of integrated circuit components may be generated by applying one or more logic synthesis processes to an RTL representation to generate definitions for use in fabrication of an apparatus embodying the invention. Alternatively or additionally, the one or more logic synthesis processes can generate from the computer-readable code a bitstream to be loaded into a field programmable gate array (FPGA) to configure the FPGA to embody the described concepts. The FPGA may be deployed for the purposes of verification and test of the concepts prior to fabrication in an integrated circuit or the FPGA may be deployed in a product directly.

The computer-readable code may comprise a mix of code representations for fabrication of an apparatus, for example including a mix of one or more of an RTL representation, a netlist representation, or another computer-readable definition to be used in a semiconductor design and fabrication process to fabricate an apparatus embodying the invention. Alternatively or additionally, the concept may be defined in a combination of a computer-readable definition to be used in a semiconductor design and fabrication process to fabricate an apparatus and computer-readable code defining instructions which are to be executed by the defined apparatus once fabricated.

Such computer-readable code can be disposed in any known transitory computer- readable medium (such as wired or wireless transmission of code over a network) or non-transitory computer-readable medium such as semiconductor, magnetic disk, or optical disc. An integrated circuit fabricated using the computer-readable code may comprise components such as one or more of a central processing unit, graphics processing unit, neural processing unit, digital signal processor or other components that individually or collectively embody the concept.

In the present application, the words "configured to..." are used to mean that an element of an apparatus has a configuration able to carry out the defined operation. In this context, a "configuration" means an arrangement or manner of interconnection of hardware or software. For example, the apparatus may have dedicated hardware which provides the defined operation, or a processor or other processing device may be programmed to perform the function. "Configured to" does not imply that the apparatus element needs to be changed in any way in order to provide the defined operation.

Although illustrative embodiments of the invention have been described in detail herein with reference to the accompanying drawings, it is to be understood that the invention is not limited to those precise embodiments, and that various changes and modifications can be effected therein by one skilled in the art without departing from the scope of the invention as defined by the appended claims.

Claims

CLAIMS1. An apparatus comprising: interrupt detection circuitry configured to detect a first interrupt to be handled by processing circuitry operating in a target execution environment; and exception signalling circuitry configured to signal exceptions to the processing circuitry in response to taken interrupts; wherein in response to determining that the first interrupt meets at least one criterion, the at least one criterion comprising determining that the target execution environment is an execution environment other than an active execution environment of the processing circuitry, the exception signalling circuitry is configured to: in response to a determination that an interrupt priority associated with the first interrupt exceeds a threshold priority, signal a first exception to pre-emptively trigger a given action, wherein switching from the active execution environment to the target execution environment is dependent on the given action being performed; and in response to a determination that the interrupt priority does not exceed the threshold priority, signal a second exception without pre-emptively triggering the given action.
2. The apparatus according to claim 1, wherein the target execution environment and the active execution environment comprise different security states.
3. The apparatus according to claim 2, wherein the given action comprises causing the processing circuitry to switch to an exception level responsible for switching between security states.
4. The apparatus according to any preceding claim, wherein the second exception indicates to the processing circuitry that a second interrupt is pending, wherein the second interrupt can be handled by the processing circuitry in the active execution environment.
5. The apparatus according to claim 4, wherein the second interrupt is associated with a second interrupt priority defined in an interrupt priority space of the active execution environment, wherein the second interrupt priority is independent from the interrupt priority associated with the first interrupt.
6. The apparatus according to any of claims 4 and 5, wherein the exception signalling 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 according to any of claims 4 to 6, wherein the second interrupt indicates the target execution environment of the first interrupt.
8. The apparatus according to any preceding claim, wherein determining that the interrupt meets at least one criterion comprises determining that the target execution environment is a pre-emptive execution environment.
9. The apparatus according to claim 8, wherein the exception signalling circuitry is configured to determine whether a given execution environment is a pre-emptive execution environment based on pre-emptive execution environment indication information stored in at least one software-writeable configuration register.
10. The apparatus according to claim 9, wherein the encoding of the pre-emptive execution environment indication information indicates that one execution environment is the pre-emptive execution environment at a given time.
11. The apparatus according to any preceding claim, wherein the threshold priority is indicated by threshold priority information stored in a software-writeable register.
12. The apparatus according to claim 11, wherein an encoding of the threshold priority information enables indication of a threshold priority for a given execution environment which is separate from a threshold priority associated with at least one other execution environment.
13. The apparatus according to any of claims 11 and 12, wherein 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 writes to the control register by software executing at a given exception level are not permitted when the given exception level is lower than an exception level responsible for switching between security states.
15. The apparatus according to claim any preceding claim, wherein the first exception is signalled on a first input pin to the processing circuitry and the second exception is signalled on a second input pin to the processing circuitry, wherein the first input pin is separate from the second input pin.
16. The apparatus according to claim any preceding claim, 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 circuitry, and that the interrupt priority exceeds the threshold priority, the exception signalling circuitry is configured to signal the first exception regardless of a current priority level of processing being performed by the processing circuitry.
17. The apparatus according to any preceding claim, 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 from an interrupt priority space associated with another execution environment.
18. The apparatus according to any preceding claim, comprising a pending interrupt configuration register accessible to 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 indicating one or more execution environments having a pending interrupt
19. A method comprising: detecting a first interrupt to be handled by processing circuitry operating in a target execution environment; and signalling exceptions to the processing circuitry in response to taken interrupts; wherein the method comprises in response to determining that the first interrupt meets at least one criterion, the at least one criterion comprising determining that the target execution environment is an execution environment other than an active execution environment of the processing circuitry: in response to a determination that an interrupt priority associated with the first interrupt exceeds a threshold priority, signalling a first exception to pre-emptively trigger a given action, wherein switching from the active execution environment to the target execution environment is dependent on the given action being performed; and in response to a determination that the interrupt priority does not exceed the threshold priority, signalling a second exception without pre-emptively triggering the given action.
20. A computer-readable medium to store computer-readable code for fabrication of an apparatus comprising: interrupt detection circuitry configured to detect a first interrupt to be handled by processing circuitry operating in a target execution environment; and exception signalling circuitry configured to signal exceptions to the processing circuitry in response to taken interrupts; wherein in response to determining that the first interrupt meets at least one criterion, the at least one criterion comprising determining that the target execution environment is an execution environment other than an active execution environment of the processing circuitry, the exception signalling circuitry is configured to: in response to a determination that an interrupt priority associated with the first interrupt exceeds a threshold priority, signal a first exception to pre-emptively trigger a given action, wherein switching from the active execution environment to the target execution environment is dependent on the given action being performed; and in response to a determination that the interrupt priority does not exceed the threshold priority, signal a second exception without pre-emptively triggering the given action.