Abnormality control

Abstract

An abnormality control circuit (40) controls the processing circuit (4) to take an abnormality depending on control information stored in the 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 abnormality control information that can be set to a trap mask in a non-recessed state or a recessed state. In response to a given anomaly of the maskable category, in at least one scenario in which the mask control information is in the masked state and the privilege of the current anomaly level is lower than a predetermined trap target anomaly level, a predetermined trap target anomaly level is determined. The anomaly control circuit controls whether to capture the given anomaly to the predetermined trap target anomaly level depending on whether the anomaly control information of the trap mask is in the trap setting state. When the masking control information is in the unmasked state, a target anomaly level for handling the given anomaly is selected independently of the anomaly control information masked by the trap.

Description

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

[0002] When performing data processing, the processing circuitry may encounter an exception, which is an event that requires interruption of the normal program execution flow so that processing can be switched to an exception handler to handle the event that caused the exception. For example, an exception may occur for many reasons, such as the execution of an undefined instruction, an address fault due to an undefined virtual to physical address translation mapping or a memory access permission check failure, 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 provide a device comprising: a processing circuit for performing data processing in one of a plurality of exception levels supported by the processing circuit; and an exception control circuit for controlling taking of an exception by the processing circuit depending on control information stored in at least one register, the control information comprising at least: masking control information, the masking control information being capable of being set to one of a masked state and an unmasked state; and trap-masked-exception control information, the trap-masked-exception control information being capable of being set to one of an untrapped state and a trapped state by software; wherein: in response to being capable of taking an exception based on setting the masking control information to the masked state For a given exception in a maskable category of exceptions, the exception control circuit is configured to: determine whether the masking control information is in the masked state; in at least one scenario where the given exception occurs when the masking control information is in the masked state and the privilege of the current exception level is lower than the predetermined trap target exception level associated with the trap-masked exception control information, control whether to capture the given exception to the predetermined trap target exception level depending on whether the trap-masked exception control information is in the trapping state; and in the case where 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, the target exception level being selected independently of the trap-masked exception control information.

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

[0005] At least some examples provide a method, the method comprising: performing data processing in one of a plurality of exception levels supported by the processing circuit; and controlling taking of an exception by the processing circuit depending on control information stored in at least one register, the control information comprising at least: masking control information, the masking control information being capable of being set to one of a masked state and an unmasked state; and trap-masked exception control information, the trap-masked exception control information being capable of being set to one of an untrapped state and a trapped state by software; wherein: in response to a given exception in a maskable category that can be masked based on setting the masking control information to the masking state, the method The invention comprises: determining whether the masking control information is in the masking state; in at least one scenario where the given exception occurs when the masking control information is in the masking state and the privilege of the current exception level is lower than the predetermined trap target exception level associated with the trap-masked exception control information, controlling whether to capture the given exception to the predetermined trap target exception level depending on whether the trap-masked exception control information is in the trapping state; and in the case where the masking control information is in the unmasked state and the given exception is determined to be unmasked, selecting a target exception level for processing the given exception, the target exception level being selected independently of the trap-masked exception control information.

[0006] At least some examples provide a computer program including instructions that, when executed by a host data processing device, control the host data processing device to provide an instruction execution environment for executing a target code, the computer program including: a handler logic for simulating execution of instructions of the target code in one of a plurality of exception levels; and an exception control program logic for simulating taking an exception depending on control information stored in at least one storage location of at least one register of the host data processing device representing a target instruction set architecture used by the target code, the control information including at least: mask control information that can be set by software to one of a masked state and an unmasked state; and trap-masked exception control information that can be set by software to an untrapped state. one of a state and a trapped state; wherein: in response to a given exception in a maskable category that can be masked based on software that sets the masking control information to the masking state, the exception control program logic is configured to: determine whether the masking control information is in the masking state; in at least one scenario where the given exception occurs when the masking control information is in the masking state and the privilege of the current exception level is lower than the predetermined trap target exception level associated with the trap-masked exception control information, control whether the given exception is captured to the predetermined trap target exception level depending on whether the trap-masked exception control information is in the trapped state; and in the case where 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, the target exception level being selected independently of the trap-masked exception control information.

[0007] The computer program may be stored on a storage medium. The storage medium may be a transient or non-transient storage medium.

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

[0009] Figure 1 An example of a data processing apparatus is schematically illustrated;

[0010] Figure 2 illustrates a plurality of exception levels at which processing circuitry may perform data processing;

[0011] Figure 3 illustrates control information stored in registers;

[0012] Figure 4 is a flow chart illustrating determining whether a given anomaly in a maskable class of anomalies should be masked;

[0013] Figure 5 is a flow chart illustrating determining whether to trap a given exception to a predetermined trap target exception level depending on whether mask control information is in a masked state and whether trap-masked exception control information is in a trapped state;

[0014] Figure 6 is a flow chart illustrating controlling the updating of the exception control information for the trap mask;

[0015] Figure 7 is a flowchart illustrating a method for controlling whether an exception in an unmaskable category of exceptions is captured to a predetermined trap target exception level based on the exception control information of the trap mask;

[0016] FIG. 8A to FIG. 8O A specific example of determining whether a given exception in a maskable class of exceptions should be masked, and if not masked, which exception level is a target exception level at which to take the given exception;

[0017] FIG. 9A to FIG. 9I A specific example of determining a target anomaly level for an anomaly in an unmaskable class of anomalies is illustrated;

[0018] Fig. 10A and Fig. 10B is a table illustrating whether a given exception of a maskable class is masked, and if not masked, at which exception level the given exception is taken, depending on the current exception level and control information when the given exception occurs;

[0019] Fig.11 is a table illustrating selection of a target exception level for an unmaskable category depending on the current exception level and control information when a given exception occurs; and

[0020] Fig.12 A simulation example is shown.

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

[0022] 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 automatically set to a masked state by the hardware of the processing circuit or the exception control circuit in response to certain events (for example, the masking control information can be set to a masked state in response to the taking of an exception), and / or can be set by software executed at a given exception level to control whether the exception of the maskable category is masked, thereby preventing them from being taken at a given exception level. If it is set in hardware on taking an exception, the software can control the timing of when the masking control information is cleared to an unmasked state. For example, instructions can be supported in the instruction set architecture to allow software to trigger the masking control information to be set to a masked or unmasked state as required. If it is set to a masked state by software, when it is expected that the taking of an exception will be deactivated for a period of time, the software can choose to set the masking control information to a masked state for any arbitrary reason. Regardless of whether the masking control information is set in hardware or software, one reason for masking an exception can be to retain state information associated with the processing currently executed by the software, and if an exception is taken, the state information may be overwritten.

[0023] However, regardless of whether the processing circuitry (either in hardware or under software control) has set the masking control information to a masked state when operating at a lower privilege exception level, other software executing on the processing circuitry (e.g., supervisory software such as a hypervisor or security monitor) may consider exceptions of the maskable class to be important exceptions that should be handled promptly. For example, if an exception of the maskable class indicates that an error has been detected, there may be a risk that the error may propagate due to processing of the masked exception based on the masking control information, making the problem worse (e.g., an erroneous value stored in memory may be processed by other operations that propagate the error to other locations in memory). One method for ensuring that exceptions of the maskable class are handled promptly may be to provide a control that software at a higher privilege exception level may set to indicate that an exception of the maskable class should be taken at the higher privilege exception level to override masking based on the masking control information, even if the masking control information is in the masked state. However, a problem with this approach is that when this control is set, the handling of exceptions of maskable classes is always taken away from the normal default level for handling that exception, which can increase the complexity of software development because more cooperation may be required between different software developers developing software that executes at different exception levels.

[0024] In the example discussed below, the control information includes trap-masked exception control information, which can be set by software to one of an untrapped state and a trapped state. In response to a given exception in a maskable category of exceptions that can be masked based on setting the mask control information to the mask state, the exception control circuit is configured to: determine whether the mask control information is in the mask state; in at least one scenario where the given exception occurs when the mask control information is in the mask state and the privilege of the current exception level is lower than the predetermined trap target exception level associated with the trap-masked exception control information, control whether the given exception is captured to the predetermined trap target exception level depending on whether the trap-masked exception control information is in the trapped state; and in the case where the mask 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, the target exception level being selected independently of the trap-masked exception control information.

[0025] Therefore, the trap-masked exception control information provides an architectural control option that can be used to configure the exception handling circuit, so that when the masking control information has been set to the masked state, the exception can be captured to a predetermined trap target exception level to reduce the delay in handling the exception. However, the premise of this capture based on the trap-masked exception control information is that the masking control information is set to the masked state. When the masking control information is in the unmasked state and the given exception is not masked, the exception can be taken at the target exception level selected independently of the trap-masked exception control information. In fact, since the masking control information is usually set to the masked state for a relatively small portion of the execution time, this can greatly reduce the number of opportunities for which the exception of the maskable class must be captured to an exception level that is more privileged than the default level at which the exception would normally be taken. Compared to a control option that indicates that all exceptions of a maskable class should be caught at a higher privileged exception level (regardless of the state of the masking control information), this allows a greater portion of exceptions to be handled at a lower privileged exception level, thereby enabling (kernel-first) exception handling where lower privileged software can handle exceptions of a maskable class in most cases (rather than (firmware-first) exception handling where higher privileged code typically handles most exceptions). Kernel-first exception handling is generally preferred because it simplifies software development compared to firmware-first exception handling. Therefore, because a processor that supports an instruction set architecture that supports exception control information that is masked by traps is simpler for software developers to develop software for the processor, the processor is an improvement over a processor that does not support exception control information that is masked by traps.

[0026] In response to an instruction requesting an update of the trap-masked exception control information executed at an exception level less privileged than the predetermined trap target exception level associated with the trap-masked exception control information, the processing circuitry may reject or trap the requested update of the trap-masked exception control information. Thus, the trap-masked exception control information may be limited to being set by software executed at a higher privileged exception level at which the exception is to be trapped (or may be set by an exception level even more privileged than the exception level). Thus, the trap-masked exception control information may be viewed as an architectural control option that enables higher privileged code to override a preference (associated with operation at a lower privileged exception level) to mask exceptions of maskable classes based on masking control information in a masked state.

[0027] In some examples, there may be only a single item of exception control information for trap masking that controls whether a trap that depends on the masking control information is taken to a particular exception level.

[0028] However, it may be useful to provide multiple items of trap-masked exception control information, each associated with a corresponding one of a plurality of predetermined trap target exception levels. The exception control circuit may control whether to capture the given exception to the given predetermined trap target exception level in the plurality of predetermined trap target exception levels, depending on whether the corresponding item of the trap-masked exception control information associated with the given predetermined trap target exception level in the plurality of predetermined trap target exception levels is in the set state, in at least one scenario where the given exception occurs when the masking control information is in the masked state and the privilege of the current exception level is lower than that of the given predetermined trap target exception level in the plurality of predetermined trap target exception levels. By providing multiple items of trap-masked exception control information that can be set by higher privileged software at different exception levels, this gives multiple pieces of higher privileged software (e.g., hypervisor and security monitor code) individual control over whether to capture rather than mask exceptions when the masking control information is set to the masked state. This may provide different software providers with more flexibility in the way that exceptions of maskable categories are handled.

