Exception Control

Abstract

The exception control circuit (40) controls exception taking by the processing circuit (4) depending on control information stored in at least one register (14), the control information including masking control information that can be set to a masked state or an unmasked state and trap mask exception control information that can be set to a non-trapped state or a trapped state. In response to a given exception of a maskable class, in at least one scenario when the masking control information is in the masked state and the current exception level is less privileged than the predetermined trap target exception level, the exception control circuit controls whether to trap the given exception to the predetermined trap target exception level depending on whether the trap mask exception control information is in the trapped state. When the masking control information is in the unmasked state, the target exception level for handling the given exception is selected independently of the trap mask exception control information.

Description

[Technical Field]

[0001] The present technology relates to the field of data processing, and more particularly to exception handling.

[0002] While performing data processing, the processing circuitry may encounter an exception, which is an event that requires the normal flow of program execution to be interrupted so that processing can switch to an exception handler to deal with the event that caused the exception. For example, an exception may occur for a number of reasons, such as the execution of an undefined instruction, an address fault occurring due to a memory access where the virtual to physical address translation mapping is undefined or where a memory access permission check fails, or the occurrence of an external event such as a memory system error, or the detection of an interrupt event signaled by an external device or peripheral.

[0003] At least some examples include an apparatus comprising: a processing circuit that performs data processing at one of a plurality of exception levels supported by the processing circuit; and exception control circuitry that controls exception taking by the processing circuit depending on control information stored in at least one register, the control information including at least masking control information settable to one of a masked state and an unmasked state, and trap mask exception control information settable by software to one of an untrapped state and a trapped state, wherein in response to a given exception of a maskable class of exceptions that is maskable based on setting the masking control information to the masked state, the exception control circuitry is configured to An apparatus is provided that is configured to: determine whether a given exception is in a masked state; in at least one scenario where the given exception occurs when the masking control information is in the masked state and the current exception level is less privileged than a predetermined trap target exception level associated with the trap mask exception control information; control whether to trap the given exception to a predetermined trap target exception level depending on whether the trap mask exception control information is in the trapped state; and if the masking control information is in the unmasked state and it is determined that the given exception is unmasked, select a target exception level for handling the given exception, wherein the target exception level is selected independently of the trap mask exception control information.

[0004] At least some examples provide computer-readable code for manufacturing the apparatus described above. The computer-readable code can be stored on a storage medium. The storage medium can be a transitory or non-transitory storage medium.

[0005] At least some examples include a method comprising: performing data processing at one of a plurality of exception levels supported by a processing circuit; and controlling exception taking by the processing circuit dependent on control information stored in at least one register, the control information including at least masking control information settable by software to one of a masked state and an unmasked state, and trap mask exception control information settable by software to one of an untrapped state and a trapped state; and, in response to a given exception of a maskable class of exceptions that is maskable based on setting the masking control information to the masked state, the method comprises: determining whether the given exception is in a masked state; in at least one scenario where the given exception occurs when the masking control information is in a masked state and the current exception level is less privileged than a predetermined trap target exception level associated with the trap mask exception control information, controlling whether to trap the given exception to a predetermined trap target exception level depending on whether the trap mask exception control information is in a trapped state; and when the masking control information is in an unmasked state and it is determined that the given exception is unmasked, selecting a target exception level for handling the given exception, wherein the target exception level is selected independently of the trap mask exception control information.

[0006] At least some examples include a computer program including instructions that, when executed by a host data processing apparatus, control a host data processing apparatus to provide an instruction execution environment for executing target code, the computer program including: processing program logic that simulates execution of instructions of the target code at one of a plurality of exception levels; and exception control program logic for simulating taking an exception depending on control information stored in at least one storage location of the host data processing apparatus that represents at least one register of a target instruction set architecture used by the target code, the control information including at least masking control information that can be set to one of a masked state and an unmasked state, and trap mask exception control information that can be set by software to one of an untrapped state and a trapped state; and wherein, in response to a given exception from a maskable class of exceptions that is maskable based on software setting the trapping control information to a masked state, the exception control program logic is configured to: determine whether the masking control information is in a masked state; control whether to trap the given exception to a predetermined trap target exception level depending on whether the trap mask exception control information is in a trapped state in at least one scenario in which the given exception occurs when the masking control information is in a masked state and a current exception level is less privileged than a predetermined trap target exception level associated with the trap mask exception control information; and select a target exception level for handling the given exception when the masking control information is in an unmasked state and it is determined that the given exception is unmasked, wherein the target exception level is selected independently of the trap mask exception control information.

[0007] The computer program may be stored on a storage medium, which may be a temporary or non-transitory storage medium. [Brief explanation of the drawings]

[0008] Further aspects, features, and advantages of the present technology will become apparent from the following description of examples, read in conjunction with the accompanying drawings. [Figure 1] 1 illustrates a schematic diagram of an example of a data processing device; [Figure 2] FIG. 1 illustrates several exception levels at which a processing circuit can perform data processing. [Figure 3] FIG. 10 is a diagram showing control information stored in a register. [Figure 4] 10 is a flow diagram illustrating determining whether a given exception of a maskable class of exceptions should be masked. [Figure 5] 10 is a flow diagram illustrating a determination of whether to trap a given exception to a predetermined trap target exception level depending on whether masking control information is in a masked state and whether trap mask exception control information is in a trapped state. [Figure 6] 10 is a flow diagram illustrating control of updates to trap mask exception control information. [Figure 7] 10 is a flow diagram illustrating control of whether an exception of a non-maskable class of exception is trapped to a predetermined trap target exception level based on trap mask exception control information. [Figure 8A] A specific example of determining whether a given exception of a maskable class of exceptions should be masked and, if not masked, what exception level is the target exception level at which the given exception is taken is given. [Figure 8B] A specific example of determining whether a given exception of a maskable class of exceptions should be masked and, if not masked, what exception level is the target exception level at which the given exception is taken is given. [Figure 8C] A specific example of determining whether a given exception of a maskable class of exceptions should be masked and, if not masked, what exception level is the target exception level at which the given exception is taken is given. [Figure 8D]A specific example of determining whether a given exception of a maskable class of exceptions should be masked and, if not masked, what exception level is the target exception level at which the given exception is taken is given. [Figure 8E] A specific example of determining whether a given exception of a maskable class of exceptions should be masked and, if not masked, what exception level is the target exception level at which the given exception is taken is given. [Figure 8F] A specific example of determining whether a given exception of a maskable class of exceptions should be masked and, if not masked, what exception level is the target exception level at which the given exception is taken is given. [Figure 8G] A specific example of determining whether a given exception of a maskable class of exceptions should be masked and, if not masked, what exception level is the target exception level at which the given exception is taken is given. [Figure 8H] A specific example of determining whether a given exception of a maskable class of exceptions should be masked and, if not masked, what exception level is the target exception level at which the given exception is taken is given. [Figure 8I] A specific example of determining whether a given exception of a maskable class of exceptions should be masked and, if not masked, what exception level is the target exception level at which the given exception is taken is given. [Figure 8J] A specific example of determining whether a given exception of a maskable class of exceptions should be masked and, if not masked, what exception level is the target exception level at which the given exception is taken is given. [Figure 8K] A specific example of determining whether a given exception of a maskable class of exceptions should be masked and, if not masked, what exception level is the target exception level at which the given exception is taken is given. [Figure 8L]A specific example of determining whether a given exception of a maskable class of exceptions should be masked and, if not masked, what exception level is the target exception level at which the given exception is taken is given. [Figure 8M] A specific example of determining whether a given exception of a maskable class of exceptions should be masked and, if not masked, what exception level is the target exception level at which the given exception is taken is given. [Figure 8N] A specific example of determining whether a given exception of a maskable class of exceptions should be masked and, if not masked, what exception level is the target exception level at which the given exception is taken is given. [Figure 8O] A specific example of determining whether a given exception of a maskable class of exceptions should be masked and, if not masked, what exception level is the target exception level at which the given exception is taken is given. [Figure 9A] A specific example of determining a target exception level for an exception of a non-maskable class of exception is given. [Figure 9B] A specific example of determining a target exception level for an exception of a non-maskable class of exception is given. [Figure 9C] A specific example of determining a target exception level for an exception of a non-maskable class of exception is given. [Figure 9D] A specific example of determining a target exception level for an exception of a non-maskable class of exception is given. [Figure 9E] A specific example of determining a target exception level for an exception of a non-maskable class of exception is given. [Figure 9F] A specific example of determining a target exception level for an exception of a non-maskable class of exception is given. [Figure 9G] A specific example of determining a target exception level for an exception of a non-maskable class of exception is given. [Figure 9H] A specific example of determining a target exception level for an exception of a non-maskable class of exception is given. [Figure 9I] A specific example of determining a target exception level for an exception of a non-maskable class of exception is given. [Figure 10A] 1 is a table showing whether a given exception of a maskable class is masked, and if not masked, at what exception level the given exception is taken, depending on the current exception level and control information when the given exception occurs. [Figure 10B] 1 is a table showing whether a given exception of a maskable class is masked, and if not masked, at what exception level the given exception is taken, depending on the current exception level and control information when the given exception occurs. [Figure 11] 10 is a table illustrating the selection of a target exception level for a non-maskable class depending on the current exception level and control information when a given exception occurs. [Figure 12] FIG. 10 is a diagram illustrating an example of a simulation.

[0009] The apparatus has a processing circuit for performing data processing at one of a plurality of exception levels, and an exception control circuit for controlling the taking of exceptions by the processing circuit in dependence on control information stored in at least one register, the control information affecting whether the exception is masked or taken, and if taken, which exception level is the target exception level at which the exception is taken.

[0010] The control information includes masking control information that can be set to one of a masked state and an unmasked state. The masking control information can be set to the masked state automatically by hardware of the processing circuitry or exception control circuitry in response to a particular event (e.g., the masking control information can be set to the masked state in response to taking an exception) and / or can be set by software running at a given exception level to control whether maskable class exceptions are masked and prevent them from being taken at the given exception level. If taking an exception is set in hardware, software can control when the masking control information is cleared to the unmasked state. For example, an instruction may be supported in the instruction set architecture to allow software to trigger setting the masking control information to the masked or unmasked state as needed. If set to the masked state by software, software can choose to set the masking control information to the masked state for any reason when it is desirable to temporarily disable taking an exception. Regardless of whether the masking control information is set in hardware or software, one reason for masking an exception may be to preserve state information associated with processing currently being executed by software, which may be overridden if the exception is taken.

[0011] However, other software executing on the processing circuit (e.g., monitoring software such as a hypervisor or security monitor) may consider a maskable class exception to be an important exception that should be dealt with promptly when the processing circuit (either in hardware or under software control) is operating at a less privileged exception level, regardless of whether the masking control information has been set to a masked state. For example, if a maskable class exception represents the detection of an error, there may be a concern that delaying the handling of the exception due to masking based on the masking control information could risk the error propagating (e.g., an erroneous value stored in memory could be processed by other operations, propagating the error to other locations in memory) and making the problem worse. One approach to ensuring that maskable class exceptions are handled promptly may be to provide a control that software at the more privileged exception level can set to indicate that a maskable class exception should be taken at its more privileged exception level, thereby overriding masking based on the masking control information even when the masking control information is in a masked state. However, the problem with this approach is that when this control is set, the handling of maskable class exceptions is always removed from the normal default level for handling exceptions, which can increase the complexity of software development because more coordination may be required between different software developers developing software that runs at different exception levels.

[0012] In an example described below, the control information includes trap mask exception control information that can be set by software to one of an untrapped state and a trapped state. In response to a given exception from a maskable class of exceptions that is maskable based on setting the masking control information to the masked state, the exception control circuitry determines whether the masking control information is in the masked state, controls whether to trap the given exception to a predetermined trap target exception level depending on whether the trap mask exception control information is in the trapped state in at least one scenario in which the given exception occurs when the masking control information is in the masked state and a current exception level is less privileged than a predetermined trap target exception level associated with the trap mask exception control information, and selects a target exception level for handling the given exception when the masking control information is in the unmasked state and it is determined that the given exception is unmasked, where the target exception level is selected independently of the trap mask exception control information.