[0029] In at least one scenario where the given exception occurs when the masking control information is in the masked state, at least two items of the trap-masked exception control information are in the trapped state, and each of the at least two items of the trap-masked exception control information satisfies one or more conditions for catching the predetermined trap target exception level: the exception control circuit is configured to catch the given exception to the predetermined trap target exception level associated with the selected item of the trap-masked exception control information; and the selected item of the trap-masked exception control information includes one of the at least two items of the trap-masked exception control information that has the smallest difference in privilege between the current exception level and the associated predetermined trap target exception level. Thus, in the event that more than one item of the trap-masked exception control information has been set to the trapped state (e.g., by software at different exception levels), if an exception is caught based on the trap-masked exception control information, it is brought to the lowest privilege of the associated predetermined trap target exception level associated with those items of the trap-masked exception control information that have been set to the trapped state. This may be considered counter-intuitive because it is different from other exception handling controls where it is generally assumed that controls set at a higher privileged exception level should take precedence if there are conflicting controls set by software at different exception levels. However, since taking an exception at the lowest privileged exception level available for taking an exception may simplify software development, it may be useful to allow items of trap-masked exception control information associated with a lower privileged exception level to take precedence even if the higher privileged exception level has set the trap-masked exception control information to a trapped state.

[0030] In the case where the trap-masked exception control information is in the untrapped state, the exception control circuit may determine whether the 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, in the case where a trap is set based on the trap-masked exception control information, even if the masking control information is in the masked state, the exception is still not masked.

[0031] In addition, there may be other reasons for masking an exception, which may be, for example, based on the current privilege level when the exception occurs. For example, the exception control circuit may determine whether a given exception is masked depending on whether the privilege of the current exception level is higher than the exception level at which the given exception would be taken if the exception level was taken when the trap-masked exception control information was in the untrapped state. This is useful because it can be assumed that if one is currently in an exception level that is more privileged than the exception level at which the exception would normally be handled (not taking into account the capture of the trap-masked exception control information), then the current processing may be considered more important than the handling of the exception, and therefore the exception may be implicitly considered to be masked regardless of whether the masking control information is in the masked state.

[0032] Furthermore, even if the masking control information is in the masking state, it does not necessarily always indicate that the exception is masked when a trap based on the exception control information of the trap mask is not present. For example, as explained in more detail below, it is possible to provide an architectural control option that allows software to indicate that at least in some scenarios, exceptions of a maskable class should be treated as if they are not maskable, so that a given exception may not be masked even if the masking control information is in the masking state.

[0033] Therefore, it should be understood that although typically when the trap-masked exception control information is in the untrapped state, the exception control circuit is configured to determine whether the given exception is masked depending at least on whether the masking control information is in the masked state, in some specific implementations, determining whether the exception is actually masked may also take into account several other parameters.

[0034] In some examples, the control information includes unmaskable exception control information, the unmaskable exception control information can be set to one of an unmaskable state and a maskable state to indicate whether the maskable class of exceptions can be masked; and in at least one scenario in which the unmaskable exception control information is in the unmaskable state, even when the masking control information is set to the masking state, the exception control circuit is configured to determine that the given exception will not be masked. This control can be useful for allowing higher privileged software to express a preference that maskable class of exceptions should be treated as unmaskable to ensure that they are handled more quickly, regardless of whether the masking control information has been set to the masking state.

[0035] In the scenario where the given exception occurs when the current exception level is the lowest privileged exception level, the unmaskable exception control information is in the unmaskable state, and the given exception is to be taken to the next lowest privileged exception level that is enabled to take the given exception when the given exception is not masked and the trap-masked exception control information is in the untrapped state, the exception control circuit is configured to control the given exception to be taken in the next lowest privileged exception level without catching the predetermined trap target exception level even when the trap-masked exception control information is in the trapped state. Therefore, in the case where the current exception level is the lowest privileged level, the unmaskable exception control information in the unmaskable state also covers any catching based on the trap-masked exception control information. It should be noted that the next lowest privileged exception level that is enabled for taking the given exception may vary based on other control information. For example, control information that specifies whether the system is in a guest operating system hierarchy (where a hypervisor manages guest operating systems but does not perform operating system functions itself) or in a host operating system hierarchy (where a hypervisor also manages applications and performs operating system functions) can control whether exception levels for guest operating systems in the guest operating system hierarchy are disabled in the host operating system hierarchy, so that the next lowest privilege exception level enabled can be a kernel-level exception level in the guest operating system hierarchy (where the guest operating system executes) and can be a hypervisor-level exception level in the host operating system hierarchy (where the hypervisor / host operating system executes).

[0036] When the current exception level is not the lowest privileged exception level, the unmaskable exception control information in the unmaskable state may override the mask itself, but not any traps determined to be needed based on the trap-masked exception control information in the trapping state and the masking control information in the masking state. This is because setting the masking control information to the masking state indicates a preference for not taking an exception to preserve a certain state that might be overwritten if the exception is taken (assuming that the current state of the process is at the default exception level to which the exception would normally be taken by default), and therefore even if the exception is not actually masked, it may still be preferred to take the exception at a higher level by triggering a trap to the predetermined trap target exception level.

[0037] In some examples, the control information includes multiple items of unmaskable exception control information associated with different exception levels; and the exception control circuit can determine whether the given exception is masked depending on one of the multiple items of unmaskable exception control information selected based on the current exception level. This can provide flexibility for different providers of software executed at different exception levels to express independent preferences on whether to allow masking of maskable exceptions.

[0038] Thus, it should be appreciated that the precise determination of whether to take a trap to a predetermined trap target exception level may depend on many factors, such as (in some implementations) the current exception level and (in at least one exception level) the current state of unmaskable exception control information, in addition to the mask control information and the exception control information masked by the trap.

[0039] In some implementations, there may also be other (optional) controls that override the trap-masked exception control information, such that even if the conditions described above for taking a trap are met (the masking control information is in the masking state, the current exception level is less privileged than the predetermined trap target exception level associated with the trap-masked exception control information, and the trap-masked exception control information is in the setting state), a trap to the predetermined trap target exception level may still not be taken (for example, because another control has specified that exceptions of a maskable class be trapped to a different exception level).

[0040] For example, the control information may include at least one other item of trap control information that can be set by software to one of a trapped state and an untrapped state; the exception control circuit may control whether to capture at least the exception of the maskable class to a specific exception level depending on whether the other item of trap control information is in the trapped state; and the at least one other item of trap control information may take precedence over the trap-masked exception control information, so that when the other item of trap control information is in the trapped state, the exception control circuit is configured to capture the exception to the specific exception level based on the other item of trap control information, regardless of whether the trap-masked exception control information is in the trapped state. For example, this other item of control information may be similar to the control for comparison described above, which indicates that the exception of the maskable class may be captured to a higher privileged exception level regardless of whether the masking control information is in the masking state. The use of the trap-masked exception control information may therefore be relevant when the at least one other item of trap control information is in the untrapped state, but irrelevant when the at least one other item of trap control information is in the trapped state.

[0041] In some cases, at least one of the other items of trap control information may be specific to a maskable class of exceptions, where another class of exceptions is not affected by the item of trap control information.

[0042] Furthermore, it is possible that at least one of the other items of trap control information is a more general control that affects the handling of both maskable classes of exceptions and at least one other class of exceptions.

[0043] Thus, depending on which additional architectural control settings are supported and how the information defining those architectural control settings has been set, there are a large number of ways in which the trap-masked exception control information may be used. Generally speaking, in at least one scenario where a given exception occurs when the masking control information is in a masked state and the privilege of the current exception level is lower than a predetermined trap target exception level associated with the trap-masked exception control information, it is useful to provide trap-masked exception control information that controls a trap to a predetermined trap target exception level depending on whether the trap-masked exception control information is in a trapped state, but does not affect the selection of the target exception level in the case where a maskable exception will not be masked if the masking control information is in an unmasked state. However, it is not necessary to consider the trap-masked exception control information in all scenarios where exceptions may occur.

[0044] A maskable class of exceptions may be any class of exceptions that may optionally be masked but that may sometimes need to be handled more quickly.

[0045] However, the techniques discussed above may be particularly useful in cases where the maskable class of exceptions includes asynchronous system error exceptions that indicate deviations from correct service. Error exceptions indicate deviations from correct service, for example, where the device itself (or an external device) does not comply with its correct functional specifications. This may be different from other causes of failure (such as memory management failures or undefined instruction errors) where the hardware system itself is operating correctly, but the information configured by the software has been incorrectly set (e.g., an undefined instruction has been provided, the page table mapping does not specify an address for access in the memory, or a memory access permission has been violated (e.g., writing to a read-only area of ​​the memory)). In many cases, error exceptions may occur after a memory system access, but they may also occur for other reasons (e.g., a fault in a register of a processing circuit). Asynchronous exceptions are exceptions that cannot be attributed to a specific point in the instruction stream being executed. For example, for asynchronous exceptions, unlike synchronous exceptions that can be attributed to a specific point in the instruction stream, it may not be possible to clearly determine which instructions are older instructions that are not affected by the error and which are younger instructions that may be affected by the error. While an asynchronous system error exception may have many causes, a common example of an asynchronous system error may be a data abort triggered by a writeback of dirty data from a cache line to external memory.

[0046] It may be desirable to handle such errors relatively quickly, since delaying the handling of asynchronous system error exceptions may risk error propagation that could lead to larger problems. However, it may also be desirable to support the ability for software or hardware to specify that error exceptions should be masked using masking control information to prevent important state information from being overwritten when the exception is taken. The provision of exception control information for trap masking allows for a compromise in which the exception may be handled with kernel priority in most cases where the asynchronous system error exception will not be masked, but there is a safety net that allows firmware to handle the exception with priority in cases where the masking control information has been set to a masked state.

[0047] The exception control circuit may also support exceptions of an unmaskable class that cannot be masked based on setting the masking control information to a masked state. It may be expected that since exceptions of this class cannot be masked based on the masking control information, the problem of delaying the handling of exceptions due to this masking discussed above will not occur, and therefore there is no need to trigger any traps based on the exception control information of the trap masking. However, the inventors recognize that even if the exceptions of the unmaskable class will not actually be masked, setting the masking control information to the masking state may signal a preference that the exception will not be taken to preserve important processor states that may otherwise be overwritten when the exception is taken. Therefore, even if the exceptions of the unmaskable class cannot be masked, it is still useful to use the exception control information of the trap masking to control whether a trap to a predetermined trap target exception level is taken when the masking control information is in the masking state. Thus, in at least one scenario where the given exception occurs when the 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-masked exception control information, and the current exception level is an exception level that can be a target exception level for handling the exception, the exception control circuitry can control whether to trap the unmaskable exception to the predetermined trap target exception level depending on whether the trap-masked exception control information is in the trapping state. This helps reduce the likelihood of losing important state due to an overwrite when an exception occurs when the masking control information is in the masked state.

[0048] In the case where the current exception level indicates an exception level that cannot be the target exception level for handling the exception (eg, the lowest privileged exception level), there is no need to trigger a trap for an unmaskable exception based on the exception control information of the trap mask.