[0013] The trap mask exception control information thus provides an architectural control option that can be used to configure exception handling circuitry so that, when the masking control information is set to a masked state, an exception can be trapped to a predetermined trap target exception level to reduce delays in handling the exception. However, this trapping based on the trap mask exception control information is conditional on the masking control information being set to a masked state. If the masking control information is in an unmasked state and a given exception is unmasked, the exception can be taken at the selected target exception level regardless of the trap mask exception control information. In practice, because the masking control information is typically set to a masked state for a relatively small portion of execution time, this can significantly reduce the number of occasions where a maskable class of exception must be trapped to an exception level that is more privileged than the default level at which the exception is normally taken. Compared to a control option that indicates that all exceptions of the maskable class should be trapped to a more privileged exception level (regardless of the state of the masking control information), this allows a larger portion of exceptions to be handled at the less privileged exception level, enabling "kernel-first" exception handling, where less privileged software can handle maskable class exceptions most of the time (rather than "firmware-first" exception handling, where more privileged code typically handles most exceptions). Kernel-first exception handling is often preferred because it can simplify software development compared to firmware-first exception handling. Therefore, processors that support instruction set architectures that support trap mask exception control information are improved compared to processors that do not support trap mask exception control information, because it is easier for software developers to develop software for them.

[0014] In response to an instruction requesting an update to the trap mask exception control information being executed at an exception level less privileged than a predetermined trap target exception level associated with the trap mask exception control information, the processing circuitry may deny or trap the requested update to the trap mask exception control information. Thus, the trap mask exception control information may be restricted to being set by software executing at (or set by) a more privileged exception level at which the exception is trapped. Thus, the trap mask exception control information may be viewed as an architectural control option that allows more privileged code to override preferences (associated with operating at less privileged exception levels) to mask maskable class exceptions based on the masked state of the masking control information.

[0015] In some instances, there may be only a single item of trap mask exception control information that controls whether a trap dependent on the masking control information is taken for a particular exception level.

[0016] However, it may be useful to provide multiple items of trap mask exception control information, each associated with a respective one of the multiple predetermined trap target exception levels. In at least one scenario in which a given exception occurs when the masking control information is in a masked state and the current exception level is less privileged than the given one of the multiple predetermined trap target exception levels, the exception control circuitry may control whether a given exception is trapped to a given one of the multiple predetermined trap target exception levels depending on whether the trap mask exception control information of the corresponding item associated with the given one of the multiple predetermined trap target exception levels is in a trapped state. By providing multiple items of trap mask exception control information that can be set by more privileged software at different exception levels, this gives multiple more privileged software (e.g., hypervisor and security monitor code) separate control over whether an exception should be trapped rather than masked when the masking control information is set to a masked state. This may provide additional flexibility to different software providers to influence how maskable class exceptions are handled.

[0017] In at least one scenario in which a given exception occurs when the masking control information is in a masked state, at least two items of the trap mask exception control information are in a trapped state, one or more conditions for trapping to a predetermined trap target exception level are satisfied for each of the at least two items of the trap mask exception control information, and the exception control circuitry is configured to trap the given exception to a predetermined trap target exception level associated with a selected item of the trap mask exception control information, the selected item of the trap mask exception control information including one of the at least two items of the trap mask exception control information that has the smallest difference in privilege between the current exception level and the predetermined trap target exception level associated with the item of the trap mask exception control information. Thus, when two or more items of the trap mask exception control information are set to a trapped state (e.g., by software at different exception levels), if an exception is trapped based on the trap mask exception control information, it will be at the least privileged of the predetermined trap target exception levels associated with the items of the trap mask exception control information that are set to the trapped state. This can be considered counterintuitive because it differs from other exception handling controls, which typically assume that when there are conflicting controls set by software at different exception levels, the control set at the more privileged exception level should take precedence. However, allowing an entry of trap mask exception control information associated with a less privileged exception level to take precedence even if the more privileged exception level also sets the trap mask exception control information to the trapped state can be useful because taking an exception at the lowest privileged exception level available for taking the exception can simplify software development.

[0018] When the trap mask exception control information is in the untrapped state, the exception control circuitry may determine whether a given exception is masked depending at least on whether the masking control information is in the masked state. Whether a given exception is masked may also depend on other factors. For example, if a trap is taken based on the trap mask exception control information, the exception will not be masked even if the masking control information is in the masked state.

[0019] There may also be other reasons for masking an exception, which may be based, for example, on the current privilege level at the time the exception occurs. For example, the exception control circuit may determine whether a given exception is masked depending on whether the current exception level is more privileged than the exception level at which the given exception would be taken if the exception level were taken when the trap mask exception control information is in the untrapped state. This is useful because if the current exception level is more privileged than the exception level at which the exception would normally be handled (without considering trapping based on the trap mask exception control information), it can be assumed that the current handling is considered more important than handling the exception, and therefore the exception can be considered implicitly masked, regardless of whether the masking control information is in the masked state.

[0020] Also, even if the masking control information is in the masked state, an exception is not always masked if there is no trap based on the trap mask exception control information. For example, as described in more detail below, it is also possible to provide an architectural control option that allows software to express that, in at least some scenarios, an exception of a maskable class should be treated as if it were non-maskable, such that a given exception cannot be masked even if the masking control information is in the masked state.

[0021] Thus, generally, when the trap mask exception control information is in the untrapped state, the exception control circuitry is configured to determine whether a given exception is masked depending at least on whether the masking control information is in the masked state, although it will be appreciated that in some implementations the determination of whether an exception is actually masked may also take into account several other parameters.

[0022] In some examples, the control information includes non-maskable exception control information settable to one of a non-maskable state and a maskable state to indicate whether an exception of the maskable class is maskable, and in at least one scenario when the non-maskable exception control information is in the non-maskable state, the exception control circuitry is configured to determine that the given exception is not masked even when the masking control information is set to the masked state. This control may be useful for allowing more privileged software to express a preference that exceptions of the maskable class should be treated as non-maskable to ensure faster processing, regardless of whether the masking control information is set to the masked state.

[0023] In a scenario where a given exception occurs when the current exception level is the least privileged exception level, the non-maskable exception control information is in the non-maskable state, and when the given exception is not masked and the trap mask exception control information is in the not-trapped state, the given exception is taken to the next least privileged exception level enabled for taking the given exception, and the exception control circuit is configured to control taking the given exception at the next least privileged exception level without trapping to the predetermined trap target exception level, even if the trap mask exception control information is in the trapped state. Thus, when the current exception level is the least privileged level, the non-maskable exception control information in the non-maskable state also overrides any trapping based on the trap mask exception control information. Note that the next least privileged exception level enabled for taking the given exception may change based on other control information. For example, control information specifying whether the system is in a guest operating system regime (where the hypervisor manages guest operating systems but does not execute operating system functions itself) or a host operating system regime (where the hypervisor also manages applications and executes operating system functions) can control whether the exception level used for guest operating systems in the guest operating system regime is disabled in the host operating system regime; thus, the next lowest privileged exception level enabled can be the kernel-level exception level (where the guest operating system executes) in the guest operating system regime, and the hypervisor-level exception level (where the hypervisor / host operating system executes) in the host operating system regime.

[0024] If the current exception level is not the least privileged exception level, the non-maskable exception control information in the non-maskable state can override the masking itself, but does not override any traps that are determined to be necessary based on the trap mask exception control information being in the trapped state and the masking control information being in the masked state. This is because setting the masking control information to the masked state indicates that not taking the exception is preferred in order to preserve some state that may be overridden when taking the exception (given the current state of processing at the default exception level at which the exception is usually taken by default), and therefore, even if the exception is not actually masked, it may still be preferable to take the exception at a higher level by triggering a trap to the predetermined trap target exception level.

[0025] In some examples, the control information comprises multiple items of non-maskable exception control information associated with different exception levels, and the exception control circuit determines whether a given exception is masked depending on one of the multiple items of non-maskable exception control information selected based on the current exception level. This provides flexibility for different providers of software running at different exception levels to express independent preferences for whether to allow masking of maskable class exceptions.

[0026] It will therefore be appreciated that the exact decision of whether to make a trap at a given trap target exception level may depend on several factors, including (in some implementations) the current exception level and (for at least one exception level) the current state of the non-maskable exception control information, in addition to the masking control information and trap mask exception control information.

[0027] In some implementations, there may be other (optional) controls that override the trap mask exception control information, so that even if the above conditions for taking a trap are met (masking control information is in the masked state, the current exception level is less privileged than the predetermined trap target exception level associated with the trap mask exception control information, and the trap mask exception control information is in the trapped state), the trap to the predetermined trap target exception level may still not be taken (e.g., because another control specifies that exceptions of the maskable class should be trapped to a different exception level).

[0028] For example, the control information may include trap control information of at least one further item settable by software to one of a trapped state and an untrapped state, and the exception control circuit may control whether to trap at least a maskable class of exception to a particular exception level depending on whether the trap control information of the further item is in the trapped state, and the trap control information of the at least one further item takes precedence over the trap mask exception control information, so that when the trap control information of the further item is in the trapped state, the exception control circuit is configured to trap the exception to a particular exception level based on the trap control information of the further item, regardless of whether the trap mask exception control information is in the trapped state. For example, this further item of control information may be similar to the control described above for comparison, meaning that a maskable class of exception can be trapped to a particular more privileged exception level regardless of whether the masking control information is in the masked state. Therefore, the use of the trap mask exception control information may be relevant when the trap control information of the at least one further item is in the untrapped state, but not when the trap control information of the at least one further item is in the trapped state.

[0029] In some cases, at least one of the further items of trap control information may be specific to a maskable class of exception, another class of exception not affected by that item of trap control information.

[0030] It is also possible that at least one of the further items of trap control information is a more general control that affects the handling of both the maskable class of exceptions and at least one other class of exceptions.

[0031] Thus, there are many ways in which the trap mask exception control information can be used, depending on which additional architectural control settings are supported and how the information defining those architectural control settings is configured. In general, in at least one scenario in which a given exception occurs when the masking control information is in a masked state and the current exception level is less privileged than the predetermined trap target exception level associated with the trap mask exception control information, it is useful to provide trap mask exception control information that controls a trap to a predetermined trap target exception level depending on whether the trap mask exception control information is in a trapped state, but does not affect the selection of a target exception level when the maskable exception is unmasked when the masking control information is in an unmasked state. However, it is not required that the trap mask exception control information be taken into account in all scenarios in which an exception can occur.

[0032] A maskable class of exception can be any class of exception that can be optionally masked, but may sometimes need to be handled more quickly.