[0049] Exceptions of the unmaskable class may, for example, include a synchronous external abort exception indicating a deviation from correct service. Again, the deviation from correct service may be caused by any of the example events described above for the asynchronous system error exception, but in contrast to asynchronous exceptions, synchronous exceptions are exceptions that can be attributed to a specific point in the executed instruction stream. For example, a synchronous exception may be an error (such as a failed error correction code check) detected in the memory system after a demand memory access issued after execution of a specified instruction (rather than an error detected for a cache writeback that is very likely to be considered an asynchronous error), and therefore can be attributed to a specific point in the instruction stream.

[0050] The device may include multiple groups of one or more exception syndrome registers, each group of one or more exception syndrome registers storing the exception syndrome information of the exception taken in the corresponding exception level in the exception level. Although the software may choose to set the masking control information to the masking state due to any arbitrary software-specific reason, the common reason for setting the masking control information to the masking state may be that a previous exception is being processed, and if a subsequent exception is brought to the exception level, it is not expected that the information related to the previous exception is overwritten in the relevant syndrome register for the current exception level. Therefore, bringing the trap to the predetermined trap target exception level can help protect the information in the group of one or more syndrome registers associated with the current exception level, while still allowing the exception to be taken quickly. Therefore, the technology described above can be particularly useful in the architecture of the grouped exception syndrome register group that allows the storage of exception information associated with exceptions processed at different exception levels for a specific exception level.

[0051] The techniques discussed above may be implemented in a hardware processor having hardware circuit features that provide processing circuitry and exception control circuitry as discussed above. The hardware device may have registers provided in hardware to store control information as described above.

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

[0053] Such simulation computer programs may be useful to allow target programs developed according to a target instruction set architecture to be executed on a host data processing device that does not natively support the target instruction set architecture. This may be useful for many reasons, such as allowing old code to be executed on newer devices that do not support the architecture for which the code was developed, or for testing target programs under development for a new instruction set architecture that will be released in the future before any hardware devices supporting the new instruction set architecture are available. Although hardware-implemented devices may have hardware circuits that provide the features discussed above, 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 may be executed on the simulation program to give the same results as if the target program were executed by a corresponding hardware device that natively supports the target instruction set architecture.

[0054] Thus, the computer program may have a handler logic and an exception control program logic that operate in a manner similar to the processing circuit and exception control circuit discussed above. The exception control program logic may control exception handling based on control information stored in at least one storage location of at least one register of a target instruction set architecture used by the target code stored in a host data processing device. Simulated exceptions of maskable categories may be handled in the manner discussed above, wherein in the case where the masking control information is in a masked state, a trap to a predetermined trap target exception level is controlled based on the exception control information masked by the trap. Thus, the target code executed on the emulation program (which may include corresponding pieces of software executed at different emulation exception levels) may see the same effect as if it were executed on a hardware device supporting the same architecture control options as discussed earlier.

[0055] Figure 1 An example of a data processing apparatus 2 is schematically illustrated. 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 to generate 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 any required operands to be available in registers 14. When the required operands are determined to be available, the instructions are then passed to an execution stage 16 that includes a plurality of execution units 18, 20, 22, 24 for performing processing operations in response to the instructions. The processing operations may use operands read from registers 14 and generate processing results that may be written back to registers 14 by a write-back 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 instructions to physical registers provided in hardware).

[0056] In this example, the 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 in which at least one of an input operand and an output operand is represented in a floating point representation; a branch unit 22 for evaluating the result of a branch instruction for triggering a non-sequential program flow; and a load / store unit 24 for controlling access to a memory. The load / store unit 24 may execute a load instruction that controls the load / store unit to load data from the memory system to the register 14, or execute a store instruction that controls the load / store unit 24 to store data from the register 14 to the memory system. It should be understood that Figure 1 The particular set of execution units 18 to 24 shown in the example of is only one possible implementation, and other implementations may have different sets of execution units. Figure 1 One or more of the types of execution units shown may be omitted, or one of these types may be duplicated so that several execution units of the same type may be provided. Figure 1 Other types of execution units for other categories of processing operations not shown.

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

[0058] 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 for instructions or data, and a main memory 36. However, it should be understood that this is only one example of a possible cache hierarchy, and other examples may have a greater number of cache levels or may have a different relationship between the instruction cache and the data cache.

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

[0060] When an exception occurs, the exception control circuitry can use the register states in registers 14 to determine whether to take the exception, and if so, what operating state the processing circuitry should be in when the exception is taken. If the exception is taken, the exception control circuitry 40 interrupts the processing currently being performed by the pipeline and controls the pipeline to switch to executing an exception handler, which can provide software instructions for responding to the event that occurred as indicated by the exception type.

[0061] Figure 2 1 is a diagram illustrating different execution states (also referred to as exception levels) in which processing circuitry 4 may operate when executing instructions. In this example, there are four exception levels EL0, EL1, EL2, EL3, where exception level EL0 is the least privileged exception level and exception level EL3 is the most privileged exception level. Generally speaking, when executing in a more privileged exception level, the processing circuitry may access some memory locations or registers 14 that are not accessible to lower, less privileged exception levels.

[0062] In this example, exception level EL0 is used to execute applications managed by a corresponding operating system or virtual machine executed at exception level EL1. In the case where multiple virtual machines coexist on the same physical platform, a hypervisor operating at EL2 may be provided to manage the corresponding virtual machines. Figure 2 An example is shown in which a hypervisor manages a virtual machine and the virtual machine manages an application, but it is also possible for the hypervisor to directly manage an application at EL0 (in this case, exception level EL1 may be disabled).

[0063] Although not required, some implementations may implement separate hardware partitions for secure and non-secure operating domains for processing circuitry. The data processing system 2 may have hardware features implemented within the processor and memory systems to ensure that data and code associated with software processes operating in the secure domain are isolated from access by processes operating in the non-secure domain. For example, a hardware partition such as that provided by Cambridge, England, may be used. Provided by Co., Ltd. Alternatively, other hardware-enforced security partitioning architectures may be used. Secure applications (trusted services) may operate in exception level EL0 in the secure domain, and secure (trusted) operating systems or virtual machines may operate in exception level EL1 in the secure domain. In some implementations, there is no support for EL2 in the secure state, and the hypervisor may only execute in the non-secure EL2. In other implementations, secure hypervisors executing in the secure EL2 may be supported, such as Figure 2 In some examples, a security monitoring program for managing transitions between non-secure domains and secure domains may be provided, which executes in exception level EL3. Other implementations may regulate transitions between secure domains in hardware so that a security monitoring program may not be required.

[0064] Figure 3 A subset of registers 14 is shown. The registers include exception synthesis characterization registers that are grouped to provide separate one or more exception synthesis characterization register groups to store exception synthesis characterization information for exceptions taken at corresponding exception levels EL1, EL2, and EL3 (the lowest privilege exception level EL0 cannot take exception levels, so no exception synthesis characterization registers are needed). For example, the synthesis characterization information associated with an exception taken may include information about the cause of the exception (e.g., fault type), information about an address associated with the exception, or any other information useful for enabling an exception handler to decide how to handle the exception.

[0065] Figure 3 Also shown is a subset of control information that the exception control circuit 40 can use to control the handling of exceptions. It should be understood that Figure 3Not all registers provided in the processor are shown, and not all control states provided in those registers are shown. Furthermore, it should be understood that the specific layout of control information across different registers may vary, and that the same information may be represented in different forms. For example, Figure 3 Information shown in different registers may be stored in the same register or in Figure 3 The information shown in the same register in the suffix may be stored in different registers. Therefore, the specific register layout shown is not necessary, and other register layouts may be used to provide the same functionality of the control options. The notation XXX_ELx.YYY refers to the field YYY provided in register XXX, and indicates that the lowest privileged exception level that can be written to the register is exception level ELx. If an attempt is made to write to a register at an exception level that is less privileged than the exception level ELx indicated in the register suffix, it is rejected or caught at a higher exception level.

[0066] In this particular example, the control information includes:

[0067] PSTATE.EL: Indication of the current exception level;

[0068] ·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 indicates a preference for asynchronous exceptions (including asynchronous memory system error exceptions - SError exceptions) targeting the current exception level to be masked to prevent them from being taken until PSTATE.A is cleared to the unmasked state, although this preference may be overridden by other control state options as shown below. For example, masking asynchronous system error exceptions is useful to protect information stored in the exception synthesis characterization register (related to a previous exception), which would otherwise be overwritten if another exception is taken at the same exception level as the previous exception. Although not in Figure 3 , but the PSTATE register may also include other masking fields for masking other classes of exceptions besides asynchronous system error exceptions. However, the examples discussed below refer to the asynchronous system error (SError) exception as a specific example of a maskable class of exceptions. An asynchronous system error is an exception that is signaled when an error that cannot be attributed to a specific point in the executed instruction stream (a deviation from the correct operation of the system hardware) is detected.

[0069] SCR_EL3.EA: An example of a further trap control, which, 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, rather than the exception level at which they would otherwise be handled when SCR_EL3.EA = 0b0.

[0070] HCR_EL2.TEA: Another example of a further trap control, which, when set to 0b1, causes external abort exceptions occurring at EL0, EL1, or EL2 to be routed to EL2 (if not already routed to EL3 based on SCR_EL3.EA), rather than handling their exception level otherwise when HCR_EL2.TEA = 0b0, unless HCR_EL2.TGE or another control requires routing to EL2 or EL3.

[0071] HCR_EL2.TGE: Another example of a further trap control, which indicates whether to "catch general exceptions" to EL2, if set to 0b0, there is no effect on the execution of EL0, while when set to 0b1, exceptions that would normally be routed from EL0 to EL1 will be routed to EL2 instead. 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 runs in the host operating system. If HCR_EL2.E2H is 0b0, exceptions are not taken to EL1, but EL1 controls may still have an effect.

[0072] HCR_EL2.AMO: Another example of a further trap control that indicates whether a physical system error (SError) exception should be routed to EL2. When HCR_EL2.AMO = 0b1, the SError exception is taken to EL2 unless it is routed to EL3 based on SCR_EL3.EA. When HCR_EL2.AMO is 0b0, this is not required (unless HCR_EL2.TGE or another control requires routing to EL2).

[0073] HCR_EL2.E2H: Indicates whether the configuration for running a host operating system (type 2 hypervisor) is supported at EL2, which may affect exception handling at lower levels (such as EL0) (some exceptions that would otherwise be handled at EL1 may instead be handled at EL2 if type 2 hypervisors are supported). When HCR_EL2.E2H=0b1, facilities for supporting host operating systems at EL2 are enabled. When HCR_EL2.E2H=0b0, facilities for supporting host operating systems at EL2 are disabled.

[0074] SCR_EL3.NMEA, SCTLR2_EL2.NMEA, SCTLR2_EL1.NMEA: Corresponding items of unmaskable exception control information associated with exception levels EL3, EL2, and EL1, respectively, which can be set by software executing at those exception levels (or higher privileged exception levels) to control whether SError exceptions can be masked using PSTATE.A to prevent them from being taken at those exception levels. These can each be set to one of an unmaskable state (e.g., 0b1) and a maskable state (e.g., 0b0). When in the unmaskable state, the Serror exception can be taken at the corresponding exception level regardless of the value of PSTATE.A. When in the maskable state, the Serror exception can be masked based on PSTATE.A being set to a masked state (e.g., 0b1) to prevent it from being taken at the corresponding exception level. More details on how these controls affect the handling of the Serror exception are set forth below.

[0075] SCR_EL3.TMEA, HCRX_EL2.TMEA: corresponding items of the trap-masked exception control information associated with EL3 and EL2, respectively, which can be set in a trapped state (e.g., 0b1) to control the capture of an asynchronous Serror exception or a synchronous external abort exception to the corresponding exception level EL3 or EL2 when PSTATE.A is in the masked state (0b1) and the privilege of the current exception level is lower than that of the corresponding exception level EL3 or EL2, or can be set to an untrapped state (e.g., 0b0) in which no capture occurs. The TMEA control is overridden by any trap to EL2 or EL3 caused by one of several 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 the case when the mask control information is in the masked state (PSTATE.A=0b1), and has no effect on the selection of the target exception level when the mask control information is in the unmasked state (PSTATE.A=0b0).

[0076] Therefore, the PSTATE.A flag can be used to protect the integrated characterization register from asynchronous exceptions. When the exception is taken (i.e., the CPU fills the integrated characterization register), the flag is set by the hardware of the processing circuit (automatically, without software intervention), and can also be set / cleared by the software of the instruction set architecture that executes the instruction that indicates that the PSTATE.A flag will be set or cleared. Most of the time, in normal use, the flag is cleared. When the flag is set, the asynchronous exception is masked, that is, it is not taken. This is a problem for asynchronous error exceptions, because failure to immediately take the error exception can cause error propagation. In addition, synchronous exceptions are non-maskable exceptions that have never been masked, which means that (unexpected) synchronous error exceptions can overwrite the integrated characterization register, which is also a problem of error recovery.

[0077] One possible solution to this problem is to direct (route) error exceptions to higher exception levels, each with its own set of comprehensive characterization registers. This is called 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 construction to notify the operating system of the error and allow it to recover. It also makes it more difficult to identify the root cause of the error when the firmware operating at EL2 or EL3 is opaque to the system administrator as usual.

[0078] The example described here introduces a new exception routing control TMEA (trap masked exception control information), which is under the control of software at a higher exception level (such as EL2 or EL3). When PSTATE.A is clear, the error exception is brought to the default exception level that will handle them normally as usual without routing to a higher exception level (assuming that no one of the other controls SCR_EL3.EA, HCR_EL2.TEA, HCR_EL2.TGE, and HCR_EL2.AMO is captured to EL2 or EL3). When PSTATE.A is set and TMEA (at a higher exception level) is set, the error exception (both synchronous and asynchronous) is brought to a higher exception level that 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 configurable TMEA flag. In the case where SCR_EL3.TMEA, HCRX_EL2.TMEA are both set to the trapped state (Ob1) and PSTATE.A is set, the exception is taken to the nearest of these higher exception levels (eg, to EL2 when at EL0 or EL1).

[0079] In this way, PSTATE.A can protect the comprehensive characterization registers from unexpected error exceptions, but the TMEA control set by the higher exception level provides a "safety net" to ensure that in the rare case that PSTATE.A is set to 0b1 to indicate masking, the error will not propagate because the exception can still be quickly brought to the higher exception level. However, in most cases, PSTATE.A will be set to 0b0, and therefore the error exception can be handled directly by the operating system at EL1.

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

[0081] Figure 4 1 is a flow chart illustrating the determination of whether given exceptions in a maskable class of exceptions (e.g., asynchronous system error exceptions) should be considered masked to prevent them from being taken. At step 100, the exception control circuit 40 determines whether the privilege of the current exception level is higher than the exception level at which a given exception of the maskable class (if taken) would be taken if the trap-masked exception control information (i.e., EL2 and EL3TMEA controls) were in an untrapped state. In addition, at step 102, the exception control circuit 40 determines whether the masking control information (PSTATE.A) is in a masked state.

[0082] If the current exception level is more privileged than the default exception level that would handle the exception if taken (ignoring any trapping based on TMEA) or the masking control information (PSTATE.A) is in a masking state, then the exception may be masked, but it may be overridden based on non-maskable exception control information (such as the NMEA control mentioned earlier). In step 104, the exception control circuit 40 determines whether the non-maskable exception control information (the appropriate NMEA control) selected based on the current exception level is set to an unmaskable state (e.g., 0b1). If the non-maskable exception control information is not in an unmaskable state (i.e., it is in a maskable state, e.g., 0b0), then the determination that the exception should be masked at steps 100 or 102 is not overridden, and in step 106, despite being masked, the exception control circuit determines whether there is any reason to trap the exception (e.g., based on TMEA controls, such as those associated with Figure 5 If there is no reason to catch the exception, then at step 107, it is determined that the given exception is masked so that the exception is not taken.

[0083] If the unmaskable exception control information is in an unmaskable state (e.g., 0b1), or in step 106, it is determined that there is a reason to catch an exception, then in step 108, although the result of one of steps 100 and 102 is "yes", it is determined that the given exception is not masked, so that the exception is still taken (because the NMEA control has overridden the initial determination of the masking state, or there is a trap taken based on TMEA control or another control).

[0084] Generally, the applicable NMEA control used at step 104 is selected based on the current abnormality level, but in some examples, other control information may also be relevant. For example, as follows Fig. 8E As shown in more detail in FIG. 1 , if the current exception level is EL3, the applicable NMEA control is SCR_EL3.NMEA; if the current exception level is EL2 or the control information indicates that the processing circuit is currently operating in the host operating system system, the applicable NMEA control is SCTLR2_EL2.NMEA; and if the current exception level is EL1 or EL0 and the processing circuit is not currently operating in the host operating system system (see FIG. 1 ). Figure 8B For example of how to determine whether the processing circuit is operating in the host operating system architecture based on the E2H and TGE fields of HCR_EL2 and the current exception level), the applicable NMEA control is SCTLR2_EL1.NMEA.

[0085] If the privilege of the current exception level is not higher than the default exception level at which the given exception (if taken) would be taken if the TMEA control was in the untrapped state (N (No) of step 100), and the masking control information is not in the masked state (PSTATE.A=0b0), then in step 108, the given exception is not masked and it is determined to be taken.

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