[0033] However, the techniques described above may be particularly useful when the maskable class of exceptions includes asynchronous system error exceptions, which indicate deviations from correct service. Error exceptions indicate deviations from correct service, such as when a device (or an external device) fails to conform to its correct functional specifications. This may be distinct from other fault causes (such as memory management faults or undefined instruction errors) in which the hardware system itself is functioning correctly but software configuration information is incorrectly configured (e.g., an undefined instruction is provided, a page table mapping is not specified for an address being accessed in memory, or memory access permissions are violated (e.g., writing to a read-only region of memory)). While error exceptions often occur following a memory system access, they may also occur for other reasons (e.g., a failure in a processing circuit's register). Asynchronous exceptions are exceptions that cannot be attributed to a specific point in the instruction stream being executed. For example, with asynchronous exceptions, unlike synchronous exceptions, which can be attributed to a specific point in the instruction stream, it may not be possible to clearly determine which instructions are older instructions not affected by the error and which are newer instructions potentially affected by the error. Asynchronous system error exceptions can have several causes, but a common example of an asynchronous system error may be a data abort triggered by a write-back of dirty data from a cache line to external memory.

[0034] Because delaying the handling of asynchronous system error exceptions can cause the error to propagate and cause larger problems, it may be desirable for such errors to be handled relatively quickly. However, it may also be desirable to support the ability for software or hardware to specify, using masking control information, that an error exception should be masked, to prevent important state information from being overridden when taking the exception. Providing trap mask exception control information allows a compromise whereby, in the majority of cases when an asynchronous system error exception is unmasked, the exception can be handled kernel-first, but there is a safety net that allows the exception to be handled firmware-first when the masking control information is set to a masked state.

[0035] The exception control circuit may also support a non-maskable class of exception that cannot be masked based on setting the masking control information to a masked state. Because this class of exception cannot be masked based on the masking control information, the above-mentioned problem of this masking causing a delay in exception handling is not expected to occur, and therefore, it is not necessary to trigger a trap based on the trap mask exception control information. However, the inventors recognized that even if a non-maskable class of exception is not actually masked, setting the masking control information to a masked state can indicate a preference that the exception not be executed in order to preserve important processor state that may be overridden when taking the exception. Therefore, even if a non-maskable class of exception is not maskable, it may still be useful to use the trap mask exception control information to control whether a trap to a given trap target exception level is taken when the masking control information is in a masked state. Thus, in at least one scenario in which a given exception occurs when the masking control information is in the masked state, the current exception level is less privileged than a predetermined trap target exception level associated with the trap mask exception control information, and the current exception level is an exception level that may be a target exception level for handling the exception, the exception control circuit may control whether to trap the non-maskable exception to the predetermined trap target exception level depending on whether the trap mask exception control information is in the trapped state. This helps reduce the possibility of important state being lost due to an override if an exception occurs when the masking control information is in the masked state.

[0036] If the current exception level is an exception level that cannot be the target exception level for handling the exception (e.g., the least privileged exception level), there is no need to trigger a trap for a non-maskable exception based on the trap mask exception control information.

[0037] A non-maskable class of exception may include, for example, a synchronous external abort exception, which indicates a deviation from correct service. Again, the deviation from correct service may be caused by any of the exemplary events described above for asynchronous system error exceptions, but in contrast to asynchronous exceptions, a synchronous exception is one that can be attributed to a particular point in the instruction stream being executed. For example, a synchronous exception may be an error (such as a failed error correcting code check) detected in a memory system following a demand memory access issued following execution of a specified instruction (as opposed to an error detected for a cache write-back, which would likely be treated as an asynchronous error), and therefore can be attributed to a particular point in the instruction stream.

[0038] The device may include multiple sets of one or more exception syndrome registers, each set storing exception syndrome information for an exception taken at a respective one of the exception levels. While software may choose to set the masking control information to the masked state for any software-specific reason, a typical reason for setting the masking control information to the masked state may be that if a previous exception has been handled and a subsequent exception is taken at that exception level, it is undesirable for information about the previous exception to be overwritten in the associated syndrome register of the current exception level. Thus, taking a trap at a given trap target exception level can help preserve information in the set of one or more syndrome registers associated with the current exception level, while still allowing the exception to be taken promptly. Thus, the above-described technique may be particularly useful in architectures in which banked sets of exception syndrome registers exist for a particular exception level, enabling concurrent register storage of exception information associated with exceptions being handled at different exception levels.

[0039] The techniques described above may be implemented in a hardware processor having hardware circuit features that provide the processing circuitry and exception control circuitry described above. The hardware device may have registers provided in the hardware for storing control information as described above.

[0040] However, in other examples, the techniques may be implemented in a program for controlling a host data processing apparatus to provide an instruction execution environment for executing the target code. The computer program for providing the simulation may be stored on a storage medium. The storage medium may be a temporary storage medium or a non-transitory storage medium.

[0041] Such a simulation computer program can be useful for enabling a target program developed according to a target instruction set architecture to be executed on a host data processing apparatus that does not itself support the target instruction set architecture. This can be useful for several reasons, such as enabling legacy code to be executed on newer devices that do not support the architecture for which the code was developed, or for testing a target program being developed for a new instruction set architecture to be released in the future before any hardware devices that support the new instruction set architecture are yet available. While a hardware-implemented device may have hardware circuitry that provides the above-mentioned features, a software simulation may provide corresponding software features, such as program logic and data structures, that emulate the functionality of the corresponding hardware, so that the target program can be executed on top of the simulation program to give the same results as if the target program had been executed by a corresponding hardware device that natively supports the target instruction set architecture.

[0042] Thus, the computer program may have processing program logic and exception control program logic that function similarly to the processing circuitry and exception control circuitry described above. The exception control program logic may control exception handling based on control information stored in at least one storage location of the host data processing apparatus that represents at least one register of the target instruction set architecture used by the target code. Simulated exceptions of a maskable class may be handled in the manner described above, with a trap to a predetermined trap target exception level controlled based on the trap mask exception control information when the masking control information is in a masked state. Thus, target code running on the simulation program (which may include respective software running at different simulated exception levels) may see the same effects as if it were running on a hardware apparatus that supports the same architectural control options discussed above.

[0043] FIG. 1 schematically illustrates an example of a data processing apparatus 2. The apparatus 2 has a processing pipeline 4 that provides processing circuitry for performing data processing in response to instructions. The processing pipeline 4 has a fetch stage 6 for fetching instructions to be executed from an instruction cache 8. A decode stage 10 decodes the fetched instructions and generates control signals for controlling subsequent stages of the pipeline 4 to perform the operations represented by the instructions. An issue stage 12 receives the decoded instructions and queues them while waiting for required operands to become available in registers 14. Once the required operands are determined to be available, the instruction is passed to an execute stage 16 that includes several execution units 18, 20, 22, 24 for performing processing operations in response to the instruction. The processing operations may use operands read from registers 14 to generate processing results that may be written back to registers 14 by a writeback stage 26 of the processing pipeline 4. Other examples may have different arrangements of pipeline stages (e.g., may include a register renaming stage for mapping architectural registers specified by the instruction to physical registers provided in hardware).

[0044] In this example, execution stage 16 includes, as execution units, an arithmetic / logic unit (ALU) 18 for performing arithmetic or logical operations on integer operands, a floating-point unit 20 for performing floating-point operations where at least one of the input and output operands is represented in floating-point representation, a branch unit 22 for evaluating the results of branch instructions to trigger non-sequential program flow, and a load / store unit 24 for controlling accesses to memory. Load / store unit 24 can execute load instructions that control the load / store unit 24 to load data from a memory system into registers 14, or store instructions that control load / store unit 24 to store data from registers 14 into the memory system. It will be understood that the particular set of execution units 18-24 shown in the example of FIG. 1 is just one possible implementation, and other implementations may have different sets of execution units. For example, one or more of the types of execution units shown in FIG. 1 may be omitted, or one of these types may be duplicated such that several execution units of the same type may be provided. Also, other types of execution units may be provided dedicated to processing other classes of processing operations not shown in FIG.

[0045] For load / store operations performed by load / store unit 24, the virtual address specified by the load / store instruction may be translated into a physical address by memory management unit 28 based on address mappings defined in page table data obtained from page table structures in the memory system. A translation lookaside buffer (TLB) 30 may be provided to cache page table entries from the page table structures for faster access by memory management unit 28.

[0046] In this example, the memory system includes a level 1 instruction cache 8, a level 1 data cache 32, a shared level 2 cache 34 used for either instructions or data, and main memory 36. However, it will be appreciated that this is only one example of a possible cache hierarchy, and other examples may have more cache levels or may have a different relationship between instruction and data caching.

[0047] Exception control circuitry 40 is provided to control exception handling for processing unit 2. Exception signal 42 is received by the exception control circuitry and may indicate when one of several exception conditions occurs. Exceptions may include several types of exceptions. For example, decode stage 10 may generate an undefined instruction exception when it encounters a fetched instruction corresponding to an undefined instruction encoding not supported by processing unit 2. MMU 28 may also generate an address fault exception if a load / store instruction specifies a target address that does not have a defined address mapping in the page table structure, or a target address that has a defined address mapping but the corresponding address mapping specifies access permissions that are not satisfied by the software process that issued the load / store instruction. Exception signal 42 may also be received to indicate whether an external interrupt has occurred, for example, due to a user pressing a button on a device containing processing unit 2 or receiving a message from an external device or peripheral, such as a message indicating that a network controller communicating with an external network has received a message. The memory system may also generate an exception signal when a memory system error is detected, such as the failure of a parity code or error correction code check used to detect errors in stored data caused by events such as a random bit flip due to particle impact, ionizing radiation or the aging effects of electronic components, a bus error due to an incorrect control setting on the memory system bus, or other condition that means a requested memory system operation cannot be performed correctly. It will be understood that many different types of exceptions can be defined and the above examples are not exhaustive.

[0048] When an exception occurs, the exception control circuitry can use the register state in registers 14 to determine whether the exception should be taken and, if so, what operational state the processing circuitry should be in when the exception is taken. When an exception occurs, the exception control circuitry 40 controls the pipeline to interrupt the processing currently being performed by the pipeline and switch to execution of an exception handler that can provide software instructions for responding to the event indicated by the exception type that occurred.

[0049] 2 is a diagram illustrating different execution states (also called exception levels) that processing circuitry 4 can operate in when executing instructions. In this example, there are four exception levels EL0, EL1, EL2, and EL3, with exception level EL0 being the least privileged exception level and exception level EL3 being the most privileged exception level. Generally, when executing at a more privileged exception level, processing circuitry can access some memory locations or registers 14 that are inaccessible to less privileged exception levels.

[0050] In this example, exception level EL0 is for executing applications managed by a corresponding operating system or virtual machine running at exception level EL1. When multiple virtual machines coexist on the same physical platform, a hypervisor operating at EL2 may be provided to manage each virtual machine. While Figure 2 shows an example in which the hypervisor manages the virtual machines and the virtual machines manage the applications, it is also possible for the hypervisor to directly manage applications at EL0 (in which case exception level EL1 may be disabled).

[0051] Although not required, some implementations may implement separate hardware-partitioned secure and non-secure operating domains for processing circuitry. Data processing system 2 may have hardware features implemented within its processor and memory systems to ensure that data and code associated with software processes running in the secure domain are isolated from access by processes running in the non-secure domain. For example, a hardware architecture such as the TrustZone® architecture offered by Arm® Limited of Cambridge, UK, may be used. Alternatively, other hardware-enforced security partitioning architectures may be used. Secure applications (trusted services) may run at exception level EL0 within the secure domain, and secure (trusted) operating systems or virtual machines may run at exception level EL1 within the secure domain. In some implementations, there is no support for EL2 in the secure state, and the hypervisor can only run at non-secure EL2. In other implementations, there may be support for a secure hypervisor running at secure EL2, as indicated by the asterisk in FIG. 2. In some examples, a secure monitor program may be provided running at exception level EL3 to manage transitions between the non-secure and secure domains. Other implementations may monitor transitions between security domains in hardware, such that a secure monitor program may not be required.

[0052] 3 shows a subset of registers 14. The registers include exception syndrome registers that are banked to provide separate sets of one or more exception syndrome registers for storing exception syndrome information for exceptions taken at each of exception levels EL1, EL2, and EL3 (the lowest privileged exception level EL0 does not require an exception syndrome register because it cannot take any exception levels). For example, the syndrome information associated with a taken exception may include information about the cause of the exception (e.g., fault type), information about the address associated with the exception, or any other information useful for enabling an exception handler to determine how to handle the exception.

[0053] FIG. 3 also illustrates a subset of control information that exception control circuitry 40 can use to control the handling of exceptions. It will be understood that FIG. 3 does not illustrate all of the registers provided in the processor, nor does it illustrate all of the control states provided in these registers. It will also be understood that the specific layout of control information across different registers can vary, and the same information can be represented in different formats. For example, information shown in FIG. 3 in different registers can be stored in the same register, or information shown in the same register in FIG. 3 can be stored in different registers. Thus, the specific register layout illustrated is not required, and other register layouts can be used to provide the same functionality of control options. The notation XXX_ELx.YYY refers to field YYY provided in register XXX and indicates that the lowest privileged exception level to which that register can be written is exception level ELx. If attempted at an exception level less privileged than the exception level ELx indicated in the register suffix, the write to the register will be denied or will trap to a higher exception level.

[0054] In this particular example, the control information includes: ● PSTATE.EL: Indicates the current exception level, PSTATE.A: Masking control information that can be set to one of a masked state (in this example, PSTATE.A=0b1) and an unmasked state (in this example, PSTATE.A=0b0). When in the masked state, this represents a preference for asynchronous exceptions (including the asynchronous memory system error exception, SError exception) that target the current exception level to be masked to prevent them from being taken until PSTATE.A is cleared to the unmasked state; however, this preference can be overridden by other control state options, as described below. For example, masking the asynchronous system error exception can be useful to protect information stored in the exception syndrome register (regarding the previous exception) that would otherwise be overridden if another exception were taken at the same exception level as the previous exception. Although not shown in Figure 3, the PSTATE register can also include additional mask fields for masking other classes of exceptions besides the asynchronous system error exception. However, the examples described below refer to the asynchronous system error (SError) exception as a specific example of a maskable class of exception. An asynchronous system error is an exception that is signaled when an error (a deviation from the correct functioning of the system hardware) that cannot be attributed to a specific point in the executed instruction stream is detected. ● SCR_EL3.EA: An example of further trap control that, when set to 0b1, causes certain classes of exceptions (e.g., synchronous external abort and asynchronous system error (SError) exceptions) to be routed to EL3 instead of the exception level that is handled when SCR_EL3.EA=0b0. ● HCR_EL2.TEA: Another example of a further trap control, when set to 0b1, causes external abort exceptions that occur at EL0, EL1, or EL2 to be routed to EL2 (if not routed to EL3 based on SCR_EL3.EA) instead of the exception level that is handled when HCR_EL2.TEA=0b0, unless HCR_EL2.TGE or another control requires routing to EL2 or EL3. HCR_EL2.TGE: Another example of further trap control, indicating whether to "trap general exceptions" to EL2. When set to 0b0, there is no effect on execution at EL0, and when set to 0b1, exceptions that would normally be routed from EL0 to EL1 are instead routed to EL2. This effectively disables EL1 from being available for taking exceptions, and software cannot reach EL1. If HCR_EL2.E2H is also 0b1, EL1 is completely disabled, and EL0 operates within the host operating system. If HCR_EL2.E2H is 0b0, exceptions are not taken to EL1, but EL1 control may still have an effect. HCR_EL2.AMO: Another example of a further trap control that indicates whether physical system error (SError) exceptions should be routed to EL2. When HCR_EL2.AMO=0b1, SError exceptions are taken to EL2 unless routed to EL3 based on SCR_EL3.EA. This is not required when HCR_EL2.AMO is 0b0 (unless HCR_EL2.TGE or another control requires routing to EL2). HCR_EL2.E2H: Indicates whether a configuration for running a host operating system (a Type 2 hypervisor) is supported at EL2, which can affect exception handling at lower levels such as EL0 (if a Type 2 hypervisor is supported, some exceptions that would otherwise be handled at EL1 may be handled at EL2 instead). When HCR_EL2.E2H=0b1, facilities for supporting a host operating system at EL2 are enabled. When HCR_EL2.E2H=0b0, facilities for supporting a host operating system at EL2 are disabled. SCR_EL3.NMEA, SCTLR2_EL2.NMEA, SCTLR2_EL1.NMEA: Respective items of non-maskable exception control information associated with exception levels EL3, EL2, and EL1, respectively, which can be set by software running at these exception levels (or more privileged exception levels) to control whether the SError exception is maskable using PSTATE.A, preventing the SError exception from being taken at these exception levels. Each of these can be set to one of a non-maskable state (e.g., 0b1) and a maskable state (e.g., 0b0). When in a non-maskable state, the SError exception can be taken at the corresponding exception level regardless of the value of PSTATE.A. When in a maskable state, the SError exception can be masked from being taken at the corresponding exception level based on PSTATE.A being set to a masked state (e.g., 0b1). Further details on how these controls affect the handling of the SError exception are provided below. ● SCR_EL3.TMEA, HCRX_EL2.TMEA: Trap mask exception control information associated with each item EL3 and EL2, respectively, which can be set to a trapped state (e.g., 0b1) to control whether an asynchronous Serror exception or a synchronous external abort exception is trapped to the corresponding exception level EL3 or EL2, or to an untrapped state (e.g., 0b0) where the trap does not occur, when PSTATE.A is in a masked state (0b1) and the current exception level is less privileged than the corresponding exception level EL3 or EL2. The TMEA control is overridden by any trap to EL2 or EL3 caused by one of the more general types of further trap controls (SCR_EL3.EA, HCR_EL2.TEA, HCR_EL2.TGE, and HCR_EL2.AMO), but unlike these further trap controls, the TMEA control is specific to when the masking control information is in the masked state (PSTATE.A=0b1) and does not affect the selection of the target exception level when the masking control information is in the unmasked state (PSTATE.A=0b0).

[0055] Therefore, the PSTATE.A flag can be used to protect the syndrome register from asynchronous exceptions. The flag is set by the processing circuit's hardware (automatically, without software intervention) when an exception is taken (i.e., the CPU populates the syndrome register), and can also be set / cleared by software executing instructions in the instruction set architecture that indicate that the PSTATE.A flag should be set or cleared. In most cases, in normal use, the flag is clear. When the flag is set, asynchronous exceptions are masked, i.e., not taken. This is a problem for asynchronous error exceptions, because failure to take an error exception quickly can cause the error to propagate. Furthermore, synchronous exceptions are non-maskable exceptions that are never masked, which means that an (unexpected) synchronous error exception can override the syndrome register, which is also a problem for error recovery.

[0056] One possible solution to this problem is to route error exceptions to higher exception levels, each with its own set of syndrome registers. This is known as firmware-first error handling. The problem with this approach is that it always removes error handling from the operating system at EL1 and requires complex software configuration to notify the operating system about the error and allow the operating system to recover. Also, it can be difficult to identify the root cause of an error when, as is often the case, firmware running at EL2 or EL3 is invisible to the system administrator.

[0057] The example described here introduces a new exception routing control, TMEA (Trap Mask Exception Control Information), that is under software control at higher exception levels, such as EL2 or EL3. When PSTATE.A is clear, error exceptions are considered normal to the default exception level, which normally handles them without routing to a higher exception level (assuming there is no trapping to EL2 or EL3 based on one of the other controls SCR_EL3.EA, HCR_EL2.TEA, HCR_EL2.TGE, and HCR_EL2.AMO). When PSTATE.A is set and TMEA (at a higher exception level) is set, error exceptions (both synchronous and asynchronous) are captured at the higher exception level, which sets the TMEA flag. For EL1 in the Arm architecture, there are two higher exception levels, EL2 and EL3, and as shown above, both have a TMEA flag that can be set. If both SCR_EL3.TMEA and HCRX_EL2.TMEA are set to the trapped state (0b1) and PSTATE.A is set, the exception is taken to the nearest of these higher exception levels (e.g., EL2 when at EL0 or EL1).

[0058] In this way, PSTATE.A can protect the syndrome register from unexpected error exceptions, but the TMEA control set by the higher exception level provides a "safety net" to ensure that the error does not propagate, since in the rare case that PSTATE.A is set to 0b1 to indicate masking, the exception can still be taken quickly to the higher exception level. However, in most cases, PSTATE.A is set to 0b0, so that the error exception can be handled directly at EL1 by the operating system.

[0059] Additionally, the operating system or higher exception levels can also set an NMEA control bit (orthogonal to TMEA) to indicate that asynchronous exceptions should be unmaskable regardless of PSTATE.A. NMEA control is provided for all exception handling exception levels EL1, EL2, and EL3. The following example shows how this control interacts with the other controls.

[0060] 4 is a flow diagram illustrating the determination of whether a given exception (e.g., an asynchronous system error exception) of a maskable class of exceptions should be considered masked to prevent it from being taken. In step 100, the exception control circuit 40 determines whether the current exception level is more privileged than the exception level that would be taken if the given exception of the maskable class were taken if the trap mask exception control information (i.e., the EL2 and EL3 TMEA controls) were in the untrapped state. Also, in step 102, the exception control circuit 40 determines whether the masking control information (PSTATE.A) is in the masked state.

[0061] If the current exception level is more privileged than the default exception level (which ignores TMEA-based trapping) that would handle the exception if adopted, or if the masking control information (PSTATE.A) is in a masked state, the exception is potentially masked, but can be overridden based on non-maskable exception control information (NMEA control, as described above). In step 104, the exception control circuit 40 determines whether the non-maskable exception control information (applicable NMEA control) selected based on the current exception level is set to a non-maskable state (e.g., 0b1). If the non-maskable exception control information is not in a non-maskable state (i.e., is in a maskable state, e.g., 0b0), the determination in step 100 or 102 that the exception should be masked is not overridden, and in step 106 the exception control circuit determines whether there is any reason to trap the exception despite being masked (e.g., based on TMEA control, as discussed in more detail with respect to FIG. 5). If there is no reason to trap the exception, in step 107 it is determined that the given exception is masked, and as a result, the exception is not taken.

[0062] If the non-maskable exception control information is in a non-maskable state (e.g., 0b1), or if step 106 determines that there is reason to trap the exception, then step 108 determines that the given exception is not masked, even though the outcome of one of steps 100 and 102 is yes, and as a result the exception is still taken (either because NMEA control has overridden the initial determination of masked status, or because there was a trap taken based on NMEA control or another control).

[0063] Generally, the applicable NMEA control to use in step 104 is selected based on the current exception level, although in some instances other control information may also be relevant. For example, as shown in more detail in FIG. 8E below, the applicable NMEA control may be SCR_EL3.NMEA if the current exception level is EL3, SCTLR2_EL2.NMEA if the current exception level is EL2, or SCTLR2_EL1 if the control information indicates that the processing circuit is currently operating in a host operating system regime. NMEA if the current exception level is EL1 or EL0 and the processing circuit is not currently operating in a host operating system regime. (See FIG. 8B for an example of how to determine whether the processing circuit is operating in a host operating system regime based on the E2H and TGE fields of HCR_EL2 and the current exception level.)

[0064] If the current exception level is not more privileged than the default exception level at which the given exception would be taken if the TMEA control is in an untrapped state (No in step 100) and the masking control information is not in a masked state (PSTATE.A=0b0), then in step 108 it is determined that the given exception is not masked and the exception is taken.

[0065] 5 is a flow diagram illustrating the steps for determining whether to trap a given exception of a maskable class based on trap mask exception control information (TMEA control). In step 120, the exception control circuit determines whether the masking control information is in a masked state (e.g., PSTATE.A=0b1). If not masked, in step 122, if the given exception is not determined to be masked according to FIG. 4, the given exception is taken at the selected target exception level regardless of the trap mask exception control information.

[0066] In step 124, the exception control circuit determines whether the current exception level is less privileged than the predetermined trap target exception level associated with the trap mask exception control information (e.g., at EL0 or EL1 if either the EL2 or EL3 version of the TMEA control is used, or at EL2 if the EL3 version of the TMEA control is used). If the current exception level is not less privileged than the exception level EL2 or EL3 associated with a given TMEA control, then that TMEA control is not relevant. If there are no relevant TMEA controls applicable to determine the handling of the exception at the current exception level, then in step 122 the given exception, if not masked, is taken at the selected target exception level regardless of the trap mask exception control information.

[0067] If the masking control information is in the masked state (YES in step 120) and the current exception level is less privileged than the predetermined trap target exception level (EL2 or EL3) associated with at least one item of the trap mask exception control information, then in step 126, the exception control circuit 40 controls whether to trap the given exception to the predetermined trap target exception level, depending on whether the trap mask exception control information is in the trapped state. If it is determined that a trap is not required, then in step 128, if the given exception is not masked, the given exception is taken at a default exception level without trapping based on the trap mask exception control information. This default exception level may change based on other control states (e.g., based on the EA, TEA, AMO, E2H, and TGE controls mentioned above—see more detailed examples below for how these can affect the target exception level in the absence of a TMEA-based trap). If it is determined that a trap is required based on the trap mask exception control information, then in step 130, the given exception is trapped to the predetermined trap target exception level associated with the item of the trap mask exception control information in the trapped state. If there are two or more associated items of trap mask exception control information in the trapped state, the trap is taken at the exception level associated with one of the items of trap mask exception control information in the trapped state (TMEA=0b1) that is different from the current exception level but has the smallest difference in privilege between the current exception level and the predetermined trap target exception level associated with it. For example, if the current exception level is EL1 and the TMEA controls for EL2 and EL3 are both set to 1, the trap is taken at EL2, and if the current exception level is EL2, the trap is taken at EL3 even if the TMEA controls for EL2 and EL3 are both set.

[0068] In step 126, the control of whether to trap based on the TMEA control may vary depending on which other controls are implemented. Generally, if there is no trap mask exception control information (TMEA control) associated with the trapped condition, no trap is taken. However, if there is an associated item of trap mask exception control information for the trapped condition, whether a trap occurs may also depend on other parameters. For example, if non-maskable exception control information (NMEA control) is supported, in some scenarios, an NMEA control set to a non-maskable state may override a trap based on the TMEA control in addition to overriding any masking based on PSTATE.A. For example, in a scenario in which a given exception occurs when the current exception level is the least privileged exception level (EL0), the non-maskable exception control information is in the non-maskable state (NMEA control = 0b1), the given exception is not masked, and the trap mask exception control information is in the not-trapped state (e.g., the next least privileged exception level may be EL1 in the guest operating system regime or EL2 in the host operating system regime), the given exception is taken to the next least privileged exception level enabled for taking the given exception, and the exception control circuit can determine that the given exception should be taken at the next least privileged exception level without trapping to the predetermined trap target exception level, even if the trap mask exception control information (TMEA) is in the trapped state. Another scenario in which the trap of step 130 does not occur despite the associated TMEA control being set to the trapped state may be when the aforementioned EA, AMO, or TGE control specifies that the exception should be routed to EL3 or EL2 (regardless of the value of the masking information PSTATE or the value of the TMEA control). Thus, in some examples, the decision whether to trap based on TMEA may be more complex than simply checking the state of the TMEA control itself. The particular decision flow may depend on which other control options are implemented in a particular embodiment.

[0069] Nevertheless, in general, it is useful to provide TMEA control to allow the user to define that in at least one scenario where the PSTATE.A flag is set to a masked state, a trap to a more privileged exception level is taken to allow two competing requirements to be met (the exception is handled quickly and the syndrome information associated with the less privileged exception level is preserved), without requiring that all exceptions be taken to a higher level when the PSTATE.A flag is in an unmasked state.

[0070] 6 is a flow diagram illustrating control of whether an update to trap mask exception control information (TMEA control information) is permitted. In step 150, an instruction requesting an update of the trap mask exception control information is executed. In step 152, processing circuit 4 determines whether the current exception level is less privileged than the predetermined trap target exception level associated with the trap mask exception control information requested to be updated (EL2 for HCRX_EL2.TMEA, EL3 for SCR_EL3.TMEA). If so, in step 154, the attempt to update the trap mask exception control information is either denied entirely or trapped to a more privileged exception level, so that software at the more privileged exception level can decide whether to permit the requested update. If the current exception level is the predetermined trap target exception level or an exception level more privileged than the predetermined trap target exception level, in step 156, the requested update to the trap mask exception control information is permitted at the current exception level (unless other controls are implemented that would cause such a write to the trap mask exception control information to be trapped for other reasons). For example, software in EL3 can set the controls to trap accesses to HCRX_EL2, causing writes from EL2 to the EL2 TMEA control to trap to EL3.

[0071] 7 is a flow diagram illustrating the handling of a class of non-maskable exceptions, e.g., a synchronous external abort exception. In step 160, a non-maskable exception of this class is detected. In step 162, the exception control circuitry determines whether the control information in register 14 indicates a scenario in which the current exception level is less privileged than a predetermined trap target exception level associated with a given item of trap mask exception control information and the current exception level can be the target exception level for handling the exception (e.g., EL0 cannot be the target exception level). If not, in step 164, a trap based on TMEA control is not needed and the non-maskable class exception is taken at a target exception level selected based on the current exception level and / or other control information (other than TMEA control).

[0072] If step 162 determines that the current exception level is less privileged than the predetermined trap target exception level associated with a given item of trap mask exception control information and the current exception level can be the target exception level for handling the exception (and optionally, in some instances at least one other condition is met, for example, depending on the SCR_EL3.EA or HCR_EL2.TEA control which may require different behavior for the trap indicated by the TMEA), then a trap based on the TMEA control (trap mask exception control information) is possible, but depending on other parameters.

[0073] In step 166, the exception control circuit determines whether the masking control information is in a masked state (e.g., PSTATE.A=0b1). If not, in step 168, a trap based on TMEA is not required and the non-maskable exception is taken at a target exception level selected based on the current exception level and / or other control information.

[0074] In step 170, the exception control circuit determines whether the trap mask exception control information is in a trapped state (eg, the associated TMEA control is set to 0b1).

[0075] If the masking control information is in the masked state (YES at step 166) and the trap mask exception control information is in the trapped state (YES at step 170), a trap is taken to the predetermined trap target exception level associated with the TMEA control that was set to the trapped state (again, if both TMEA controls are set and the current exception level is EL1, the trap is taken to EL2, which is the level closest in privilege to the current exception level). If the masking control information is in the unmasked state (PSTATE=0b0) or the trap mask exception control information is in the untrapped state (all TMEA controls are 0b0), then a TMEA-based trap is not taken (step 168), although this does not necessarily preclude a trap to a higher level for other reasons, such as based on the EA or TEA controls.

[0076] Therefore, even if the PSTATE.A flag does not cause masking of a non-maskable exception, it can be considered to control whether the exception is trapped to a more privileged level based on TMEA control. This is useful because preserving syndrome information is prioritized when the PSTATE.A flag is set, and therefore trapping to a higher exception level helps satisfy this requirement even if no masking actually exists. Nevertheless, making this trap conditional on PSTATE.A helps increase the use of kernel-prioritized exception handling, reducing the number of occasions where firmware needs to handle an exception and simplifying software development.

[0077] It will be understood that in those parts of the flowchart where the outcome depends on checking several conditions, those conditions may be checked in any order, or possibly at least partly in parallel, and so the particular order of steps shown in the flowchart is only one example of how this could be done.

[0078] A more detailed example of how the various items of control information described above can be used to control exception handling will now be described.

[0079] 8A-8O illustrate the handling of an asynchronous system error (SError) exception, which indicates that an error has been detected following a memory system access, where the error cannot be attributed to a specific point in the instruction stream and therefore it is unclear which instructions may be affected by the error. This is an example of the maskable class of exception discussed above. These figures collectively illustrate a process for determining whether an exception should be masked, and if not, which exception level should take the exception, based on the current exception level at the time of the exception and the control information shown in FIG. 3.

[0080] 8A illustrates the determination of the value route_to_el3, which indicates whether an SError exception should be routed from a lower exception level to be taken at EL3. If the current exception level is not EL3 (No in step 1000) and SCR_EL3.EA=0b1 (Yes in step 1002), then route_to_el3 is TRUE (step 1006), indicating that the exception is routed to EL3. If the current exception level is EL3 (Yes in step 1000) or SCR_EL3.EA=0b0 (No in step 1002), then route_to_el3 is FALSE (step 1004).

[0081] 8B illustrates the determination of the value IsInHost(), which indicates whether the process is currently in the host operating system regime (type 2 hypervisor). IsInHost() is FALSE if in the guest operating system regime and TRUE if in the host operating system regime. If the current exception level is neither EL2 (no in step 1008) nor EL0 (no in step 1014), IsInHost() is FALSE (step 1018). If the current exception level is EL2 (yes in step 1008) but HCR_EL2.E2H is 0b0 (no in step 1010), or if the current exception level is EL0 (yes in step 1014) and one or both of HCR_EL2.E2H and HCR_EL2.TGE are 0b0 (no in step 1016), IsInHost() is also FALSE (step 1018). If the current exception level is EL2 (Yes in step 1008) and HCR_EL2.E2H=0b1 (Yes in step 1010), or if the current exception level is EL0 (Yes in step 1014) and both HCR_EL2.E2H and HCR_EL2.TGE are set to 0b1 (Yes in step 1016), IsInHost() is TRUE (step 1012).

[0082] 8C illustrates the determination of the value route_to_el2, which indicates whether an SError exception should be routed from a lower exception level EL0 or EL1 and taken at EL2. If route_to_el3 is TRUE (No in step 1020), then route_to_el2 is FALSE (step 1032). If route_to_el3 is FALSE (Yes in step 1020) and the current exception level is EL2 or EL3 (No in both steps 1022 and 1030), then route_to_el2 is FALSE (step 1032).

[0083] If route_to_el3 is FALSE (Yes in step 1020) and the current exception level is EL1 (Yes in step 1022), In step 1026, if HCR_EL2.AMO is 0b1 (YES in step 1024), then route_to_el2 is TRUE; • In step 1028, if HCR_EL2.AMO is 0b0 (No in step 1024), then route_to_el2 is FALSE.

[0084] If route_to_el3 is FALSE (Yes in step 1020), the current exception level is EL0 (No in step 1022, Yes in step 1030), and IsInHost() determined in the process of FIG. 8B is TRUE (No in step 1034), or both HCR_EL2.E2H and HCR_EL2.TGE are set to 0b0 (Yes in step 1038), then route_to_el2 is FALSE (step 1036).

[0085] route_to_el3 is FALSE (Yes in step 1020), the current exception level is EL0 (No in step 1022, Yes in step 1030), IsInHost() is determined to be FALSE in the process of FIG. 8B (Yes in step 1034), one or both of HCR_el2.E2H and HCR_EL2.TGE are set to 0b1 (No in step 1038), and route_to_el2 is TRUE (Step 1040).

[0086] Figure 8D shows the determination of the value soft_masked, which represents the initial determination of whether the SError exception should be masked (this initial determination can be overridden based on non-maskable exception information (NMEA control), as described below in Figures 8E and 8F). The determination of soft_masked depends on the current exception level (step 1042).

[0087] If the current exception level is EL3, soft_masked is TRUE (step 1050), and SCR_EL3.EA=0b0 (yes in step 1044) or PSTATE.A=0b1 (yes in step 1046), and if SCR_EL3.EA=0b1 (no in step 1044) and PSTATE.A=0b0 (no in step 1046), soft_masked is FALSE (step 1048).

[0088] If the current exception level is EL2: • soft masked is FALSE (step 1054) if route_to_el3 determined in FIG. 8A is TRUE (No in step 1052). If route_to_el3 is FALSE (Yes in step 1052): If HCR_EL2.TGE and HCR_EL2.AMO are both 0 (YES in step 1056) or PSTATE.A=1 (YES in step 1058), then soft_masked is TRUE (step 1060). If one or both of HCR_EL2.TGE and HCR_EL2.AMO are 0b1 (step 1056 - No) and PSTATE.A=0 (step 1058 - No), then soft_masked is FALSE (step 1062).

[0089] If the current exception level is EL0 or EL1: • soft masked is FALSE (step 1070) if route_to_el3 determined in FIG. 8A is TRUE (step 1064: No) or if route_to_el2 determined in FIG. 8C is TRUE (step 1066: No). If both route_to_el3 and route_to_el2 are FALSE, then soft_masked is TRUE (step 1072) if PSTATE.A=1 (YES in step 1068) and FALSE (step 1070) if PSTATE.A=0 (NO in step 1068).

[0090] Note that steps 1044, 1056 are passed if the EA, TGE, AMO controls are not set to trap the SError exception to one of the higher levels, so the effect of steps 1044, 1056 is that the SError exception can be considered masked in step 1050 or 1060 if the current exception level (EL3 in the case of step 1050 or EL2 in the case of step 1060) is more privileged than the exception level specified to take the exception level (ignoring the TMEA trap control).

[0091] FIG. 8E illustrates the selection of which of the non-maskable exception control information (NMEA control) items to use to determine whether the masked status determined in FIG. 8D should be overridden. This depends on the current exception level and IsInHost() status determined in FIG. 8B. If the current exception level is EL3 (Yes in step 1076), the NMEA control to use is SCR_EL3.NMEA (step 1078). If the current exception level is EL2 (Yes in step 1080) or IsInHost() is TRUE (Yes in step 1084), the NMEA control to use is SCTLR2_EL2.NMEA (step 1082). If the current exception level is EL1 or EL0 (No in step 1080) and IsInHost() is FALSE (No in step 1084), the NMEA control selected is SCTLR2_EL1.NMEA (step 1086).

[0092] Figure 8F shows applying the selected NMEA control to determine whether to override the initial masked determination of Figure 8D and prevent masking of the SError exception. If soft_masked was already determined to be FALSE in the process of Figure 8D (No at step 1098), it remains FALSE regardless of the value of the selected NMEA control (step 1100). If soft_masked is TRUE (Yes at step 1098) and the selected NMEA control is in the unmaskable state 0b1 (No at step 1102), soft_masked becomes FALSE (step 1100), thereby overriding the previous masked status based on the unmaskable indication provided by the NMEA control. If soft_masked is TRUE (yes in step 1098) and the selected NMEA control is in the maskable state 0b0 (yes in step 1102), then soft_masked remains TRUE (step 1104), and thus the SError exception is masked, preventing it from being taken (although the exception remains pending and therefore may be taken later if the PSTATE.flag is later cleared to the unmasked state 0b0).

[0093] Figure 8G shows the determination of signal route_soft_masked_to_el2, which indicates whether a trap to EL2 should be taken, based on the EL2 version of the TMEA control, HCRX_EL2.TMEA. This is a trap taken when PSTATE.A=1, ensuring that the SError exception can be handled more quickly in EL2 while preserving the exception syndrome information in the EL1 set of syndrome registers.

[0094] In step 1122, parameter route_soft_masked_to_el2 is determined to be FALSE (i.e., no TMEA-based trap will occur) if either route_to_el3 determined in Figure 8A is TRUE (No in step 1108) or the external debugger has disabled exception taking at exception levels below EL3 (Yes in step 1110). Assuming neither of these conditions is met (Yes in step 1108, No in step 1110): • Whenever HCRX_EL2.TMEA is in a non-trapped state (0b0-N in step 1112), route_soft_masked_to_el2 is FALSE (step 1122) because in this case the EL2 software has not set trap mask exception control information to indicate that a trap to EL2 dependent on PSTATE.A is desired. If HCRX_EL2.TMEA is in a trapped state (0b1 - Yes in step 1112), a trap to EL2 by TMEA is possible, but whether this occurs also depends on other parameters: If the current exception level is EL1 (YES in step 1114) and PSTATE.A is in the masked state (0b1 - YES in step 1116), then route_soft_masked_to_el2 is TRUE (step 1118). If the current exception level is EL1 (step 1114: Yes), but PSTATE.A is in an unmasked state (0b0 - step 1116: No), then route_soft_masked_to_el2 is FALSE (step 1120). ○ If the current exception level is EL0 (Yes in step 1124), the masked status (after any NMEA overrides are evaluated) is TRUE (Yes in step 1126), and IsInHost() determined in Figure 8B is FALSE (Yes in step 1128), then route_soft_masked_to_el2 is TRUE (step 1130). Note that in step 1126, the term "soft_masked" refers to the final masked status determined based on NMEA in the process of Figure 8F, not the initial masked status determined in Figure 8D (before any NMEA overrides). If the current exception level is EL0 (Yes in step 1124), the masked status determined following the NMEA override in the process of FIG. 8F (not the initial masked status determined in FIG. 8D) is FALSE (No in step 1126), or IsInHost() determined in FIG. 8B is TRUE (No in step 1128), then route_soft_masked_to_el2 is FALSE (step 1122). If the current exception level is EL2 or EL3 (step 1124: No), then route_soft_masked_to_el2 is FALSE (step 1122).

[0095] Figure 8H shows the decision of signal route_soft_masked_to_el3, which indicates whether to take a trap to EL3, based on the EL3 version of the TMEA control, SCR_EL3.TMEA. Again, this trap is intended to allow SError exceptions to be handled more quickly in EL3, while still allowing preservation of exception syndrome information in the EL1 or EL2 set of the syndrome register when PSTATE.A=1.

[0096] If handling of exceptions in EL3 is disabled by the external debugger (step 1136: Yes), then route_soft_masked_to_el3 is FALSE (step 1134).

[0097] If SCR_EL3.TMEA is in an untrapped state (0b0-N in step 1138), then route_soft_masked_to_el3 is FALSE (step 1134) because in this case the EL3 software has not expressed any preference to avoid masking SError exceptions at lower levels when PSTATE.A=1.

[0098] If there is no external debugger disabling exceptions at EL3 (No in step 1136) and SCR_EL3.TMEA is in a trapped state (0b1 - Yes in step 1138), a trap to EL3 by TMEA is possible, but whether this happens also depends on other parameters: If either route_to_el2 or route_soft_masked_to_el2 is TRUE (No in step 1140 or step 1142): route_soft_masked_to_el3 is TRUE (step 1154) if the current exception level is less privileged than EL3 (No in step 1152) and taking exceptions at levels less privileged than EL3 is currently disabled by the external debugger (Yes in step 1150); and route_soft_masked_to_el3 is FALSE (step 1156) if the current exception level is EL3 (Yes in step 1150) or if taking exceptions at privilege levels lower than EL3 is not currently disabled by an external debugger (No in step 1152).

[0099] Thus, in the absence of an external debugger disabling exception handling at EL0-EL2, a TMEA trap to EL2 as determined in Figure 8G takes precedence over a TMEA trap to EL3, and if both SCR_EL3.TMEA and HCRX_EL2.TMEA are set to the trapped state per step 1142, the trap is taken to EL2, the closest exception level (smallest difference in privilege) to the EL1 / EL0 level at which an SError can occur if HCRX_EL2.TMEA is relevant. If route_to_el2 and route_soft_masked_to_el2 are both FALSE (Yes in steps 1140 and 1142), then route_soft_masked_to_el3 is TRUE (step 1146) if either: The current exception level is EL2 or EL1 and PSTATE.A is in a masked state (0b1 - Yes in step 1144), or ○ If the current exception level is EL2 or EL0 and the masked status is TRUE (Yes in step 1148). Again, soft_masked in step 1148 refers to the masked status following the NMEA override in the process of Figure 8F (not the initial masked status determined in Figure 8D). ●route_soft_masked_to_el3 may also be TRUE (step 1154) if route_to_el2 and route_soft_masked_to_el2 are both FALSE (Yes in steps 1140 and 1142), none of the conditions tested in steps 1144, 1148 are met, the current exception level is less privileged than EL3 (No in step 1150), and taking exceptions at levels less privileged than EL3 is currently disabled by the external debugger (Yes in step 1152).

[0100] Note the difference between steps 1116 and 1126 in FIG. 8G and steps 1144 and 1148 in FIG. 8H. For exceptions that occur when the current exception level is EL1, the TMEA trap depends on PSTATE.A being 1, regardless of whether the actual masking status determined in FIG. 8F was overridden using NMEA controls. This is because setting PSTATE.A to a masked state (0b1) in EL1 indicates that the current state of processing in EL1 is such that there is some important syndrome information in the EL1 syndrome register that should be protected, and therefore, even if masking has been overridden using NMEA controls, it is still desirable to perform a TMEA trap to EL2 or EL3 to protect the syndrome information in the EL1 syndrome register. In contrast, for exception level EL0, the TMEA trap depends on the actual masking status determined in FIG. 8F (after it has been overridden using NMEA controls). Thus, an NMEA control set to 1 prevents a TMEA trap from being taken from EL0 to EL2 or EL3; instead, unmasked exceptions are taken to their default exception level (e.g., EL1) unless another control (e.g., EA, AMO, or TGE control) takes precedence. This behavior for EL0 is useful because, at the EL0 exception level (which cannot be the target exception level for handling exceptions), there is no exception syndrome information to protect, and therefore no need to trap to EL2 or EL3 even if the associated TMEA control is set. Since the EL1 syndrome information was captured, a previous exception return to EL0 already exists, so if the NMEA control prevents masking from occurring, there is no need to trap to EL2 or EL3 to protect the syndrome information at EL1, even if the associated TMEA control is set to the trapped state (0b1).

[0101] 8I illustrates the determination of the "routed_away" directive, which indicates whether there is any reason to route the SError exception away from the default exception level (e.g., EL1 in the guest operating system environment or EL2 in the host operating system environment) that would otherwise take the exception. If any of route_to_el2, route_soft_masked_to_el2, route_to_el3, or route_soft_masked_to_el3 is TRUE (step 1160), as determined in the processes shown in FIGS. 8C, 8G, 8A, and 8H, respectively (Yes in steps 1158, 1162, 1164, 1166), the routed_away directive is TRUE. If route_to_el2, route_soft_masked_to_el2, route_to_el3, and route_soft_masked_to_el3 are all FALSE (No in step 1166), then routed_away is FALSE (step 1168).

[0102] Figure 8J shows the final masked status determination, indicating whether the exception is actually masked (prevented from being taken). If soft_masked, determined following any NMEA override in Figure 8F, is TRUE (Yes in step 1170) and routed_away, determined in Figure 8I, is FALSE (Yes in step 1174), then masked is TRUE (step 1176), indicating that the exception is prevented from being taken. If soft_masked (following any NMEA override) is FALSE (No in step 1170) or routed_away is TRUE (No in step 1174), then the exception is taken, and therefore masked is FALSE (step 1172).

[0103] 8K illustrates determining whether an exception should be taken at EL3. If the current exception level is EL3 (YES in step 1178) and the exception is unmasked (YES in step 1180), then take_in_el3 is TRUE (step 1184); otherwise, take_in_el3 is FALSE (step 1182).

[0104] Figure 8L illustrates determining whether an exception should be taken at EL2 (take_in_el2_0). If the current exception level is EL2 (Yes in step 1186), or if IsInHost() determined in Figure 8B is TRUE (Yes in step 1188), routed_away determined in Figure 8I is FALSE (Yes in step 1192), and the exception is determined not to be masked in Figure 8J (Yes in step 1194), then take_in_el2_0 is TRUE (step 1196). Otherwise, take_in_el2_0 is FALSE (step 1190).

[0105] 8M illustrates determining whether an exception should be taken at EL1 (take_in_el1_0). If the current exception level is EL1 (YES in step 1198), or if the current exception level is EL0 and IsInHost() is FALSE (YES in step 1200), routed_away is FALSE (YES in step 1204), and it is determined that the exception is not masked (YES in step 1206), then take_in_el1_0 is TRUE (step 1208). Otherwise, take_in_el1_0 is FALSE (step 1202).

[0106] 8N shows the selection of a target exception level for taking an exception. If it is determined according to FIG. 8J that the exception is masked (No in step 1210), the target exception level is unknown because the exception is not taken.

[0107] If the "masked" status is FALSE (Yes in step 1210) and any of take_in_el3 (FIG. 8K), route_to_el3 (FIG. 8A), and route_soft_masked_to_el3 (FIG. 8H) are TRUE (Yes in step 1214), the target exception level is EL3 (step 1216).

[0108] If masked is FALSE (Yes in step 1210), the exception is not taken in EL3 (No in step 1214), and any of take_in_el2_0 (Figure 8L), route_to_el2 (Figure 8C), or route_soft_masked_to_el2 (Figure 8G) is TRUE (Yes in step 1218), the target exception level is EL2 (step 1220).

[0109] If masked is FALSE (Yes in step 1210) and the exception is not taken at EL3 or EL2 (No in steps 1214 and 1218), the target exception level is EL1 (step 1224). Note that in some cases, there may be an additional check of whether "take_in_el1_0" (determined according to FIG. 8M) is TRUE before determining that the target exception level is EL1. However, in practice, the state when the results of steps 1210, 1214, and 1218 are all No and "take_in_el1_0" is FALSE should be unreachable as shown in the following pseudocode, and therefore the check of whether "take_in_el1_0" is TRUE may be redundant.

[0110] Figure 8O illustrates the further ability to mask exceptions based on an external debugger disabling exceptions at the target exception level determined in Figure 8N. If the external debugger disabled the exception at the target exception level (Yes in step 1228), masked becomes TRUE and the target exception level becomes unknown (step 1232). Otherwise, the masked status and target exception level remain as determined according to Figures 8J and 8N, respectively.

[0111] 9A-9I illustrate the handling of a synchronous external abort exception, which indicates that an external memory system error has been detected following a memory system access (other than an MMU fault), and the error may have originated at a particular point in the instruction stream being executed. This is an example of the non-maskable class of exception discussed above. These figures collectively illustrate the process for determining which exception level should take the exception based on the current exception level at the time of the exception and the control information shown in FIG. 3. This type of exception cannot be masked. With regard to the references to "IsInHost()" in FIGS. 9A-9I, this is determined in the same manner as shown in FIG. 8B for the asynchronous SError exception, and therefore will not be repeated here again.

[0112] 9A illustrates the determination of the value route_to_el3, which indicates whether a synchronous external abort exception should be routed to be taken at EL3 from a lower exception level. If the current exception level is not el3 (No in step 1234) and SCR_EL3.EA=0b1 (Yes in step 1236), then route_to_el3 is TRUE (step 1240), indicating that the exception is routed to EL3. If the current exception level is EL3 (Yes in step 1234) or SCR_EL3.EA=0b0 (No in step 1236), then route_to_el3 is FALSE (step 1238).

[0113] Figure 9B illustrates the determination of the value route_to_el2, which indicates whether a synchronous external abort should be routed to be taken at EL2 from a lower exception level. References to "tea_bit" refer to the value of the HCR_EL2.TEA control (step 1254). If route_to_el3, as determined in Figure 9A, is TRUE (No in step 1256), then route_to_el2 is FALSE (step 1258).

[0114] If route_to_el3 is FALSE (Yes in step 1256) and the current exception level is EL1 (Yes in step 1260), then: If tea_bit is 1 or the fault is of a particular type to be handled at EL2 (YES in step 1262), then route_to_el2 is TRUE (step 1264). For example, a particular type of fault to be handled at EL2 may include a fault associated with an access to a system register managed by software executing at EL2 that is emulated through an access to memory, or may be a second-stage address translation fault detected by an MMU in a two-stage address translation regime in which address translation is controlled based on a first-stage page table defined by the operating system to map virtual addresses to intermediate addresses and a second-stage page table defined by a hypervisor to map the intermediate addresses to physical addresses. If tea_bit is 0 and the failure is not of a type that is handled in EL2 (No in step 1262), then route_to_el2 is FALSE (step 1266).

[0115] If route_to_el3 is FALSE (Yes in step 1256) and the current exception level is EL0 (Yes in step 1268): ●If IsInHost() (determined according to Figure 8B) is FALSE (Yes in step 1270), and tea_bit is 1, or HCR_EL2.TGE control is 1, or the failure is one of the types that should be handled in EL2 (Yes in step 1274), then route_to_el2 is TRUE (step 1276). If IsInHost() is TRUE (step 1270: No), or if tea_bit=0b0, HCR_EL2.TGE=0b0, and the failure is not of a type that is handled in EL2 (step 1274: No), then route_to_el2 is FALSE (step 1272).

[0116] If the current exception level is EL3 or EL2, then route_to_el2 is FALSE (No in step 1268 followed by step 1278).

[0117] Figure 9C shows the determination of signal route_soft_masked_to_el2, which indicates whether a trap to EL2 should be taken, based on the EL2 version of the TMEA control, HCRX_EL2.TMEA. This is a trap taken when PSTATE.A=1, ensuring that synchronous external abort exceptions can be handled more quickly in EL2 while allowing preservation of exception syndrome information in the EL1 set of syndrome registers.

[0118] The parameter route_soft_masked_to_el2 is determined to be FALSE (step 1282) if any one or more of the following apply: route_to_el3 (determined according to FIG. 9A) is TRUE (No in step 1280); ● The current exception level is any exception level other than EL1 (No in step 1284), ● PSTATE.A = 0 (No in step 1286), ●HCRX_EL2.TMEA=0 (No in step 1288).

[0119] The parameter route_soft_masked_to_el2 is determined to be TRUE if all of the following conditions are met (step 1282): route_to_el3 is FALSE (Yes in step 1280), ● The current exception level is EL1 (Yes in step 1284), ●PSTATE.A=1 (Yes in step 1286), ●HCRX_EL2.TMEA=1 (Yes in step 1288).

[0120] Therefore, if HCRX_EL2.TMEA is set to 1 (trapped), and a Synchronous External Abort exception occurs in EL1 while PSTATE.A is set to masked, the Synchronous External Abort exception is trapped to EL2. This trap is not taken if PSTATE.A is 0 (unmasked).

[0121] FIG. 9D shows the decision of signal route_soft_masked_to_el3, which indicates whether to take a trap to EL3, based on the EL3 version of the TMEA control SCR_EL3.TMEA.

[0122] The parameter route_soft_masked_to_el3 is determined to be FALSE (step 1294) if any one or more of the following apply: route_to_el2 (determined according to FIG. 9B) is TRUE (No in step 1292); route_soft_masked_to_el2 (determined according to FIG. 9C) is TRUE (No in step 1296); - If the current exception level is any exception level other than EL1 or EL2 (No in step 1298). • PSTATE.A=0 (No in step 1300). ●SCR_EL3.TMEA=0 (No in step 1302).

[0123] The parameter route_soft_masked_to_el3 is determined to be TRUE if all of the following conditions are met (step 1304): route_to_el2 is FALSE (Yes in step 1292), route_soft_masked_to_el2 is FALSE (No in step 1296), ● The current exception level is EL1 or EL2 (Yes in step 1298), ●PSTATE.A=1 (Yes in step 1300), ●SCR_EL3.TMEA=1 (Yes in step 1302).

[0124] Therefore, when SCR_EL3.TMEA is set to 1 (trapped), a Synchronous External Abort exception will trap to EL3 if it is not trapped to EL2 based on HCRX_EL2.TMEA or HCR_EL2.TEA, and will occur at EL1 or EL2 when PSTATE.A is set to 1 (masked). The trap will not be taken if PSTATE.A is 0 (unmasked).

[0125] 9E illustrates the determination of the "routed_away" directive, which indicates whether there is any reason to route a synchronous external abort exception away from the default exception level (e.g., EL1 or EL2) that would otherwise take the exception. If any of route_to_el2, route_soft_masked_to_el2, route_to_el3, or route_soft_masked_to_el3 is TRUE as determined in the processes illustrated in FIGS. 9B, 9C, 9A, and 9D, respectively (Yes in steps 1306, 1310, 1312, 1314), the routed_away directive is TRUE (step 1308). If route_to_el2, route_soft_masked_to_el2, route_to_el3, and route_soft_masked_to_el3 are all FALSE (No in steps 1306, 1310, 1312, 1314), then routed_away is FALSE (step 1316).

[0126] 9F illustrates determining whether an exception should be taken at EL3 (take_in_el3). If the current exception level is EL3 (YES in step 1318), then take_in_el3 is TRUE (step 1322); otherwise, take_in_el3 is FALSE (step 1320).

[0127] Figure 9G illustrates determining whether an exception should be taken at EL2 (take_in_el2_0). If the current exception level is EL2 (Yes in step 1324), or if IsInHost() determined in Figure 8B is TRUE (Yes in step 1326) and routed_away determined in Figure 9E is FALSE (Yes in step 1330), then take_in_el2_0 is TRUE (step 1332). Otherwise, take_in_el2_0 is FALSE (step 1328).

[0128] 9H illustrates determining whether an exception should be taken at EL1 (take_in_el1_0). If the current exception level is EL1 (YES in step 1334), or if the current exception level is EL0, IsInHost() is FALSE (YES in step 1336), and routed_away is FALSE (YES in step 1340), then take_in_el1_0 is TRUE (step 1342). Otherwise, take_in_el1_0 is FALSE (step 1338).

[0129] 9I illustrates the selection of a target exception level for taking an exception. If any of take_in_el3 (FIG. 9F), route_to_el3 (FIG. 9A), and route_soft_masked_to_el3 (FIG. 9D) are TRUE (Yes in step 1344), the target exception level is EL3 (step 1346).

[0130] If the exception is not taken at EL3 (No in step 1344) and any of take_in_el2_0 (FIG. 9G), route_to_el2 (FIG. 9B), and route_soft_masked_to_el2 (FIG. 9C) are TRUE (Yes in step 1348), the target exception level is EL2 (step 1350).

[0131] If the exception is not taken at EL3 or EL2 (No at step 1348), the target exception level is EL1 (step 1354). Note that in some cases, there may be an additional check of whether "take_in_el1_0" (determined according to FIG. 9H) is TRUE before determining that the target exception level is EL1. However, in practice, the state when the results of steps 1344 and 1348 are No and "take_in_el1_0" is FALSE should be unreachable as shown in the following pseudocode, and therefore the check of whether "take_in_el1_0" is TRUE may be redundant.

[0132] It will be understood that the same logical functions of the flow diagrams shown above can be achieved by performing steps in a different order or by performing some steps in parallel. Also, not all steps are required for a given embodiment. In some implementations, certain types of exception routing control may not be supported, as shown in the pseudocode below, where there are some additional tests for whether certain optional features are supported (see, for example, the tests for variables of the form "???Enabled()" or "Have???()," which indicate whether a particular optional feature is enabled and implemented). The AND or Boolean relationships shown in the pseudocode indicate what happens if one of these optional features is not supported. In most cases, if an exception routing control is not supported, the corresponding control value is treated as if it were 0b0.

[0133] Exemplary pseudocode for implementing the functionality of FIGS. 8A-8O is provided below:

[0134] [Table 1]

[0135] [Table 2]

[0136] [Table 3] An example pseudo-code for the function IsInHost() is as follows:

[0137] [Table 4]

[0138] 10A and 10B show summary tables that indicate, for each combination of control information values, whether an asynchronous system error (SError) exception that occurs at exception level EL0, EL1, EL2, or EL3 is taken or masked, and if taken, which exception level is the target exception level at which the exception is taken.

[0139] Each column on the left side of the table refers to a bit in one of the system registers or a PSTATE.A flag for the labeled exception level (an "x" indicates that the corresponding control may be 0b0 or 0b1): ●EA EL3 means SCR_EL3.EA ●TMEA EL3 means SCR_EL3.TMEA ●NMEA EL3 means SCR_EL3.NMEA ●TGE EL2 means HCR_EL2.TGE ●E2H EL2 means HCR_EL2.E2H ●AMO EL2 means HCR_EL2.AMO ●NMEA EL2 means SCTLR2_EL2.NMEA ●TMEA EL2 means HCRX_EL2.TMEA ●NMEA EL1 means SCTLR2_EL1.NMEA ●A PSTATE means PSTATE.A.

[0140] Each column on the right side of the table indicates the outcome if an SError exception occurs for the corresponding set of control information values ​​when the current exception level is EL3, EL2, EL1, or EL0, respectively. Each cell in the right column represents one of the following outcomes: ●ELx means that the error exception is taken to ELx. ●B means that the error exception is not taken and remains pending because it is masked by PSTATE.A. ●C means that the error exception is not taken because it is implicitly masked (the current exception level is more privileged than the exception level at which the exception should be taken) and remains pending. n / a: means that the exception level is not accessible in this configuration.

[0141] These values ​​are determined according to the pseudocode above and the functions shown in Figures 8A-8O.

[0142] Any of the control options other than TMEA and PSTATE.A are optional, and if omitted, can be treated as if they were set to 0b0.

[0143] Exemplary lines of note in FIGS. 10A and 10B include: ●Line 1: Error exceptions at EL1 and EL0 are taken to the default exception level EL1, and at EL2 and EL3 they are implicitly masked because they are at exception levels more privileged than the default exception level EL1. No trap control is set. ● Line 2: By setting PSTATE.A to 1, error exceptions are masked at EL1 and EL0. ● Line 3: Setting NMEA EL1 to 1 prevents error exception masking even if PSTATE.A is 1. Lines 4 and 5: Setting TMEA EL2 to 1 causes error exceptions to trap from EL1 or EL0 to EL2 if PSTATE.A is 1, but if PSTATE.A is 0, the behavior is still the same as line 1. ● Line 6: If TMEA EL2 and NMEA EL1 are both 1 and PSTATE.A is 1, the non-maskable status caused by NMEA=1 overrides trapping to EL2 if an error exception occurs in EL0, but not if the error exception occurs in EL1; therefore, if TMEA EL2, NMEA EL1, and PSTATE.A are all 1, but none of the other trap controls are set, an error exception occurring in EL0 will be taken in EL1, but an error exception occurring in EL1 will be taken in EL2. ● Line 7: Setting NMEA EL2 to 1 means that error exceptions are taken to EL2 even if they occur in EL2, rather than being implicitly masked as in lines 1-6. ● Lines 13-19 and 63-68: The TMEA control has no effect when any of the EA EL3, TGE EL2, and AMO EL2 controls are set, because in these cases there is explicit routing of error exceptions to EL2 or EL3. Line 41: If both TMEA EL3 and TMEA EL2 are set and PSTATE.A is set, TMEA-based traps from EL0 and EL1 are taken to EL2, i.e., the TMEA-related exception level that is closest in privilege to the current exception level, and TMEA-based traps from EL2 are taken to EL3. Line 42 shows how, if TMEA EL1 is 1, this overrides TMEA-based traps from EL0 and the exception is taken at EL1 instead (similar to line 6).

[0144] Exemplary pseudocode for implementing the functionality of FIGS. 9A-9I is provided below:

[0145] [Table 5]

[0146] [Table 6]

[0147] Figure 11 shows a summary table that indicates, for each combination of control information values, which exception level is the target exception level for a (non-maskable) synchronous external abort exception that occurs at exception level EL0, EL1, EL2, or EL3. The column TEA_EL2 refers to the value of HCR_EL2.TEA, and the other columns have the same meaning as in Figures 10A and 10B. Note lines 2 and 3, which indicate that when TMEA_EL2 is 1, a trap to EL2 is taken from EL1 (but not EL0) when PSTATE.A is 1, but when PSTATE.A is 0, the exception is taken at EL1 from both EL1 and EL0.

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

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

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

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

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

[0153] FIG. 12 illustrates a simulator implementation that may be used. While the above embodiments implement the present invention in terms of apparatus and methods for operating specific processing hardware supporting the technology, it is also possible to provide an instruction execution environment according to the embodiments described herein implemented through the use of a computer program. Such computer programs are often referred to as simulators, insofar as they provide a software-based implementation of a hardware architecture. Various simulator computer programs include emulators, virtual machines, models, and binary translators, including dynamic binary translators. Typically, a simulator implementation may execute on a host processor 330, optionally running a host operating system 320 and supporting the simulator program 310. In some arrangements, there may be multiple layers of simulation between the hardware and the provided instruction execution environment, and / or there may be multiple different instruction execution environments provided on the same host processor. Historically, powerful processors have been required to provide simulator implementations that run at reasonable speeds, but such an approach may be justified in certain situations, such as when it is desirable to execute code native to another processor for compatibility or reuse reasons. For example, a simulator implementation may provide an instruction execution environment with additional functionality not supported by the host processor hardware, or may provide an instruction execution environment typically associated with a different hardware architecture. An overview of simulation is given in "Some Efficient Architecture Simulation Techniques," Robert Bedichek, Winter 1990 USENIX Conference, pp. 53-63.

[0154] While embodiments have been described above with reference to particular hardware constructs or features, equivalent functionality may be provided in the simulated embodiments by suitable software constructs or features. For example, particular circuits may be implemented as computer program logic in the simulated embodiments. Similarly, memory hardware such as registers or caches may be implemented as software data structures in the simulated embodiments. In arrangements where one or more of the hardware elements referenced in the foregoing embodiments reside on host hardware (e.g., host processor 330), some simulated embodiments may use the host hardware where suitable.

[0155] Simulator program 310 may be stored on a computer-readable storage medium (which may be a non-transitory medium) and provides a program interface (an instruction execution environment) to target code 300 (which may include an application, an operating system, and a hypervisor), the program interface being the same as the application program interface of the hardware architecture being modeled by simulator program 310. Thus, program instructions of target code 300 may be executed from within the instruction execution environment using simulator program 310, thereby allowing host computer 330, which does not actually have the hardware features of device 2 described above, to emulate these features. Simulator program 310 thus simulates the presence of target processing circuitry.

[0156] Simulator code 310 includes instruction decode program logic 312, processing program logic 314, and exception control program logic 318, which correspond in function to instruction decoder 10, processing circuitry 4, and exception control circuitry 40 described above. Additionally, a register emulation data structure 316 may be maintained by simulator code 310 to emulate registers 14 provided in the instruction set architecture of the target processor simulated by simulator code 310. For example, register emulation data structure 316 may be stored in a memory of the host data processing device and may include storage locations for storing data corresponding to registers 14, including registers for storing control information as shown in FIG. 3 . Exception control program logic 318 may respond to simulated exceptions targeted at the target processor represented by simulator code 310 in a manner corresponding to the response to exceptions by exception control circuitry 40 described above, including controlling whether exceptions are masked and controlling trapping based on trap mask exception control information and other control information described above. (In a simulation, exception routing control information may be maintained as part of register emulation data structure 316.) Thus, the simulator code 310 can provide advantages similar to those achieved on a physical hardware implementation of the processing unit 2 described in the previous example.

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

[0158] In this application, a list of features preceded by the phrase "at least one of" means that any one or more of those features can be provided individually or in combination. For example, "at least one of: [A], [B] and [C]" encompasses any of the following options: A alone (without B or C), B alone (without A or C), C alone (without A or B), a combination of A and B (without C), a combination of A and C (without B), a combination of B and C (without A), or a combination of A, B, and C.

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

Claims

1. 1. An apparatus comprising: a processing circuit for performing data processing at one of a plurality of exception levels supported by the processing circuit; an exception control circuit for controlling exception taking by said processing circuitry in dependence on control information stored in at least one register, said control information comprising at least: masking control information that can be set to one of a masked state and an unmasked state; trap mask exception control information that can be set by software to one of an untrapped state and a trapped state; Including, In response to a given exception of a maskable class of exceptions that is maskable based on the masking control information being in the masked state, the exception control circuitry: determining whether the masking control information is in the masked state; in at least one scenario in which the given exception occurs when the masking control information is in the masked state and a current exception level is less privileged than a predetermined trap target exception level associated with the trap mask exception control information, controlling whether to trap the given exception to the predetermined trap target exception level depending on whether the trap mask exception control information is in the trapped state; and if the masking control information is in the unmasked state and the given exception is determined to be unmasked, select a target exception level for handling the given exception, wherein the target exception level is selected independently of the trap mask exception control information.

2. the control information includes a plurality of items of trap mask exception control information, each associated with a respective one of a plurality of predetermined trap target exception levels; the exception control circuitry is configured to, in at least one scenario in which the given exception occurs when the masking control information is in the masked state and the current exception level is less privileged than the given one of the plurality of predetermined trap target exception levels, control whether the given exception is trapped to the given one of the plurality of predetermined trap target exception levels depending on whether trap mask exception control information of a corresponding item associated with the given one of the plurality of predetermined trap target exception levels is in the trapped state; 10. The apparatus of claim 1.

3. In at least one scenario in which the given exception occurs when the masking control information is in the masked state, at least two items of trap mask exception control information are in the trapped state, and for each of the at least two items of trap mask exception control information, one or more conditions for trapping to the predetermined trap target exception level are satisfied; the exception control circuitry is configured to trap the given exception to the predetermined trap target exception level associated with trap mask exception control information of a selected item; 3. The apparatus of claim 2, wherein the trap mask exception control information of the selected item includes one of the trap mask exception control information of the at least two items having a minimum privilege difference between the current exception level and the associated predetermined trap target exception level.

4. 4. The apparatus of claim 1, wherein if the trap mask exception control information is in the untrapped state, the exception control circuitry is configured to determine whether the given exception is masked depending at least on whether the masking control information is in the masked state.

5. 5. The apparatus of claim 4, wherein the exception control circuitry is also configured to determine whether the given exception is masked depending on whether the current exception level is more privileged than an exception level at which the given exception would be taken if the exception level were taken when the trap mask exception control information is in the untrapped state.

6. the control information includes non-maskable exception control information settable to one of a non-maskable state and a maskable state to indicate whether an exception of the maskable class is maskable; and in at least one scenario when the non-maskable exception control information is in the non-maskable state, the exception control circuitry is configured to determine that the given exception is not masked even when the masking control information is set to the masked state.

6. An apparatus according to claim 4 or 5.

7. In a scenario where the given exception occurs when the current exception level is a least privileged exception level, if the non-maskable exception control information is in the non-maskable state, the given exception is not masked, and the trap mask exception control information is in the not trapped state, the given exception is taken to a next least privileged exception level that is enabled for taking the given exception, and the exception control circuitry:

7. The apparatus of claim 6, wherein the trap mask exception control information is configured to control taking the given exception at the next least privileged exception level without trapping to the predetermined trap target exception level even when the trap mask exception control information is in the trapped state.

8. the control information includes a plurality of items of non-maskable exception control information associated with different exception levels; 8. The apparatus of claim 7, wherein the exception control circuitry is configured to determine whether the given exception is masked depending on one of the plurality of items of non-maskable exception control information selected based on the current exception level.

9. the control information includes at least one further item of trap control information settable by software to one of a trapped state and an untrapped state; the exception control circuit is configured to control whether to trap at least the maskable class of exceptions to a particular exception level depending on whether the trap control information of the further item is in the trapped state; 9. The apparatus of claim 1, wherein the trap control information of the at least one further item takes precedence over the trap mask exception control information, such that if the trap control information of the further item is in the trapped state, the exception control circuitry is configured to trap the exception to the particular exception level based on the trap control information of the further item, regardless of whether the trap mask exception control information is in the trapped state.

10. The apparatus of claim 1 , wherein the maskable class of exceptions comprises an asynchronous error exception that indicates a deviation from correct service.

11. In response to a non-maskable exception of a non-maskable class of exceptions that cannot be masked based on setting the masking control information to the masked state, the exception control circuit 11. The apparatus of claim 1, configured to control whether to trap the non-maskable exception to the predetermined trap target exception level depending on whether the trap mask exception control information is in the trapped state in at least one scenario in which the given exception occurs when the masking control information is in the masked state, a current exception level is less privileged than the predetermined trap target exception level associated with the trap mask exception control information, and the current exception level is an exception level that may be a target exception level for handling the exception.

12. The apparatus of claim 11 , wherein the non-maskable class of exceptions comprises a synchronous external abort exception that indicates a deviation from correct service.

13. 13. The apparatus of claim 1, comprising a plurality of sets of one or more exception syndrome registers, each set of one or more exception syndrome registers storing exception syndrome information for exceptions taken at each of the exception levels.

14. 14. The apparatus of claim 1, wherein the processing circuitry is configured to deny or trap the requested update to the trap mask exception control information in response to an instruction requesting an update to the trap mask exception control information being executed at an exception level that is less privileged than the predetermined trap target exception level associated with the trap mask exception control information.

15. Computer readable code for manufacturing a device according to any one of claims 1 to 14.

16. A storage medium having stored thereon the computer readable code of claim 15.

17. 1. A method comprising: performing data processing at one of a plurality of exception levels supported by the processing circuitry; and controlling exception taking by said processing circuitry in dependence on control information stored in at least one register, said control information comprising at least: masking control information that can be set to one of a masked state and an unmasked state; trap mask exception control information that can be set by software to one of an untrapped state and a trapped state; Including, In response to a given exception of a maskable class of exceptions that is maskable based on setting the masking control information to the masked state, the method comprises: determining whether the masking control information is in the masked state; in at least one scenario in which the given exception occurs when the masking control information is in the masked state and a current exception level is less privileged than a predetermined trap target exception level associated with the trap mask exception control information, controlling whether to trap the given exception to the predetermined trap target exception level depending on whether the trap mask exception control information is in the trapped state; if the masking control information is in the unmasked state and it is determined that the given exception is unmasked, selecting a target exception level for handling the given exception, wherein the target exception level is selected independently of the trap mask exception control information.

18. 1. A computer program comprising instructions that, when executed by a host data processing apparatus, control the host data processing apparatus to provide an instruction execution environment for executing target code, the computer program comprising: processor logic for simulating execution of instructions of the target code at one of a plurality of exception levels; Exception control program logic for simulating exception taking in dependence on control information stored in at least one storage location of the host data processing apparatus representing at least one register of a target instruction set architecture used by the target code, the control information comprising at least: masking control information that can be set to one of a masked state and an unmasked state; trap mask exception control information that can be set by software to one of an untrapped state and a trapped state; Including, In response to a given exception of a maskable class of exceptions that is maskable based on setting the masking control information to the masked state, the exception control program logic: determining whether the masking control information is in the masked state; in at least one scenario in which the given exception occurs when the masking control information is in the masked state and a current exception level is less privileged than a predetermined trap target exception level associated with the trap mask exception control information, controlling whether to trap the given exception to the predetermined trap target exception level depending on whether the trap mask exception control information is in the trapped state; and if the masking control information is in the unmasked state and the given exception is determined to be unmasked, select a target exception level for handling the given exception, wherein the target exception level is selected independently of the trap mask exception control information.

19. A storage medium storing a computer program according to claim 18.

Images