[0087] At step 124, the exception control circuitry determines whether the current exception level is less privileged than a predetermined trap target exception level associated with the trap-masked exception control information (e.g., in EL0 or EL1 if the EL2 or EL3 version of the TMEA control is used; or in 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 the given TMEA control, then the TMEA control is irrelevant. If there is no relevant TMEA control applicable to determine that an exception is handled at the current exception level, then at step 122, if unmasked, the given exception is taken at a target exception level selected independently of the trap-masked exception control information.

[0088] If the masking control information is in the masking state (yes in step 120), and the privilege of the current exception level is lower than the predetermined trap target exception level (EL2 or EL3) associated with at least one item of the trap-masked exception control information, then in step 126, the exception control circuit 40 controls whether to capture the given exception to the predetermined trap target exception level depending on whether the trap-masked exception control information is in the set state. If it is determined that a trap is not required, then in step 128, if the given exception will not be masked, the given exception is taken at the default exception level without being captured based on the trap-masked exception control information. This default exception level may be based on other control state changes (for example, based on the EA, TEA, AMO, E2H, TGE controls mentioned earlier, see below for more detailed examples of how these controls 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-masked exception control information, then in step 130, the given exception is captured to the predetermined trap target exception level associated with the item of the trap-masked exception control information in the set state. If there are more than one relevant entry of the trap-masked exception control information in the trapped state, the trap is taken to the exception level associated with the one of the entries in the trap-masked exception control information in the trapped state (TMEA=0b1) that has the smallest difference in privilege between the current exception level and the associated predetermined trap target exception level (while being different from the current exception level). For example, if the current exception level is EL1 and both the EL2 and EL3 TMEA controls are set to 1, the trap will be taken to EL2, while if the current exception level is EL2, the trap is taken to EL3 even if the TMEA controls of both EL2 and EL3 are set.

[0089] In step 126, the control of whether to capture based on TMEA control may vary depending on which other controls are implemented. Generally speaking, if there is no abnormal control information (TMEA control) masked by the relevant trap in the set state, the trap is not taken. However, in the case of the relevant items in the set state of the abnormal control information masked by the trap, whether the trap occurs may also depend on other parameters. For example, when the abnormal control information (NMEA control) that cannot be masked is supported, in some scenarios, the NMEA control that is set to the unmaskable state can also cover the trap based on the TMEA control in addition to covering any mask based on PSTATE.A. For example, in a scenario where a given exception occurs when the current exception level is the lowest privileged exception level (EL0), the unmaskable exception control information is in an unmaskable state (NMEA control=0b1), and the given exception is to be taken to the next lowest privileged exception level (e.g., the next lowest privileged exception level may be EL1 in a guest operating system architecture or EL2 in a host operating system architecture) that is enabled for taking the given exception when the given exception is unmasked and the trap-masked exception control information is in an untrapped state, even when the trap-masked exception control information (TMEA) is in a trapped state, the exception control circuitry may determine that the given exception should be taken at the next lowest privileged exception level without catching the predetermined trap target exception level. In addition, another scenario where the trap of step 130 may not occur despite the relevant TMEA control being set to the trapped state may be when the EA, AMO, TGE control mentioned earlier has specified 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 capture based on the TMEA may be more complex than just checking the state of the TMEA control itself. The specific decision flow may depend on which other control options are implemented in a particular implementation.

[0090] However, in general, it is useful to provide TMEA controls to enable a user to define a trap that is taken to a higher privileged exception level in at least one scenario where the PSTATE.A flag is set to the masked state, to allow two competing requirements to be satisfied (exceptions are handled promptly, and the comprehensive characterization information associated with the lower privileged exception level is preserved) without necessarily requiring every exception to be taken to the higher level if the PSTATE.A flag is in the unmasked state.

[0091] Figure 61 is a flow chart illustrating control of whether to allow updating of the trap masked exception control information (TMEA control information). At step 150, an instruction requesting an update of the trap masked exception control information is executed. At step 152, the processing circuit 4 determines whether the privilege of the current exception level is lower than the predetermined trap target exception level associated with the trap masked exception control information requested to be updated (EL2 for HCRX_EL2.TMEA and EL3 for SCR_EL3.TMEA). If so, then at step 154, the attempt to update the trap masked exception control information is rejected outright or trapped at a higher privileged exception level so that software at the higher privileged exception level can determine whether the requested update is allowed. If the current exception level is the predetermined trap target exception level or an exception level that is more privileged than the predetermined trap target exception level, then at step 156, the requested update of the trap masked exception control information is allowed at the current exception level (unless there is any other control implemented that would trap such a write to the trap masked exception control information for other reasons). For example, software at EL3 may set controls to trap accesses to HCRX_EL2, causing writes to the EL2TMEA controls to be trapped from EL2 to EL3.

[0092] Figure 7 1 is a flow chart illustrating a category of handling unmaskable exceptions (e.g., synchronous external abort exceptions). At step 160, an unmaskable exception of the category is detected. At step 162, the exception control circuit determines whether the control information in register 14 indicates a scenario in which the privilege of the current exception level is less than a predetermined trap target exception level associated with a given item of the exception control information masked by the trap, and the current exception level can be a target exception level for handling the exception (e.g., EL0 may not be the target exception level). If not, then at step 164, a trap based on TMEA control is not required, and an exception of the unmaskable category is taken at a target exception level selected based on the current exception level and / or based on other control information (outside of TMEA control).

[0093] If, in step 162, it is determined that the privilege of the current exception level is lower than the predetermined trap target exception level associated with a given item of the trap-masked exception control information, and the current exception level is capable of being the target exception level for handling the exception (and optionally, in some examples, at least one other condition is satisfied, e.g., depending on SCR_EL3.EA or HCR_EL2.TEA control that may require a trap to behave differently than indicated by the TMEA), then a trap based on TMEA control (the trap-masked exception control information) but depending on other parameters is feasible.

[0094] At step 166, the exception control circuit determines whether the mask control information is in the masked state (e.g., PSTATE.A=0b1). If not, then at step 168, no TMEA-based trap is required and an unmaskable exception is taken at a target exception level selected based on the current exception level and / or other control information.

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

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

[0097] Therefore, even if the PSTATE.A flag does not result in masking of unmaskable exceptions, it can be considered to be used to control whether to trap exceptions to higher privilege levels based on TMEA control. This is useful because there is a preference to retain comprehensive characterization information when the PSTATE.A flag is set, so catching higher exception levels helps meet this requirement, even if there is actually no masking. However, making the trap dependent on PSTATE.A helps increase the use of kernel priority exception handling and reduces the number of times the firmware needs to handle exceptions, simplifying software development.

[0098] It should be understood that in portions of the flowchart where the outcome of a flow chart depends on the checking of multiple conditions, those conditions may be checked in any order or in some cases at least partially in parallel, so the particular order of steps shown in the flow chart indicates one example of how this may be accomplished.

[0099]

[0066] More detailed examples of how the various items of control information described earlier may be used to control exception handling are now described.

[0100] FIG. 8A to FIG. 8OIllustrate the handling of an asynchronous system error (SError) exception indicating that an error was detected after a memory system access, where the error cannot be attributed to a specific point in the instruction stream, so it is not known which instructions may be affected by the error. This is an example of the above-mentioned maskable class of exceptions. As a whole, these figures illustrate the use of the current exception level at the time of the exception and Figure 3 The control information shown determines whether an exception should be masked, and if not, which exception level should take care of the exception.

[0101] Fig. 8A The determination of the value route_to_el3 indicating whether the SError exception will be routed from a lower exception level to be taken at EL3 is illustrated. If the current exception level is not EL3 (No of step 1000) and SCR_EL3.EA=0b1 (Yes of step 1002), route_to_el3 is true (step 1006), indicating that the exception will be routed to EL3. If the current exception level is EL3 (Yes of step 1000) or SCR_EL3.EA=0b0 (No of step 1002), route_to_el3 is false (step 1004).

[0102] Figure 8B The determination of the value IsInHost() indicating whether the process is currently in the host operating system system (type 2 hypervisor) is illustrated. If in the guest operating system system, IsInHost() is false, and if in the host operating system system, it is true. If the current exception level is neither EL2 (no of step 1008) nor EL0 (no of step 1014), IsInHost() is false (step 1018). If the current exception level is EL2 (yes of step 1008), but HCR_EL2.E2H is 0b0 (no of step 1010) or if the current exception level is EL0 (yes of step 1014) and one or both of HCR_EL2.E2H and HCR_EL2.TGE are 0b0 (no of 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 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).

[0103] Figure 8CThe determination of the value route_to_el2 indicating whether the SError exception will be routed from the lower exception level EL0 or EL1 to be taken at EL2 is illustrated. If route_to_el3 is true (no of step 1020), then route_to_el2 is false (step 1032). If route_to_el3 is false (yes of step 1020) and the current exception level is EL2 or EL3 (no of both steps 1022 and 1030), then route_to_el2 is false (step 1032).

[0104] If route_to_el3 is false (Yes in step 1020) and the current exception level is EL1 (Yes in step 1022), then:

[0105] At step 1026, if HCR_EL2.AMO is 0b1 (Yes at step 1024), then route_to_el2 is true and

[0106] In step 1028, if HCR_EL2.AMO is 0b0 (No in step 1024), route_to_el2 is false.

[0107] 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 if Figure 8B If IsInHost() determined in the process is true (No in step 1034) or both HCR_EL2.E2H and HCR_EL2.TGE are set to 0b0 (Yes in step 1038), route_to_el2 is false (step 1036).

[0108] If route_to_el3 is false (Yes in step 1020), the current exception level is EL0 (No in step 1022, Yes in step 1030), then IsInHost() Figure 8B is determined to be false during the process (Yes in step 1034), and one or both of HCR_EL2.E2H and HCR_EL2.TGE are set to 0b1 (No in step 1038), then route_to_el2 is true (step 1040).

[0109] Fig.8D exemplifies an initial determination of whether an SError exception should be masked (as in Fig. 8E and Figure 8FAs mentioned below, it is possible to override this initial determination based on the value of soft_masked based on the unmaskable abnormal control information (NMEA control). The determination of soft_masked depends on the current abnormality level (step 1042).

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

[0111] If the current exception level is EL2, then:

[0112] If Fig. 8A If route_to_el3 determined in step 1052 is true (No in step 1052), soft_masked is false (step 1054).

[0113] If route_to_el3 is false (Yes in step 1052), then:

[0114] o If both HCR_EL2.TGE and HCR_EL2.AMO are 0 (Yes at step 1056) or if PSTATE.A=1 (Yes at step 1058), soft_masked is true (step 1060).

[0115] o If one or both of HCR_EL2.TGE and HCR_EL2.AMO are 0b1 (No at step 1056) and PSTATE.A=0 (No at step 1058), then soft_masked is false (step 1062).

[0116] If the current exception level is EL0 or EL1, then:

[0117] If Fig. 8A route_to_el3 determined in step 1064 is true (no in step 1064) or Figure 8C If route_to_el2 determined in step 1066 is true (No in step 1066), soft_masked is false (step 1070).

[0118] If both route_to_el3 and route_to_el2 are false, if PSTATE.A=1 (yes of step 1068), soft_masked is true (step 1072), and if PSTATE.A=0 (no of step 1068), soft_masked is false (step 1070).

[0119] It should be noted that because steps 1044 and 1056 are passed, if the EA, TGE, AMO controls have not been set to trap the SError exception at one of the higher levels, the effect of steps 1044 and 1056 is that the SError exception can be considered to be masked at steps 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 for taking the exception level (ignoring the TMEA trap control).

[0120] Fig. 8E The example shows which of the corresponding items of the non-maskable abnormal control information (NMEA control) is selected to determine the Fig.8D Whether the masking state determined in should be overwritten. This depends on the current exception level and the Figure 8B 1076). If the current abnormal level is EL3 (Yes in step 1076), the NMEA control used is SCR_EL3.NMEA (step 1078). If the current abnormal level is EL2 (Yes in step 1080) or IsInHost() is true (Yes in step 1084), the NMEA control used is SCTLR2_EL2.NMEA (step 1082). If the current abnormal level is EL1 or EL0 (No in step 1080) and IsInHost() is false (No in step 1084), the selected NMEA control is SCTLR2_EL1.NMEA (step 1086).

[0121] Figure 8F Illustrate the application of selected NMEA controls to determine Fig.8D The initial mask determines whether it should be overwritten to prevent masking of SError exceptions. Fig.8D1098), it will remain false regardless of the value of the selected NMEA control (step 1100). If soft_masked is true (step 1098 yes) and the selected NMEA control is in the unmaskable state 0b1 (step 1102 no), then soft_masked becomes false (step 1100), so that the previous masked state has been overwritten based on the unmaskable indication provided by the NMEA control. If soft_masked is true (step 1098 yes) and the selected NMEA control is in the maskable state 0b0 (step 1102 yes), then soft_masked remains true (step 1104), and therefore the SError exception will be masked to prevent it from being taken (again, the exception remains pending and therefore can still be taken if the PSTATE.A flag is later cleared to the unmasked state 0b0).

[0122] Figure 8G Illustrated is the determination of the signal route_soft_masked_to_el2 indicating whether a trap to EL2 should be taken based on the EL2 version HCRX_EL2.TMEA of the TMEA control. This is the trap taken when PSTATE.A=1 to ensure that SError exceptions can be handled more quickly at EL2 while still retaining the exception synthesis characterization information in the EL1 synthesis characterization register set.

[0123] In step 1122, if Fig. 8A If route_to_el3 determined in step 1108 is true (no at step 1108) or the external debugger has disabled exceptions from being taken at exception levels below EL3 (yes at step 1110), then parameter route_soft_masked_to_el2 is determined to be false (i.e., a TMEA-based trap does not occur). Assuming that neither of these conditions are met (yes at step 1108 and no at step 1110), then:

[0124] If HCRX_EL2.TMEA is in the untrapped state (0b0—NO of step 1112), then route_soft_masked_to_el2 is false (step 1122), because in this case, EL2 software has not yet set the trap-masked exception control information to indicate that a trap to EL2 that depends on PSTATE.A is desired.

[0125] If HCRX_EL2.TMEA is in the Trapped state (0b1, YES of step 1112), a trap to EL2 due to TMEA is possible, but whether it occurs also depends on other parameters:

[0126] o If the current exception level is EL1 (Yes at step 1114) and PSTATE.A is in the masked state (0b1, Yes at step 1116), route_soft_masked_to_el2 is true (step 1118).

[0127] o If the current exception level is EL1 (Yes at step 1114) but PSTATE.A is in the unmasked state (0b0, No at step 1116), route_soft_masked_to_el2 is false (step 1120).

[0128] o If the current anomaly level is ELO (Yes at step 1124), the masked state (after any NMEA overlays are evaluated) is true (Yes at step 1126) and Figure 8B If IsInHost() determined in step 1126 is false (Yes in step 1128), route_soft_masked_to_el2 is true (step 1130). It should be noted that in step 1126, the term "soft_masked" refers to Figure 8F The final masking state is determined based on NMEA during the process, rather than during Fig.8D The initial masking state (before any NMEA overlay) is determined in .

[0129] If the current abnormal level is EL0 (Yes in step 1124), the masking state is as in Figure 8F After NMEA coverage (not in Fig.8D The initial masking state determined in step 1126) is determined to be false (No in step 1126) or Figure 8B If IsInHost() determined in is true (No in step 1128), route_soft_masked_to_el2 is false (step 1122).

[0130] o If the current exception level is EL2 or EL3 (No at step 1124), route_soft_masked_to_el2 is false (step 1122).

[0131] Figure 8H The example indicates whether a trap to EL3 should be taken based on the determination of the signal route_soft_masked_to_el3 taken by the EL3 version of the TMEA control SCR_EL3.TMEA. In addition, if taken, the trap is intended to allow the SError exception to be handled more quickly at EL3, while still enabling the exception synthesis characterization information in the synthesis characterization registers of the EL1 or EL2 group to be preserved, assuming PSTATE.A=1.

[0132] If exception handling at EL3 is disabled by the external debugger (yes at step 1136 ), route_soft_masked_to_el3 is false (step 1134 ).

[0133] If SCR_EL3.TMEA is in the untrapped state (0b0, No of step 1138), 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.

[0134] If exceptions are not disabled at EL3 by the external debugger (No at step 1136) and SCR_EL3.TMEA is in the trapped state (0b1, Yes at step 1138), a trap to EL3 due to TMEA is possible, but whether it occurs also depends on other parameters:

[0135] If one of route_to_el2 or route_soft_masked_to_el2 is true (step 1140 or no at step 1142), then:

[0136] o If the privilege of the current exception level is lower than EL3 (No at step 1150) and taking exceptions at a level lower than EL3 is currently disabled by the external debugger (Yes at step 1152), then route_soft_masked_to_el3 is true (step 1154); and

[0137] o If the current exception level is EL3 (Yes at step 1150) or taking exceptions at a level less privileged than EL3 is not currently disabled by an external debugger (No at step 1152), then route_soft_masked_to_el3 is false (step 1156).

[0138] Therefore, when an external debugger is disabled, exceptions are not taken at EL0 to EL2, as Figure 8G The determined TMEA trap to EL2 will take precedence over the TMEA trap to EL3 - due to step 1142, if both SCR_EL3.TMEA and HCRX_EL2.TMEA are set to the trapped state, the trap will be taken to EL2 (the exception level closest to the EL1 / EL0 level where an SError can occur (with the smallest difference in privilege) when HCRX_EL2.TMEA is relevant).

[0139] If both route_to_el2 and route_soft_masked_to_el2 are false (yes in steps 1140 and 1142), then route_soft_masked_to_el3 is true (step 1146) if either:

[0140] o The current exception level is EL2 or EL1 and PSTATE.A is in the masked state (0b1, YES in step 1144), or

[0141] o The current exception level is EL2 or EL0 and the masked state is true (yes in step 1148). In addition, soft_masked in step 1148 refers to Figure 8F During the process of masking after NMEA coverage (not in Fig.8D The initial masking state determined in ).

[0142] If both route_to_el2 and route_soft_masked_to_el2 are false (yes at steps 1140 and 1142), the conditions tested at steps 1144 and 1148 are not satisfied, the current exception level is less privileged than EL3 (no at step 1150), and taking exceptions at a level less privileged than EL3 is currently disabled by an external debugger (yes at step 1152), then route_soft_masked_to_el3 may also be true (step 1154).

[0143] Notice Figure 8G between steps 1116 and 1126 and Figure 8H For exceptions that occur when the current exception level is EL1, the TMEA trap depends on PSTATE.A being 1 regardless of Fig.8F The actual masking state determined in EL1 has been overridden using NMEA control. This is because in EL1, setting PSTATE.A to the masked state (0b1) indicates that the current state of processing at EL1 is such that there is some important comprehensive characterization information to be protected in the EL1 comprehensive characterization registers, so even if the masking has been overridden using NMEA control, it is still desirable to execute a TMEA trap to EL2 or EL3 to protect the comprehensive characterization information in the EL1 comprehensive characterization registers. In contrast, for exception level EL0, the TMEA trap depends on the Figure 8F1. The actual masking state determined in (after being overridden using the NMEA control). Thus, a NMEA control set to 1 will prevent a TMEA trap from being taken from EL0 to EL2 or EL3, and instead a non-masked exception will be taken to its default exception level (e.g., EL1) unless another control takes priority (e.g., EA, AMO, TGE control). This behavior of EL0 is useful because there is no exception comprehensive characterization information to protect in the EL0 exception level (which cannot be the target exception level for handling exceptions), and since it can be assumed that there has been a previous exception passed back to EL0 since the capture of the EL1 comprehensive characterization information, no EL1 comprehensive characterization information is needed, so even if the relevant TMEA control is set, no trap to EL2 or EL3 is needed. Therefore, even if the relevant TMEA control is set to the set trap state (0b1), in the case where the NMEA control has prevented masking from occurring, no trap to EL2 or EL3 is needed to protect the comprehensive characterization information of EL1.

[0144] Figure 8I The determination of a "routed_away" indication indicating whether there is any reason to route the SError exception away from the default exception level (e.g., EL1 in a guest operating system environment, or EL2 in a host operating system environment) at which the exception would otherwise be taken is shown. Figure 8C , Figure 8G , Fig. 8A and Figure 8H If any of route_to_el2, route_soft_masked_to_el2, route_to_el3 or route_soft_masked_to_el3 determined in the process is true (yes of steps 1158, 1162, 1164, 1166), the routed_away indication is true (step 1160). If route_to_el2, route_soft_masked_to_el2, route_to_el3 and route_soft_masked_to_el3 are all false (no of step 1166), routed_away is false (step 1168).

[0145] Figure 8J The determination of the final masking state indicating whether an exception is actually masked (prevented from being taken) is illustrated. Figure 8F In the soft_masked determined after any NMEA overlay is true (step 1170 is true) and as in Figure 8IIf routed_away is false (yes of step 1174), masked is true (step 1176), indicating that the exception will be prevented from being taken. If soft_masked (after any NMEA overlay) is false (no of step 1170) or routed_away is true (no of step 1174), masked is false (step 1172) because the exception will be taken.

[0146] Figure 8K The determination of whether the exception should be taken at EL3 is illustrated. If the current exception level is EL3 (Yes at step 1178) and the exception is not masked (Yes at step 1180), then take_in_el3 is true (step 1184), otherwise take_in_el3 is false (step 1182).

[0147] Figure 8L The determination of whether the exception should be taken at EL2 (take_in_el2_0) is illustrated. If the current exception level is EL2 (yes in step 1186) or if Figure 8B IsInHost() determined in is true (step 1188 is), as in Figure 8I The routed_away determined in step 1192 is false (yes in step 1192) and if Figure 8J If the exception is determined to be unmasked (Yes in step 1194), take_in_el2_0 is true (step 1196). Otherwise, take_in_el2_0 is false (step 1190).

[0148] Figure 8M The determination of whether the exception should be taken at EL1 (take_in_el1_0) is illustrated. If the current exception level is EL1 (Yes at step 1198) or the current exception level is EL0 and IsInHost() is false (Yes at step 1200), routed_away is false (Yes at step 1204) and the exception is determined to be unmasked (Yes at step 1206), then take_in_el1_0 is true (step 1208). Otherwise, take_in_el1_0 is false (step 1202).

[0149] Figure 8N Illustrate the selection of a target exception level for taking an exception. Figure 8J If it is determined to be masked (NO at step 1210), the target exception level is unknown since the exception will not be taken.

[0150] If the "masked" state is false (yes in step 1210) and take_in_el3 ( Figure 8K )、route_to_el3( Fig. 8A ) and route_soft_masked_to_el3( Figure 8H ) is true (yes in step 1214), the target exception level is EL3 (step 1216).

[0151] If masked is false (yes at step 1210), the exception will not be taken at EL3 (no at step 1214), and take_in_el2_0 ( Figure 8L )、route_to_el2( Figure 8C ) and route_soft_masked_to_el2( Figure 8G ) is true (yes in step 1218), the target exception level is EL2 (step 1220).

[0152] If masked is false (yes at step 1210), the exception will not be taken at EL3 or EL2 (no at steps 1214 and 1218), then the target exception level is EL1 (step 1224). Note that in some cases, there may be an additional check whether "take_in_el1_0" is true before determining that the target exception level is EL1 (depending on the Figure 8M However, in practice, as mentioned in the pseudo code below, the state when the results of steps 1210, 1214, and 1218 are all negative and "take_in_el1_0" is false should be unreachable, so the check whether "take_in_el1_0" is true may be redundant.

[0153] Fig.8O Demonstrates the use of an external debugger in Figure 8N The further ability to mask exceptions by disabling exceptions at the target exception level is determined. If the external debugger has disabled exceptions at the target exception level (yes at step 1228), masked becomes true and the target exception level becomes unknown (step 1232). Otherwise, maintain the state as respectively according to Figure 8J and Figure 8N The determined masking state and target anomaly level.

[0154] FIG. 9A to FIG. 9I The processing of a synchronous external abort exception indicating that an external memory system error (other than an MMU failure) is detected after a memory system access, where the error can be attributed to a specific point in the executed instruction stream. This is an example of an exception of the non-maskable class described above. The figures as a whole illustrate the use of the current exception level at the time of the exception and Figure 3 The control information shown determines which exception level of the exception should be taken. This type of exception cannot be masked. FIG. 9A to FIG. 9IReferences to "IsInHost()" in Figure 8B The same approach as shown for asynchronous SError exceptions is used, so it is not repeated here.

[0155] Fig. 9A The determination of the value route_to_el3 indicating whether a synchronous external abort exception is to be routed from a lower exception level to be taken at EL3 is illustrated. If the current exception level is not EL3 (No at step 1234) and SCR_EL3.EA=0b1 (Yes at step 1236), route_to_el3 is true (step 1240), indicating that the exception is to be routed to EL3. If the current exception level is EL3 (Yes at step 1234) or SCR_EL3.EA=0b0 (No at step 1236), route_to_el3 is false (step 1238).

[0156] Fig. 9B The determination of the value route_to_el2 indicating whether a synchronous external abort is to be routed from a lower exception level to be taken at EL2 is illustrated. Reference to "tea_bit" refers to the value of the HCR_EL2.TEA control (step 1254). If as in Fig. 9A If route_to_el3 determined in step 1256 is true (No in step 1256), route_to_el2 is false (step 1258).

[0157] If route_to_el3 is false (Yes in step 1256) and the current exception level is EL1 (Yes in step 1260), then:

[0158] If tea_bit is 1 or the fault is of a specific type to be handled at EL2 (yes at step 1262), route_to_el2 is true (step 1264). For example, the specific type of fault to be handled at EL2 may include a fault related to access to a system register managed by software executing at EL2 that is being emulated through access to memory, or may be a second-level address translation fault detected by an MMU in a two-level address translation hierarchy, where address translation is controlled based on a first-level page table defined by an operating system to map a virtual address to an intermediate address, and based on a second-level page table defined by a hypervisor to map an intermediate address to a physical address.

[0159] If tea_bit is 0 and the fault is not a type to be handled at EL2 (No at step 1262), then route_to_el2 is false (step 1266).

[0160] If route_to_el3 is false (Yes in step 1256) and the current exception level is EL0 (Yes in step 1268), then:

[0161] If IsInHost() (according to Figure 8B If the fault is one of the types to be handled at EL2 (yes at step 1274), route_to_el2 is true (step 1276).

[0162] route_to_el2 is false (step 1272) if IsInHost() is true (no at step 1270) or all of the following conditions are met: tea_bit = 0b0, HCR_EL2.TGE = 0b0 and the fault is not a type to be handled at EL2 (no at step 1274).

[0163] If the current exception level is EL3 or EL2, route_to_el2 is false (step 1278, after the no of step 1268).

[0164] Fig. 9C Illustrated is the determination of the signal route_soft_masked_to_el2 indicating whether a trap to EL2 should be taken based on the EL2 version HCRX_EL2.TMEA of the TMEA control. This is the trap taken when PSTATE.A=1 to ensure that synchronous external abort exceptions can be handled more quickly at EL2 while facilitating the preservation of the exception synthesis characterization information in the set of EL1 synthesis characterization registers.

[0165] The parameter route_soft_masked_to_el2 is determined to be false (step 1282) if any one or more of the following apply:

[0166] ·route_to_el3 (as per Fig. 9A Determine) is true (No in step 1280);

[0167] The current exception level is any exception level other than EL1 (No at step 1284);

[0168] PSTATE.A = 0 (No at step 1286);

[0169] HCRX_EL2.TMEA=0 (No in step 1288).

[0170] The parameter route_soft_masked_to_el2 is determined to be true (step 1282) if all of the following conditions are met:

[0171] route_to_el3 is false (yes in step 1280);

[0172] The current exception level is EL1 (Yes in step 1284);

[0173] PSTATE.A = 1 (Yes in step 1286);

[0174] HCRX_EL2.TMEA=1 (Yes in step 1288).

[0175] Therefore, HCRX_EL2.TMEA being set to 1 (trapped state) causes synchronous external abort exceptions to be trapped at EL2 if they occur at EL1 while PSTATE.A is set to the masked state. If PSTATE.A is 0 (unmasked state), the trap is not taken.

[0176] Fig.9D It illustrates indicating whether a trap to EL3 should be taken based on the determination of the signal route_soft_masked_to_el3 taken by the EL3 version SCR_EL3.TMEA controlled by TMEA.

[0177] The parameter route_soft_masked_to_el3 is determined to be false (step 1294) if any one or more of the following apply:

[0178] ·route_to_el2 (as per Fig. 9B Determine) is true (No in step 1292);

[0179] route_soft_masked_to_el2 (as per Fig. 9C Determine) is true (no in step 1296);

[0180] The current exception level is any exception level other than EL1 or EL2 (No at step 1298).

[0181] PSTATE.A=0 (No in step 1300).

[0182] SCR_EL3.TMEA=0 (No in step 1302).

[0183] The parameter route_soft_masked_to_el3 is determined to be true (step 1304) if all of the following conditions are met:

[0184] route_to_el2 is false (yes in step 1292);

[0185] route_soft_masked_to_el2 is false (No at step 1296);

[0186] The current exception level is EL1 or EL2 (Yes in step 1298);

[0187] PSTATE.A = 1 (Yes in step 1300);

[0188] ·SCR_EL3.TMEA=1 (Yes in step 1302).

[0189] Therefore, SCR_EL3.TMEA is set to 1 (trapped state) causing synchronous external abort exceptions to be trapped to EL3 if they occur at EL1 or EL2 based on HCRX_EL2.TMEA or HCR_EL2.TEA when PSTATE.A is set to 1 (masked state). If PSTATE.A is 0 (unmasked state), the trap is not taken.

[0190] Fig.9E The determination of a "routed_away" indication indicating whether there is any reason to route a synchronous external abort exception away from the default exception level (e.g., EL1 or EL2) at which the exception would otherwise be taken is illustrated. Fig. 9B , Fig. 9C , Fig. 9A and Fig.9D If any of route_to_el2, route_soft_masked_to_el2, route_to_el3 or route_soft_masked_to_el3 determined in the process is true (yes of steps 1306, 1310, 1312, 1314), the routed_away indication 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 of steps 1306, 1310, 1312, 1314), routed_away is false (step 1316).

[0191] Fig.9F The determination of whether the exception should be taken at EL3 (take_in_el3) is illustrated. If the current exception level is EL3 (yes at step 1318), then take_in_el3 is true (step 1322), otherwise take_in_el3 is false (step 1320).

[0192] Figure 9G The determination of whether the exception should be taken at EL2 (take_in_el2_0) is illustrated. If the current exception level is EL2 (yes in step 1324) or if Figure 8B IsInHost() determined in is true (yes in step 1326), and as in Fig.9E If routed_away determined in is false (Yes in step 1330), take_in_el2_0 is true (step 1332). Otherwise, take_in_el2_0 is false (step 1328).

[0193] Figure 9H The determination of whether the exception should be taken at EL1 (take_in_el1_0) is illustrated. If the current exception level is EL1 (Yes at step 1334) or the current exception level is EL0 and IsInHost() is false (Yes at step 1336) and routed_away is false (Yes at step 1340), then take_in_el1_0 is true (step 1342). Otherwise, take_in_el1_0 is false (step 1338).

[0194] Fig.9I Illustrate the selection of the target exception level for taking an exception. If take_in_el3( Fig.9F )、route_to_el3( Fig. 9A ) and route_soft_masked_to_el3( Fig.9D ) is true (yes in step 1344), the target exception level is EL3 (step 1346).

[0195] If the exception will not be taken at EL3 (NO at step 1344) and take_in_el2_0 ( Figure 9G )、route_to_el2( Fig. 9B ) and route_soft_masked_to_el2( Fig. 9C ) is true (yes in step 1348), the target exception level is EL2 (step 1350).

[0196] If the exception is not to be taken in EL3 or EL2 (No at step 1348), then the target exception level is EL1 (step 1354). Note that in some cases there may be an additional check whether "take_in_el1_0" is true before determining that the target exception level is EL1 (depending on the Figure 9HHowever, in practice, as mentioned in the pseudo code below, the state when the results of steps 1344 and 1348 are both negative and "take_in_el1_0" is false should be unreachable, so the check whether "take_in_el1_0" is true may be redundant.

[0197] For the flow chart shown above, it should be understood that the same logic function can be reached by executing steps in different orders or performing some steps in parallel. In addition, not all steps are necessary for a given embodiment. In some specific implementations, some types of abnormal routing control may not be supported, as shown in the following pseudo code, wherein there are some additional tests (for example, see the variable test of "??? Enabled()" or "Have???()" form for some optional features, which is the variable indicating whether some optional features are enabled and realized). If a feature in these optional features is not supported, the AND or Boolean relation shown in the pseudo code shows what will happen. In most cases, if abnormal routing control is not supported, the corresponding control value is regarded as 0b0.

[0198] To achieve FIG. 8A to FIG. 8O A sample pseudocode of the functionality is shown below:

[0199]

[0200]

[0201]

[0202]

[0203]

[0204] The sample pseudo code of the function IsInHost() is as follows:

[0205]

[0206] Fig. 10A and Fig. 10B A summary table is shown indicating whether, for each combination of values ​​of control information, an asynchronous system error (SError) exception occurring in any of the exception levels EL0, EL1, EL2, EL3 will be taken or masked, and if taken, which exception level will be the target exception level for taking the exception.

[0207] Each column on the left side of the table refers to a bit in one of the system registers for a flagged exception level, or to a PSTATE.A flag (where the "x" indicates that it does not matter whether the corresponding control is 0b0 or 0b1), as shown below:

[0208] EA EL3 means SCR_EL3.EA

[0209] TMEA EL3 means SCR_EL3.TMEA

[0210] NMEA EL3 means SCR_EL3.NMEA

[0211] TGE EL2 means HCR_EL2.TGE

[0212] ·E2H EL2 means HCR_EL2.E2H

[0213] AMO EL2 means HCR_EL2.AMO

[0214] NMEA EL2 means SCTLR2_EL2.NMEA

[0215] TMEA EL2 means HCRX_EL2.TMEA

[0216] NMEA EL1 means SCTLR2_EL1.NMEA

[0217] ·A PSTATE means PSTATE.A.

[0218] Each column in the right side of the table shows the result if the SError exception occurs for the corresponding control information value of the group when the current exception level is EL3, EL2, EL1, EL0 respectively. Each cell in the right column represents one of the following results:

[0219] ELx means taking the error exception to ELx.

[0220] B means that since the error exception is masked by PSTATE.A, it is not taken and remains pending.

[0221] C means that since the error exception is implicitly masked (due to the current exception level being more privileged than the exception level at which it should be taken), it is not taken and remains pending.

[0222] Not Applicable (n / a): Indicates that the exception level cannot be accessed in this configuration.

[0223] These values ​​are based on the pseudo code above and FIG. 8A to FIG. 8O The functions shown in are determined.

[0224] Any control options other than TMEA and PSTATE.A are optional and, if omitted, are treated in the same manner as if they were set to 0b0.

[0225] Fig. 10A and Fig. 10B Noteworthy example lines in include:

[0226] • Line 1: Error exceptions at EL1 and EL0 are taken to the default exception level EL1, and are implicitly masked at EL2 and EL3 due to being in a higher privileged exception level than the default exception level EL1. Trap control has not been set yet.

[0227] Line 2: Setting PSTATE.A to 1 causes the FAULT exception to be masked at EL1 and EL0.

[0228] Line 3: Setting NMEA EL1 to 1 prevents the mask error exception from occurring even if PSTATE.A is 1.

[0229] Lines 4 and 5: Set TMEA EL2 to 1, causing an error exception to be caught from EL1 or EL0 to EL2 if PSTATE.A is 1, but if PSTATE.A is 0, the behavior remains the same as line 1.

[0230] Line 6: If TMEA EL2 and NMEA EL1 are both 1 and PSTATE.A is 1, the unmaskable state caused by NMEA=1 overrides the trap to EL2 if the error exception occurs at EL0, but not if the error exception occurs at EL1, so that when TMEA EL2, NMEA EL1, and PSTATE.A are all 1, but no other trap controls are set, error exceptions occurring at EL0 are taken at EL1, but error exceptions occurring at EL1 are taken at EL2.

[0231] • Line 7: Setting NMEA EL2 to 1 means that even if an error exception occurs at EL2, the error exception is taken to EL2 instead of being implicitly masked as in lines 1 to 6.

[0232] • Lines 13 to 19 and 63 to 68: When any of the EA EL3, TGE EL2 and AMO EL2 controls are set, the TMEA control has no effect as there is an explicit routing of the error exception to EL2 or EL3 in these cases.

[0233] Line 41: If both TMEA EL3 and TMEA EL2 are set and PSTATE.A is set, bring TMEA-based traps from EL0 and EL1 to EL2, i.e., the TMEA-associated exception level closest in privilege to the current exception level, and bring TMEA-based traps from EL2 to EL3. Line 42 shows how this will override the TMEA-based trap from EL0 if NMEA EL1 is 1, causing the exception to be taken at EL1 instead (similar to line 6).

[0234] To achieve FIG. 9A to FIG. 9I A sample pseudocode of the functionality is shown below:

[0235]

[0236]

[0237]

[0238] Fig.11 A summary table is shown indicating which exception level is the target exception level for a (non-maskable) synchronous external abort exception occurring in any of the exception levels EL0, EL1, EL2, EL3 for each combination of values ​​of the control information. Column TEA EL2 refers to the value of HCR_EL2.TEA, and the other columns have values ​​corresponding to Fig. 10A and Fig. 10B Same meaning. Note lines 2 and 3, which show that when TMEA EL2 is 1, a trap is taken from EL1 (but not from EL0) to EL2 when PSTATE.A is 1, but when PSTATE.A is 0, an exception is taken from both EL1 and EL0 to EL1.

[0239] The concepts described herein may be embodied in computer readable code for making devices embodying the described concepts. For example, the computer readable code may be used at one or more stages of the semiconductor design and fabrication process, including the electronic design automation (EDA) stage, to fabricate integrated circuits including devices embodying the concepts. The computer readable code may additionally or alternatively enable the definition, modeling, simulation, verification, and / or testing of devices embodying the concepts described herein.

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

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

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

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

[0244] Fig.12The simulator that can be used is illustrated. Although the previously described embodiments implement the present invention in terms of the apparatus and method for operating the specific processing hardware supporting the technology involved, an instruction execution environment according to the embodiments described herein can also be provided, which is implemented by using a computer program. Such computer programs are generally referred to as simulators, to a certain extent because such computer programs provide a software-based specific implementation of the hardware architecture. The types of simulator computer programs include emulators, virtual machines, models and binary converters, which include dynamic binary converters. Typically, the simulator is specifically implemented and can be run on a host processor 330, which optionally runs a host operating system 320 and supports a simulator program 310. In some arrangements, there may be multiple simulation layers between the hardware and the provided instruction execution environment and / or a plurality of different instruction execution environments provided on the same host processor. Historically, a powerful processor is required to provide a simulator that is executed at a reasonable speed, but this approach may be reasonable in certain circumstances, such as when it is desired to run another processor local code for compatibility or reuse reasons. For example, the simulator is specifically implemented to provide additional functions that the host processor hardware does not support to the instruction execution environment, or to provide an instruction execution environment that is generally associated with different hardware architectures. An overview of simulation is given in: "Some Efficient Architecture Simulation Techniques", Robert Bedichek, Winter 1990 USENIX Conference, pp. 53-63.

[0245] To the extent that embodiments have been previously described with reference to specific hardware constructs or features, in simulated embodiments, equivalent functionality may be provided by suitable software constructs or features. For example, specific circuits may be implemented as computer program logic in simulated embodiments. Similarly, memory hardware such as registers or cache memory may be implemented as software data structures in simulated embodiments. In arrangements where one or more of the hardware elements referenced in previously described embodiments are present on host hardware (e.g., host processor 330), some simulated embodiments may utilize host hardware, where appropriate.

[0246] The simulator program 310 may be stored on a computer-readable storage medium (which may be a non-transitory medium) and provides a program interface (instruction execution environment) to the target code 300 (which may include an application, an operating system, and a hypervisor) that is the same as the application program interface of the hardware architecture modeled by the simulator program 310. Therefore, the simulator program 310 may be used to execute program instructions of the target code 300 from within the instruction execution environment so that a host computer 330 that does not actually have the hardware features of the device 2 discussed above can emulate these features. Therefore, the simulator program 310 simulates the presence of the target processing circuit.

[0247] The simulator code 310 includes instruction decode program logic 312, processing program logic 314, and exception control program logic 318, which correspond in functionality to the instruction decoder 10, processing circuitry 4, and exception control circuitry 40 described above. In addition, a register emulation data structure 316 may be maintained by the simulator code 310 to emulate registers 14 provided in the instruction set architecture of the target processor emulated by the simulator code 310. For example, the register emulation data structure 316 may be stored in a memory of a host data processing device, and may include storage locations for storing data corresponding to the registers 14, including registers for storing control information, such as registers for storing registers 14. Figure 3 As shown. Exception control program logic 318 may respond to simulated exceptions targeting the target processor represented by simulator code 310 in a manner corresponding to the response of the exception control circuit 40 described above to the exception, including controlling whether the exception is masked and controlling the trap based on the exception control information of the trap mask and other control information as described above (in simulation, the exception routing control information may be maintained as part of the register simulation data structure 316). Therefore, simulator code 310 may provide advantages similar to those achieved in the physical hardware implementation of processing device 2 described in the earlier example.

[0248] In this application, the words "configured to..." are used to mean that elements of a device have a configuration that enables the performance of a defined operation. In this context, "configuration" means the arrangement or manner of interconnection of hardware or software. For example, the device may have dedicated hardware that provides the defined operation, or a processor or other processing device may be programmed to perform the function. "Configured to" does not mean that the device elements need to be changed in any way in order to provide the defined operation.

[0249] In the present application, a feature list beginning with the phrase "at least one of..." means that any one or more of those features may be provided individually or in combination. For example, "at least one of [A], [B], and [C]" covers any of the following options: only A (without B or C), only B (without A or C), only C (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.

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

Claims

1. A device, comprising: processing circuitry for performing data processing in one of a plurality of exception levels supported by the processing circuitry; and an exception control circuit, the exception control circuit being used to control taking of an exception by the processing circuit depending on control information stored in at least one register, the control information comprising at least: masking control information, the masking control information being capable of being set to one of a masked state and an unmasked state; and Trap-masked exception control information, the trap-masked exception control information being settable by software to one of an untrapped state and a trapped state; in: In response to a given exception among the maskable categories of exceptions that can be masked in the masking state based on the masking control information, the exception control circuit is configured to: determining whether the masking control information is in the masking state; in at least one scenario where the given exception occurs while the masking control information is in the masking state and the privilege of the current exception level is lower than a predetermined trap target exception level associated with the trap-masked exception control information, controlling whether to trap the given exception to the predetermined trap target exception level depending on whether the trap-masked exception control information is in the trapping state; as well as In the event that the mask control information is in the unmasked state and the given exception is determined to be unmasked, a target exception level for handling the given exception is selected, the target exception level being selected independently of the trap-masked exception control information.

2. The device according to claim 1, wherein: The control information includes a plurality of items of trap masked exception control information, each item being associated with a respective one of a plurality of predetermined trap target exception levels, and The exception control circuit is configured to control whether to trap the given exception to the given predetermined trap target exception level among the multiple predetermined trap target exception levels, depending on whether the corresponding item of the trap-masked exception control information associated with the given predetermined trap target exception level among the multiple predetermined trap target exception levels is in the trapping state, in at least one scenario where the given exception occurs when the masking control information is in the masking state and the privilege of the current exception level is lower than that of a given predetermined trap target exception level among the multiple predetermined trap target exception levels.

3. The device according to claim 2, wherein: In at least one scenario where the given exception occurs when the masking control information is in the masked state, at least two items of the trap-masked exception control information are in the trapped state, and each of the at least two items of the trap-masked exception control information satisfies one or more conditions for catching the predetermined trap target exception level: The exception control circuit is configured to trap the given exception to the predetermined trap target exception level associated with the selected item of trap-masked exception control information; and The selected item of trap-masked exception control information comprises one of the at least two items of trap-masked exception control information having a smallest difference in privilege between the current exception level and an associated predetermined trap target exception level.

4. A device according to any preceding claim, wherein: In case the trap-masked exception control information is in the untrapped state, the exception control circuit is configured to determine whether the given exception is masked depending at least on whether the mask control information is in the masked state.

5. The device according to claim 4, wherein: The exception control circuit is further configured to determine whether the 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-masked exception control information was in the untrapped state.

6. The device according to any one of claims 4 and 5, wherein: The control information includes unmaskable exception control information, the unmaskable exception control information being settable to one of an unmaskable state and a maskable state to indicate whether the maskable category of exceptions can be masked; and In at least one scenario in which the unmaskable abnormality control information is in the unmaskable state, the abnormality control circuit is configured to determine that the given abnormality is not to be masked even when the masking control information is set to the masking state.

7. The device according to claim 6, wherein: In a scenario where the given exception occurs when the current exception level is a lowest privileged exception level, the unmaskable exception control information is in the unmaskable state, and the given exception is to be taken to a next lowest privileged exception level that is enabled for taking the given exception if the given exception is unmasked and the trap-masked exception control information is in the untrapped state, the exception control circuit is configured to: Even when the trap-masked exception control information is in the trapped state, the given exception is controlled to be taken in the next least privileged exception level without catching the predetermined trap target exception level.

8. The apparatus of claim 7, wherein the control information comprises a plurality of items of unmaskable exception control information associated with different exception levels; and The exception control circuit is configured to determine whether the given exception is masked depending on one of the plurality of items of unmaskable exception control information selected based on the current exception level.

9. An apparatus as claimed in any preceding claim, wherein the control information comprises at least one other item of trap control information which is settable by software to one of a trapped state and an untrapped state; the exception control circuitry being configured to control whether to trap at least the maskable class of exceptions to a particular exception level depending on whether the other items of trap control information are in the trapped state; and The at least one other item of trap control information takes precedence over the trap-masked exception control information such that, if the other item of trap control information is in the trapped state, the exception control circuit is configured to trap the exception to the specific exception level based on the other item of trap control information, regardless of whether the trap-masked exception control information is in the trapped state.

10. An apparatus as claimed in any preceding claim, wherein the maskable class of exceptions comprises asynchronous error exceptions indicating deviations from correct service.

11. An apparatus according to any preceding claim, wherein: In response to an unmaskable exception in an unmaskable category of exceptions that cannot be masked based on setting the masking control information to the masking state, the exception control circuit is configured to: In at least one scenario in which the given exception occurs when the masking control information is in the masking state, a current exception level is less privileged than the predetermined trap target exception level associated with the trap-masked exception control information, and the current exception level is an exception level that can be a target exception level for handling the exception, whether the unmaskable exception is trapped to the predetermined trap target exception level is controlled depending on whether the trap-masked exception control information is in the trapping state.

12. The apparatus of claim 11, wherein the unmaskable class of exceptions comprises a synchronous external abort exception indicating a deviation from correct service.

13. The apparatus according to any preceding claim, comprising a plurality of groups of one or more exception comprehensive characterization registers, each group of one or more exception comprehensive characterization registers storing exception comprehensive characterization information of exceptions taken in a corresponding exception level in the exception levels.

14. An apparatus according to any preceding claim, wherein in response to an instruction requesting an update to the trap-masked exception control information executed at an exception level less privileged than the predetermined trap target exception level associated with the trap-masked exception control information, the processing circuit is configured to reject or trap the requested update to the trap-masked exception control information.

15. Computer readable code for producing an apparatus according to any preceding claim.

16. A storage medium storing the computer-readable code according to claim 15.

17. A method comprising: performing data processing in one of a plurality of exception levels supported by the processing circuitry; as well as Controlling taking of exceptions by the processing circuitry in dependence upon control information stored in at least one register, the control information comprising at least: masking control information, the masking control information being capable of being set to one of a masked state and an unmasked state; and Trap-masked exception control information, the trap-masked exception control information being settable by software to one of an untrapped state and a trapped state; in: In response to a given exception in a maskable category that can be masked based on setting the masking control information to the masking state, the method includes: determining whether the masking control information is in the masking state; in at least one scenario where the given exception occurs when the masking control information is in the masking state and a current exception level is less privileged than a predetermined trap target exception level associated with the trap-masked exception control information, controlling whether the given exception is trapped to the predetermined trap target exception level depending on whether the trap-masked exception control information is in the trapping state; and In the event that the mask control information is in the unmasked state and the given exception is determined to be unmasked, a target exception level for handling the given exception is selected, the target exception level being selected independently of the trap-masked exception control information.

18. A computer program, the computer program comprising instructions, which when executed by a host data processing device, control the host data processing device to provide an instruction execution environment for executing a target code, the computer program comprising: handler logic for emulating instructions for executing the target code in one of a plurality of exception levels; and exception control program logic for emulating taking an exception in dependence upon control information stored in at least one storage location of at least one register of the host data processing apparatus representing a target instruction set architecture used by the target code, the control information comprising at least: masking control information, the masking control information being capable of being set to one of a masked state and an unmasked state; and Trap-masked exception control information, the trap-masked exception control information being settable by software to one of an untrapped state and a trapped state; in: In response to a given exception in a maskable category of exceptions that can be masked based on setting the masking control information to the masking state, the exception control program logic is configured to: determining whether the masking control information is in the masking state; in at least one scenario where the given exception occurs while the masking control information is in the masking state and the privilege of the current exception level is lower than a predetermined trap target exception level associated with the trap-masked exception control information, controlling whether to trap the given exception to the predetermined trap target exception level depending on whether the trap-masked exception control information is in the trapping state; as well as In the event that the mask control information is in the unmasked state and the given exception is determined to be unmasked, a target exception level for handling the given exception is selected, the target exception level being selected independently of the trap-masked exception control information.

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

Images