TW202540862A - Selection of tag translation mode - Google Patents

Abstract

Address translation circuitry determines whether a first or second tag translation mode is to be used for a given stage of address translation to be performed in response to a tag-accessing instruction specifying a given data address and requesting that an operation is performed using a given allocation tag associated with a given data item corresponding to the given data address. The given allocation tag comprises a tag for use in a tag check in response to a tag-checked memory access instruction specifying an address operand for defining a target address of a memory access operation. If the selected mode is the first mode, a data-locating second address is obtained identifying a location of both the given data item and the given allocation tag within the second address space. If the second mode is selected, a tag-locating second address is obtained identifying a location of the given allocation tag within the second address space separate from a location of the given data item identified by the data-locating second address.

Description

Tag translation mode selection

This technology relates to the field of data processing.

Some data processing architectures can support tag-checking operations based on allocation tags for given data items stored in memory and address tags associated with address pointers used to calculate the address of those given data items. Such tag-checking can help detect memory security errors (e.g., errors where address pointers are used to access memory regions that the address pointers never intended to point to due to programming errors and/or unexpected results in the code (such as buffer overflows), posing a risk of data corruption and increasing vulnerability to malicious attacks).

At least some embodiments of the present technology provide an apparatus comprising: a tag checking circuit system for performing a tag checking in response to a tag-checked memory access instruction, the tag-checked memory access instruction specifying an address operation for defining a target data address corresponding to a data item associated with an allocation tag stored in a memory system, the tag checking including responding to the detection of the target data address obtained from the memory system. An error handling response is triggered when the allocation tag and an address tag associated with the address operand are mismatched; and an address translation circuit system is used to perform address translation based on address mapping information associated with at least one address translation stage, the at least one address translation stage including a given address translation stage from a first address space to a second address space; wherein: when the response specifies a given data address and requests use of the data corresponding to the given data... When executing a tag access instruction to perform an operation on a given data item at a given address and performing the given address translation stage, the address translation circuit system is configured to: determine whether a first tag translation mode or a second tag translation mode is a selected tag translation mode to be used in response to the given address translation stage of the tag access instruction; and, in response to determining that the selected tag translation mode is the first tag translation mode, obtain a data location... A second address is provided, wherein the data location second address identifies a position of the given data item and the given assignment label within the second address space; and a tag location second address is obtained in response to determining that the selected tag translation mode is the second tag translation mode, wherein the tag location second address identifies a position of the given assignment label within the second address space, which is separate from a position of the given data item in the second address space identified by the data location second address.

At least some embodiments of this technology provide a computer-readable code for manufacturing the aforementioned device. The computer-readable code can be stored on a storage medium. This storage medium can be a non-temporary storage medium.

At least some embodiments of this technology provide a method comprising: determining whether a first label translation mode or a second label translation mode is a selected label translation mode to be used in response to a label access instruction to be executed in a given address translation stage, the label access instruction specifying a given data address and requesting to perform an operation using a given allocation label associated with a given data item corresponding to the given data address, the given allocation label including a label for responding to a label check to be executed in response to a label check memory access instruction, the label check memory access instruction specifying an address arithmetic bit for defining a target address of a memory access operation, the label check including responding to the detection of an access from the memory An error handling response is triggered when the system obtains a label mismatch between the allocation label for the target address and an address label associated with the address operand; the response is triggered when a data location second address is obtained by selecting the first label translation mode, the data location second address identifying a position of both the given data item and the given allocation label in the second address space; and when a label location second address is obtained by selecting the second label translation mode, the label location second address identifying a position of the given allocation label in the second address space, the position being separate from a position of the given data item in the second address space identified by the data location second address.

At least some examples provide a computer program for controlling a host data processing device to provide an instruction execution environment for executing object program code. The computer program includes: a tag checking logic for responding to a tag-checked memory access instruction to perform a tag check, the tag-checked memory access instruction specifying an address operation for defining a bit corresponding to a target data address associated with an allocation tag stored in a simulated memory system. The query includes a response to triggering an error handling response upon detecting a label mismatch between the allocation label for the target data address obtained from the analog memory system and an address label associated with the address operand; and address translation logic for performing address translation based on address mapping information associated with at least one address translation stage, the at least one address translation stage including a given address translation stage from a first address space to a second address space; wherein: when the response is in the specified When a given data address is given and a tag access instruction requests the use of a given allocation label associated with a given data item corresponding to that given data address to perform an operation, and the given address translation stage is executed, the address translation logic is configured to: determine whether a first tag translation mode or a second tag translation mode is a selected tag translation mode to be used in response to the given address translation stage in response to the tag access instruction; and respond to the determination that the selected tag translation mode is the first tag translation mode. A second data location address is obtained by means of the method, the second data location address identifying a position of the given data item and the given allocation label in the second address space; and a second label location address is obtained by determining that the selected label translation mode is the second label translation mode, the second label location address identifying a position of the given allocation label in the second address space, the position being separate from a position of the given data item in the second address space identified by the second data location address.

The computer program can be stored on a storage medium. The storage medium can be a non-temporary storage medium.

The device has a tag checking circuitry system for performing a tag check in response to a tag-checked memory access instruction, which specifies an address operator for defining a target data address corresponding to a data item associated with an allocation tag stored in a memory system. The tag check includes a response to triggering an error handling response upon detecting a tag mismatch between the allocation tag obtained from the memory system for the target data address and the address tag associated with the address operator. Error handling responses may include, for example, denying memory access (e.g., responding to a memory access instruction that failed tag checking and signaling an error), and/or logging information about the detected tag mismatch error (e.g., updating the error log to identify the target data address where a tag mismatch was detected). When a tag mismatch is detected, it is not necessary to prevent memory access from continuing (e.g., in some cases, the purpose of tag checking may only be to generate a report to flag a possible memory usage error to software developers, and not necessarily to require blocking access to underlying data in memory). Nevertheless, by providing architectural support for assigning allocation tags to data items stored in the memory system and assigning address tags to address operators used to calculate the address of such data items, and by comparing allocation tags and address tags when executing tag-checked memory access instructions, this can help software developers develop more robust code that is less likely to lead to errors or be compromised by attackers.

The address translation circuit system performs address translation based on address mapping information associated with at least one address translation stage, which includes a given address translation stage from a first address space to a second address space. In some embodiments, the address translation circuit system supports different label translation modes for the given address translation stage for use when processing label access instructions that specify a given data address and request to perform an operation using a given allocation label associated with a given data item corresponding to the given data address. Tag access instructions can be tag-checked memory access instructions. For such tag-checked memory access instructions, the operation performed using a given allocation tag is a tag check performed by the tag checking circuit system. This check compares the given allocation tag with the address tag associated with the address operand used to calculate the given data address. The tag-checked memory access instruction also requests a read or write access to the given data item. Alternatively, tag access instructions can be tag read/write instructions, used to read or write the value of the allocation tag associated with a data item block corresponding to a given data address (this tag read/write instruction may not require access to the given data item itself). Therefore, a tag access instruction can be any instruction that requires the use of an allocation tag associated with a given data item at a given data address to perform an operation. The given data item itself does not need to respond to a tag access instruction for access.

When the given address translation stage is executed in response to the tag access instruction, the address translation circuit system can determine whether a first tag translation mode or a second tag translation mode is a selected tag translation mode to be used in the given address translation stage in response to the tag access instruction. The address translation circuit system, in response to determining that the selected tag translation mode is the first tag translation mode, obtains a data location second address, which identifies a position of both the given data item and the given allocation tag within the second address space. The address translation circuit system responds by determining that the selected label translation mode is the second label translation mode and obtaining a label positioning second address. This label positioning second address identifies a location within the second address space where the given allocation label is located, separate from a location within the second address space identified by the data positioning second address. In the case where the label positioning second address is obtained according to the second label translation mode, if the label access instruction does not require access to the given data item, the data positioning second address itself does not need to be obtained in response to the label access instruction.

Using this method, the address translation circuit system supports greater flexibility in determining how to associate allocation tags with their corresponding data items. If the first tag translation mode is selected, both the given data item and its associated allocation tag are mapped to the same address in the second address space (based on the address mapping information shared by access to the data item and access to its associated allocation tag). If the first tag translation mode is used for all address translation stages, the same physical address can be used to identify the location of both the given data item and the given allocation tag in the physical address space, and it can be left to the memory system to implement techniques for locating the allocation tag associated with the given data item identified by the physical address space. For example, a memory system can provide physical storage for storing allocation tags alongside each data location—for example, using spare bits originally used for error correction codes or other information, or alternatively, the memory system can partition off portions of its physical storage to hold allocation tags associated with data items in another portion of its physical storage. The specific mechanisms used to manage the association between data items and tags in the memory system may be implementation-specific and separate from the address translation mechanisms provided by the address translation circuit system. While this approach simplifies software development (because it eliminates the need for software to control the address translation table structure to provide separate address mapping information for translating data items and associated allocation tags), it places a greater burden on memory system hardware designers by providing a way to store designated allocation tags and associate the location of those allocation tags with corresponding items.

On the other hand, if the second translation mode is selected for a given address translation mode, the given allocation tag can be mapped to an address in the second address space, which is separate from the address that identifies the location of the corresponding data item. This allows data items and their associated allocation tags to be mapped to different physical addresses, so that from the perspective of the memory system, it does not need to manage any specific tag access mechanism (e.g., specifying a permanent physical storage for storing allocation tags), because when both tags and data need to be accessed, the memory system can simply send two memory access requests—one for the tag-location physical address (depending on the tag-location second address) and the other for the data-location physical address (depending on the data-location second address). Virtualizing the location of tags by supporting tag location address translation for identifying the second address of the tag (separate from data location address translation for identifying the second address of the data) can also help increase the efficiency of available physical memory storage. This is because not every allocation tag mapped to a tag address in a given data address space necessarily needs to be allocated physical memory in the physical address space, and the virtualization method implements the following option: mapping the tag location addresses of allocation tags associated with different data items to be assigned the same allocation tag value to the same translated tag location address to reduce the number of physical storage locations in memory required to provide tag storage for a given number of data items.

Therefore, by providing an address translation circuit system that supports selection between a first label translation mode and a second label translation mode, this allows for the identification of whether the task of identifying the location of an assigned label associated with a specific data item lies in the software (when setting the relevant address translation mapping controls) or in the hardware of the memory system (if the software chooses to map the label/data to the same physical address). This allows for a balance between the reduced complexity of maintaining label address translation mapping (in the first label translation mode) and the more efficient use of available physical memory storage (in the second label translation mode). Consequently, processor architectures supporting both the first and second label translation modes can better balance the demands of a wide variety of workloads.

Each time a tag access instruction is executed, the assigned address translation stage does not need to be executed based on the first or second tag translation mode. The address translation circuit system may have at least one translation lookaside buffer (TLB) that caches information derived from a previous instance of executing the assigned address translation stage for a given target address. If information identifying a tag that positions a second address (or a physical address derived from a tag that positions a second address, if the tag that positions a second address itself will require further translation to a physical address) is already available in the translation lookaside buffer, the assigned address translation stage does not need to be executed again. Furthermore, as described below, in some instances, at least when a second label translation mode is to be used for a given address translation phase and the label access instruction is also a label-checked memory access instruction that needs to access a given data item, whether label translation is performed on the architecture to obtain the second address of the label location may depend on the attributes obtained in the data translation operation used to obtain the second address of the data location corresponding to the given data address.

In some implementations, address translation circuitry can support a two-stage translation system, where address translation is performed based on a first address translation stage from the virtual address space to the intermediate address space and a second address translation stage from the intermediate address space to the physical address space. This can facilitate virtualization where multiple client operating systems (each responsible for setting the address mappings for the first address translation stage) may coexist on the same hardware platform, and thus the hypervisor can control the address mappings for the second address translation stage to ensure that conflicting intermediate addresses in the intermediate address space obtained based on mappings set by different client operating systems can be mapped to different physical addresses in the physical address space.

In the case of supporting a two-stage translation system, support for both the first and second label translation modes can be provided for the first stage (but not the second stage), or support for both the first and second label translation modes can be provided for the second stage (but not the first stage), or support for both the first and second address translation modes can be provided for both the first and second address translation stages.

Therefore, in some embodiments, the address translation circuit system can support the use of the second label translation mode when the given address translation stage is the first address translation stage. In this case, the first address space is the virtual address space, and the second address space is the intermediate address space. The data location second address and the label location second address can undergo further translation in the second address translation stage in this case to obtain the corresponding data location physical address and label location physical address in the physical address space. Therefore, the mode control that selects between the first and second label translation modes affects whether a given data item and a given allocation label are mapped to separate addresses in the intermediate address space. The separate intermediate addresses may depend on the separate address mapping information defined in the separate first-stage address translation table entries as data items and their associated allocation tags.

In some instances, the address translation circuit system may support the use of the second label translation mode when the given address translation stage is the second address translation stage, wherein the first address space is the intermediate address space and the second address space is the physical address space. In this case, the data-located second address is the data-located physical address and the label-located second address is the label-located physical address. Therefore, the mode control used to select between the first and second label translation modes affects whether a given data item and a given allocation label are mapped to separate addresses in the physical address space, which is determined in the address translation based on the separate address mapping information defined for data and allocation labels respectively in the separate second-stage address translation entries. The separate second-stage address translation entries can be selected based on information from the first data location address, which identifies the position of the given data item in the first (intermediate) address space, wherein the first data location address is obtained by translating the given (virtual) data address based on the first address translation stage.

The address translation circuit system can select the selected label translation mode based on label translation control information, which can be configured to control which label translation mode is used for the selected label translation mode in the given address translation stage. Therefore, although the hardware of the address translation circuit system supports two modes, the configuration settings can select which mode is used for a given instance of performing address translation for a given stage for a given label access instruction.

In some instances, tag translation control information can be a static configuration input fixed to a given processing system that implements the address translation circuitry. For example, the same design of a processor containing the address translation circuitry can be used with a variety of different memory storage hardware, and some memory storage units may not support tag-specific access mechanisms (making it potentially beneficial to restrict the address translation circuitry to use a second tag translation mode for at least one address translation stage when the address translation circuitry is used in conjunction with that type of memory storage unit).

However, in some instances, label translation control information may include software-configurable configuration inputs that can be set by software running on the data processing system. For example, label translation control information may contain information specified in at least some software-accessible control registers (e.g., software executing at a given privilege level—software with lower privileges may not be able to set the information indicated in the control registers). This implementation provides greater dynamic control over whether a particular software workload will utilize its label access controlled according to a first or second label translation mode.

The label translation control information may include a first-stage label translation mode indicator, which indicates whether either the first label translation mode or the second label translation mode should be used as the selected label translation mode for a first-address translation stage, at least for a first-class label access instruction. For the first-address translation stage, the first address space is a virtual address space, and the second address space is an intermediate address space. Therefore, when the given address translation stage is a first-address translation stage, the first-stage label translation mode indicator can be used to control which label translation mode is used.

Support for the first and second label translation modes can exist in different ways, wherein a given input address can be translated in a given address translation stage: in the first label translation mode, the address translation circuit system processes an input address based on a data address translation operation to obtain the data address second address, and in the second label translation mode, the address translation circuit system processes an input address based on a label address translation operation to obtain the label address second address. The data address translation operation and the label address translation operation can process the input address in different ways (e.g., based on different translation table base addresses, or by applying different mappings between the input address and the address used to look up the translation table structure).

Therefore, when the first-stage label translation mode indicator indicates that the second label translation mode should be the selected label translation mode of the first-stage address translation from the virtual address space to the intermediate address space, one approach is to use label address translation operations for all accesses to the stored allocation labels to identify the address in the second (intermediate) address space where the required allocation label is stored.

However, it may also be useful to provide a type of instruction that applies data address translation operations to identify the addresses of one or more allocation tags of interest, even when the tag access instruction applies the tag address translation operation in a second tag translation mode. Therefore, in some instances, when the first address translation phase is executed in response to a subject tag read/write instruction to request the read or write of one or more assigned tags identified using a subject tag target address specified by the subject tag read/write instruction, the address translation circuit system may apply the data address translation operation to an input address based on the subject tag target address to obtain a tag read/write target second address in the second address space, even when the first-stage tag translation mode indicator indicates that the second tag translation mode should be used as the selected tag translation mode for the first address translation phase in response to the tag access instruction. Therefore, subject tag read/write instructions directly specify the address that identifies the location of one or more allocation tags, rather than indirectly specifying them by specifying the address of the corresponding data item. For address translation purposes, their behavior is similar to non-tag-checked data access instructions that do not require access to any allocation tags at all. For example, such subject tag read/write instructions that access allocation tags as if they were their equivalent data items can be used by the super manager to allow the super manager to control the values of allocation tags used by the client operating system.

The execution of a subject label read/write command can be disabled at at least one privilege level that would otherwise allow the execution of such a command. This reduces the likelihood of the assigned label being tampered with by a lower privilege code and reflects the common use case of subject label read/write commands, which may be achieved by a supermanager with sufficient privileges to allow the execution of such commands.

For some instances that support the use of the second label translation mode in the second address translation stage (where the first address space is the intermediate address space and the second address space is the physical address space), the label translation control information may also include a second-stage label translation mode indicator, which indicates that when the first-stage label translation mode indicator indicates that the selected label translation mode is used for the first address translation stage, either the first label translation mode or the second label translation mode should be used as the selected label translation mode for the second address translation stage. This allows the hypervisor to select which virtualized memory tags (where different address translation maps are applied to the data and an associated allocation tag) will be applied to the second-stage translation of a given client operating system, even if that client operating system is not yet designed to support virtualized tags at the first address translation stage. By avoiding the memory system having to allocate permanent physical memory regions to store the tags, this further helps to support more efficient use of physical memory storage.

When the first-stage label translation mode indicator has a value indicating that the first label translation mode will be used in the first address translation stage, the second-stage label translation mode indicator affects which label translation mode is used in the second address translation stage. However, when the first-stage label translation mode indicator indicates that the second label translation mode will be used in the first address translation stage, it may be undesirable to also apply the second label translation mode to the second address translation stage, as this may involve unpredictable results where the data/labels from the first address translation stage that locate the second address are treated separately as separate data/label addresses mapped to the second address translation stage. Therefore, to reduce the software burden of managing such unpredictable address translation mappings, the following can be useful: In response to the determination that the first-stage label translation mode indicator indicates that the selected label translation mode is used for the second label translation mode of the first address translation stage, the address translation circuit system determines that the first label translation mode should be used as the selected label translation mode for the second address translation stage (regardless of the value set for the second-stage label translation mode indicator).

When the selected label translation mode is the second label translation mode, there are several different ways to generate a label location second address.

In some instances, when the given address translation phase is executed in response to a tag access instruction, and when the selected tag translation mode is the second tag translation mode used for the given address translation phase, the address translation circuit system can obtain the given allocation tag by identifying the first address of a data location in the first address space based on recognizing a location of the given data item. A label is assigned a first address at a location in the first address space, and then a second label is obtained by translating the first label address according to address mapping information selected from a given stage translation table structure based on the first label address, the given stage translation table structure being based on a given translation table base address identification. Therefore, the aforementioned label address translation operation may include transforming the first data address to generate different first label addresses representing the location of a given assigned label in the first address space, and then using the obtained first label address to select an entry in a given stage translation table structure that provides an address mapping to the second label address. This method simplifies the software management burden of maintaining the translation table structure because the single translation table structure maintained by the software can be used for both data address translation operations and label address translation operations.

Using this method, when the given address translation stage is executed in response to the tag access instruction, and when the selected tag translation mode is the first tag translation mode for the given address translation stage, the address translation circuit system can obtain the second address of the data location by translating the first address of the data location according to the address mapping information, wherein the address mapping information is selected from the given stage translation table structure based on the first address of the data location, and the given stage translation table structure is based on the base address identification of the given translation table. Therefore, the same translation table base address can be used regardless of whether the label address translation operation is performed in the second label translation mode or the data address translation operation is performed in the first label translation mode (or in the case of performing a data address translation operation for the subject label read/write command mentioned above).

In the second tag translation mode, the address translation circuit system can obtain the first address of the tag location based on: a tag table base address indicating a location within the first address space that specifies a tag table region for storing allocated tags; and a tag table offset derived from the first address of the data location. Although other more complex transformations of the first address of the data location can be applied to generate the first address of the tag location, using a portion of the first address of the data location as an offset relative to the tag table base address can be more simply implemented in hardware.

In other examples, instead of transforming the first address of the data location to obtain the first address of the label location (so that the data and label addresses are translated into different first address inputs for the address translation stage to the table lookup), another approach is to use the same first address of the data location as the input address for the translation table lookup in the address translation stage, but use that first address of the data location to use different translation table structures defined by different base addresses, so that the separate translation table entries used for data and label access can be identified from the respective translation table structures to map the same first address of the data location in the first address space to the second address of the data location and separate the second address of the label location in the second address space.

Therefore, when the given address translation stage is executed in response to the tag access instruction, the address translation circuit system can be configured such that the address translation circuit system responds to determining that the selected tag translation mode is the first tag translation mode and, based on address mapping information, identifies a data location first address of the given data item at a location in the first address space to obtain the data location second address. The address mapping information is selected from a data translation table structure based on the data location first address, and the data translation table structure is identified based on a data translation table base address. The address translation circuit system responds by determining that the selected label translation mode is the second label translation mode and obtaining the second address of the label location by translating the first address of the data location based on address mapping information. The address mapping information is selected from a label translation table structure based on the first address of the data location. The label translation table structure is identified based on a label translation table base address that is separate from the base address of the data translation table.

While the examples above describe an implementation where an address translation circuit system selects to apply either the first or second label translation mode to obtain an address in the second address space and thus identify the location of an allocation tag associated with a given data item, other examples may support the second label translation mode (virtualized label translation mode) to obtain the address of the allocation tag, but may not support the first label translation mode. In this case, entity tags (where the data item and its associated allocation tag are identified in memory based on the same entity address) may not be supported.

Regardless of whether physical tagging methods are supported (e.g., using the first tag translation mode), in implementations that support virtualized tag translation modes (e.g., the second tag translation mode described above), processing of tag-checked memory access instructions may involve performing a tag location address translation operation to obtain the tag location address, while this operation may not be necessary for non-tag-checked memory access instructions. This may introduce performance costs because performing tag-location address translation operations carries a higher risk of address translation errors. If the entry providing the address translation mapping for the required tag address has not been configured by the software or indicates that access permissions have not been granted, such address translation errors that are detrimental to processing performance will occur. (In the case of virtualized tag translation mode, tag translation may use address translation entries that are different from those used to obtain the corresponding data location address, and therefore even if the entry used to obtain the data location address has been correctly configured, there is no guarantee that tag translation will not produce translation errors.) Therefore, while introducing this tag location address translation operation in the virtualized tag translation mode can have the benefit of reducing reliance on the location of tags associated with memory system management and corresponding data items (e.g., avoiding the need to partition a portion of physical memory for the tag), the virtualized tag translation mode may risk performance degradation compared to an implementation that does not perform a tag location address translation operation separate from the corresponding data location address translation operation.

In the examples discussed below, a memory management circuit system may control access to a target data address for a tagged memory access instruction based on memory attribute information associated with that target data address. This memory attribute information may indicate whether the target data address is located in an untagged memory region that would not require tagging. The memory management circuit system may determine whether to perform a tag location address translation operation on the architecture to obtain a tag location entity address that locates the associated allocation tag in a physical address space, based at least on whether the memory attribute information associated with the target data address of the tag-checked memory access instruction indicates that the target data address is located in the untagged memory region. (The tag location entity address is separate from the data location entity address that locates the target data item in the physical address space.)

Using this method, software can (by setting memory attribute information assigned to a set of addresses) communicate whether tag checks are required for accessing those addresses. Furthermore, for address regions that do not require tag checks, tag-based address translation operations can be suppressed on the architecture, reducing the frequency of processing interruptions caused by address translation errors. This can help improve processing performance.

The memory management circuit system can respond by suppressing the tag location address translation operation on the architecture when the target data address is detected to be located in the unlabeled memory area.

When determining whether to suppress tag location address translation operations on the architecture, some cases may also consider other factors.

For example, in some implementations, the memory management circuitry may include the address translation circuitry mentioned above, and therefore may also support the first and second address translation modes as described earlier. In this case, the architectural performance for determining whether to enable or disable tag-based address translation operations may be related to the second address translation mode rather than the first address translation mode.

Therefore, in some instances, the memory management circuit system may respond to detecting at least one tag translation mode indicator indicating that a virtualized tag translation mode is disabled, thereby suppressing the execution of the tag location address translation operation on the architecture. The virtualized tag translation mode includes a mode in which the target data item is mapped to the data location entity address based on data translation address mapping information corresponding to the target data address, and the associated allocation tag is mapped to the tag location entity address based on tag translation address mapping information corresponding to the target data address, wherein the tag translation address mapping information is separate from the data translation address mapping information. For example, the virtualized label translation pattern can be the second address translation pattern mentioned above (and can be applied in either the first or second address translation stage). Depending on the implementation, label translation address mapping information can be separated from data translation address mapping information for several reasons (e.g., because the label translation address mapping information and the data translation address mapping information are selected from translation table structures that use different translation table base address accesses, or because the label translation address mapping information and the data translation address mapping information are selected from the same translation table structure based on different input addresses corresponding to the associated labels and data items, respectively). Therefore, even if memory attribute information does not indicate that the target data address is located in an unlabeled memory region, label location address translation operations can still be prevented on the architecture if virtualization labels are currently disabled.

When the virtualization tag translation mode is disabled, the memory management circuit system can map both the target data item and the associated allocation tag to the data location entity address. This corresponds to the first address translation mode described above.

Memory attribute information can also support indicating the target data address as encoding in a labeled memory region. In this case, whether the label location address translation is performed on the architecture may depend on whether at least one further condition is met (e.g., depending on instruction type information, and/or depending on a control indicator that controls whether virtualization label translation mode is enabled).

For example, satisfying this further condition may depend on at least one tag translation mode indicator that indicates the virtualization tag translation mode is enabled. When the virtualization tag translation mode is indicated as disabled, tag location address translation may not be performed on the architecture, even if memory attribute information indicates that the target data address is located in a tagged memory region.

When the tag-based address translation operation is suppressed at the architectural level, the memory management circuitry prevents any errors from being transmitted based on the tag-based address translation operation. Errors are costly in terms of performance because they can cause ongoing workloads to be interrupted to allow the execution of abnormal processors. Therefore, by preventing address translation errors in tag-based address translation operations when accessing untagged memory regions, the possibility of performance loss is reduced.

In some cases, when the tag-location address translation operation is suppressed at the architectural level, the memory management circuitry can prevent the actual execution of the tag-location address translation operation. Therefore, the tag-location address translation operation may not occur at all. This not only reduces the risk of spoofed address translation errors but also eliminates the bandwidth cost of performing the translation, freeing up address translation bandwidth for other translation operations.

However, in some implementations, even when the tag address translation operation is suppressed at the architectural level, the memory management circuitry can still allow the tag address translation operation to actually be performed, but prevent changes in the architectural state caused by the tag address translation operation from resulting in an architectural outcome identical to that without the tag address translation operation. For example, the memory management circuitry can prevent transmission errors, updates to architecturally visible performance counters, and/or trigger read/write operations in memory based on the results of tag address translation operations that have been performed but should be suppressed at the architectural level. Even with architectural suppression, performing tag-location address translation can be useful in some implementations because it allows the tag-location address translation operation to begin earlier (while waiting for memory attribute information associated with the target data address), rather than delaying the tag-location address translation until the result of checking the memory attribute information is actually known. Furthermore, in some cases, if performing a label-based address translation results in the translation lookup buffer caching the translation table pointer as a result of the label-based address translation, this may help speed up later translations that require the same pointer (for example, a given translation table pointer from a higher-level translation table in a multi-level translation table structure may be shared between some labeled memory regions and some unlabeled memory regions).

In some instances, a special memory property type corresponding to an untagged memory region can be defined (or several variants of the "untagged" memory property can be defined).

However, in other instances, the memory management circuit system may infer whether the target data address is located in the unlabeled memory region based on one or more memory attribute indicators of one or more memory region attributes that are unrelated to the execution of the tag check. The spare encoding space available for encoding attribute types in the translation table entries may be extremely limited, and therefore it may sometimes be impossible to add new dedicated attribute types to the existing address translation framework. Therefore, in some cases, it may be possible to infer whether the region is tagged/unlabeled based on other attribute types already provided.

For example, a labeled memory region can be restricted to a region that is indicated by memory property information as a normal write-back cacheable memory region. A "normal" memory region may be a non-device memory region, to which repeated or reordered access to the memory region is permitted (unlike "device" memory regions, to which repeated or reordered access to the memory region is not permitted, as this can lead to side effects). For example, device memory is typically used in buffer structures that control devices such as input/output (I/O) devices or hardware accelerators. Therefore, unlike read/write operations for memory storage used for random access to memory data, repeatedly performing the same read or write operation, or reordering the read/write sequence relative to the order in which read/write requests were issued, can cause such devices to malfunction. Memory tags may generally be used for random access to memory data rather than device control structures; therefore, addresses in device memory may be considered untagged by default. Similarly, non-cacheable memory regions (regions that store addresses that do not need to be allocated to cached memory) are unlikely to store general random access memory data that is accessed by software prone to memory usage errors, and therefore non-cacheable memory regions can also be assumed to be unlabeled. Thus, in some instances, the memory management circuitry system may respond by detecting that the target data address is located in a region other than a normally write-back cacheable memory region and determining that the target data address is located in the unlabeled memory region.

It will be understood that this is only one example, and other examples may have different ways of encoding memory regions as tagged or untagged, using memory attribute information associated with the target data address of the tagged memory access instruction.

The memory management circuit system can determine whether to perform the tag-location address translation operation on the architecture to translate the target data address into the data location entity address based on the memory attribute information derived from at least one translation table entry accessed in a data location address translation operation. For the purpose of identifying the entity address of the target data item, the data location address translation operation can be performed on a tag-checked memory access instruction, whether the tag-location address translation operation is performed on the architecture or suppressed. Therefore, by using memory attribute information obtainable from data location address translation operations (DRCOs) to enable/disable whether tag address translation operations are performed on the architecture, this provides an easy-to-implement technique to prevent unnecessary errors that can result from unnecessarily performing tag address translation operations. One might argue that enabling/disabling tag address translation operations based on attribute information from data address translation operations would be undesirable, as performing tag address translation operations after data address translation operations could result in unacceptably long latency in tag-checked memory access instructions, especially if both data and tag translations require translation table visits. However, in practice, because tag-location-to-address (TAN-TO) operations are suppressed architecturally but not actually prevented from being executed, they may be speculatively initiated before memory attribute information becomes available. This prevents the observation of any errors or other architectural consequences resulting from speculatively executed TAN-TO operations if it is later determined that the TAN-TO operation will be disabled (suppressed) architecturally. Any remaining portion of the TAN-TO operation then does not need to be completed if it is later found that the TAN-TO operation will be disabled (suppressed) architecturally.

In some instances, for a given address translation stage, the memory management circuit system can perform the tag-location address translation operation based on address mapping information from a tag-translation table entry, which is different from a data-translation table entry that provides address mapping information for the given address translation stage in a data-location address translation operation, for translating the target data address into the data-location entity address. As described above, there can be different ways that cause label/data location address translation operations to use mappings from different translation table entries (e.g., accessing these entries using different translation table base addresses corresponding to separate label/data translation table structures, or providing different label/data input addresses to a shared translation table structure shared between labels and data). The given address translation stage can be a first address translation stage translating from virtual address space to intermediate address space, or a second address translation stage translating from intermediate address space to physical address space.

In some embodiments, an apparatus includes the tag inspection circuit system mentioned above; a tag location address determination circuit system for determining a tag location address corresponding to a given data item in a location within a first address space based on a data location address identifying a location of a given data item in a first address space; and an address translation circuit system for performing at least one address translation stage from the first address space to a physical address space. The tag location address determination circuit system may determine the tag location address based on an offset relative to a tag table base address, the tag table base address indicating a location within the first address space that specifies a tag table address region for storing the assigned tag, the offset depending on an offset portion of the data location address.

Therefore, within the first address space (which will be translated into a physical address space using one or two address translation stages), the data location address that identifies the position of a given data item in the first address space is transformed to produce a corresponding tag location address that identifies the position of the associated allocation tag in the first address space. This transformation is between two addresses within the same address space (rather than a mapping from an address in the first address space to an address in the second address space).

Compared to alternatives (such as looking up the data address in a separate tag address translation table structure), this method simplifies software development for systems supporting virtualized tags, meaning that data and tag translations can share the same translation table structure. The tag address determination circuitry can modify the data address to identify the tag address, which can then be input for address translation using the same translation structure also used for data.

Furthermore, compared to alternatives such as defining a data-to-tag address mapping table to provide more arbitrary mappings from data location addresses in the first address space to corresponding tag location addresses in the first address space, generating tag location addresses based on offsets relative to the tag table base address (where the offset depends on the offset portion of the data location address) can reduce the hardware cost of implementing the tag location address determination circuit system and reduce the software development cost of setting control information to control the generation of tag location addresses.

In some embodiments, the tag location address determination circuit system is configured to determine tag selection information based on one or more bits of the data location address that are less significant than the offset portion but adjacent to the offset portion. This tag selection information indicates which of a plurality of allocation tags stored at the same address in the tag table address region corresponds to the allocation tag for the data location address. This can be used in embodiments where each allocation tag contains fewer bits than the number of bits corresponding to the stored information at a single address in memory. For example, for memory addressable where each unique address value corresponds to a separate byte (8 bits) of data in memory, the allocation tag may contain fewer than 8 bits (e.g., 4 bits). In this case, it can be useful to package multiple allocation tags into memory locations corresponding to a single address, allowing the allocation tags to be stored more compactly in the memory address space. Therefore, if the smallest size of the data read back from memory corresponds to the content of a single addressable location (e.g., a byte), then multiple tags can actually be returned from memory. To enable selection among the allocation tags returned from memory (and to identify which tag is actually associated with the data item of interest), the tag location address determination circuitry can determine tag selection information from the data location address based on one or more less significant (but adjacent) bits used to derive the offset. For example, in an instance where the allocation label is 4 bits wide and each address refers to 1 byte (8-bit) of memory, the next least significant bit after the portion used to derive the offset can be used to select between two allocation labels existing in the memory address space of the allocated byte.

Other examples can use different label sizes. If the label size is equal to the size of an addressable memory location, then it is not necessary to derive label selection information from the label location address in the circuit system, because a read of the given address in memory can return a single assigned label.

In some instances, the tag table base address includes a quasi-address. The quasi-address may be an address that naturally aligns with the alignment boundary in memory. For example, the tag table base address can be explicitly or implicitly defined as an address where several least significant bits are all 0. By using a quasi-address base address, the complexity of the tag location address determination circuitry can be reduced. For example, this means that an adder is not needed to combine the base address and the offset, because the offset bits can be simply inserted into the positions that correspond to 0s in the quasi-base address. Since adders are relatively slow compared to circuit systems that multiplex bits from different sources to the appropriate bit locations, eliminating the cost of adders in each cycle of address translation for lookup tag addresses can help improve performance and make it easier for circuit designers to design circuit systems that meet timing requirements. Furthermore, using a locating base address means that less information needs to be stored to define the base address because the lower-order 0 bits do not need to be explicitly stored. For example, those 0 bits can be omitted from the information stored in a register to define the base address. Alternatively, if the register does define the lower bits of the address, the lower bits of the register defining the base address can be ignored, so that the base address is still the reference address even if it is set to a non-zero value, where several lower bits are set to 0.

In some instances, the base address of the label table can be fixed by design (e.g., restricted to a specific location within the first address space in an instruction set architecture).

However, to increase the flexibility of software developers, it can be useful for the label table base address to be variable based on the label table base address information. The label table base address information may be software-configurable (e.g., in some cases, limited to software with at least a given privilege level). For example, the label table base address information can be specified in a control register. In some instances, multiple segments of the label table base address information corresponding to different translation systems can be specified, wherein the label table base address used to generate the label location address is selected by the label location address determination circuit system based on an indication of which translation system is currently being used.

The first address space may contain at least one translatable address region, each translatable address region having a corresponding label table address region specified within the first address space. A translatable address region may be an area of the address space that allows valid data address translation. Therefore, in response to a data memory access request for a data item at an address outside of a translatable address region, the address translation circuit system may trigger an error. Restricting valid address translation to one or more translatable address regions can be helpful because this leaves available encoding space in the address value for encoding other information (e.g., address labels used for label checking). Furthermore, limiting the size of the translatable address region within the address space reduces the management burden on software developers, as they do not need to maintain a translation table structure that covers such a large address space region.

In some instances, the label table address region may be located within a given translatable address region. This can be simpler for hardware/software designers because the introduction of the label table address region may not require any changes to whether the address space of the first address is translatable or not.

However, the label table address region of a given translatable address region may also be located outside of that given translatable address region. For example, the label table address region may be located in an adjacent region of a translatable address region where data corresponding to the labels in the label table address region is stored. If the label table address region is located outside the corresponding translatable address region, label memory access to an allocated label in the label table address region may be excluded from the requirement of accessing addresses only in translatable regions (unlike data access to data items), and therefore label access to addresses in the label table address region may not trigger an error. Data access to that label table address region may trigger an error. Tag access to a address in a portion of an untranslatable address region other than the tag table address region may trigger an error.

In some instances, for a given translatable address region having a variable size based on region size information, the size of the corresponding label table address region is variable, scaling as the given translatable address region is sized. For example, the translatable region size information can be software-configured to define the size of the given translatable address region. Since the granularity of defining assignment labels for data items in a given memory region can be fixed (depending on the ratio of the assignment label width to the size of the data block sharing a single assignment label), it can be useful to scale the label table storage area size with the size of the corresponding translatable address region, so that the translatable region size information also implicitly defines the size of the given label table address region (and thus defines the size of the offset portion used to form the label location address and the bit position where the offset is applied to the label table base address). Therefore, this method avoids the need to define separate configuration information (e.g., control register states) that defines the size of the label table, separate from the size of the translatable address region.

For example, a ratio between the size of the given translatable address region and the size of the corresponding label table address region can be 2^ ⁿ , where 2^ ⁿ is the number of data bytes of the one or more allocation tags stored in a byte corresponding to the corresponding label table address region.

In some cases, the first address space can support a single translatable address region.

However, other examples (at least for some translation systems or certain operating states of processing circuit systems) may support the first address space comprising a plurality of translatable address regions, each having a separate label table base address that identifies the location of its respective label table address region. Providing multiple translatable address regions can be useful for distinguishing address spaces used for different purposes (e.g., one translatable region used by user/application level software, and another translatable region used by kernel/operating system level software). Therefore, when using multiple translatable address regions, when determining the tag location address, the tag location address determination circuit system can apply the offset relative to the tag table base address, which corresponds to the translatable address region containing the data location address. The tag table base addresses of the plurality of translatable address regions may be variable based on the separate entries of the tag table base address information of the plurality of translatable address regions (e.g., the tag table base address information of each translatable address region may be stored in one or more control registers).

Similarly, these translatable address regions may have individual region sizes, which are variable based on separate entries of the region size information of the plurality of translatable regions. Likewise, the size of a given label table address region may scale with the size of the corresponding translatable region, so the size of the label table address region of one translatable address region may differ from the size of the label table address region of another translatable address region.

Some examples support both single translatable regions and multiple translatable regions translation systems, where the control state stored in the control register defines the configuration of the currently used translatable address region.

In some instances, the offset portion of the data location address excludes the least significant n bits of the data location address, where 2^ ⁿ corresponds to the number of data bytes of the one or more allocation tags stored in a byte of the corresponding label table address region. Therefore, the offset portion may correspond to a portion of the data location address that will select a unique allocation tag from the label table address region (address bits that only distinguish different addresses sharing the same allocation tag are ignored when determining the offset portion).

In some examples, for a data location address within a given translatable address region of size ^2t bytes, the tag location address determination circuit system can determine the tag location address as an address within the given translatable address region, wherein the bits [t-1:0] of the tag location address include: bits [tn-1:0] of the tag location address, which specify the offset portion obtained from the bits [t-1:n] of the data location address; and bits [t-1:tn] of the tag location address set based on tag table base address information, which indicates the tag table base address corresponding to the given translatable address region; wherein 2t bytes ⁿ is the number of data bytes of the one or more allocation tags stored in a byte corresponding to the corresponding tag table address region. This method can be implemented relatively simply in hardware circuit logic and can provide sufficient flexibility in software to determine which parts of the first address space need to be used for other purposes to change the location of the tag table address region within the first address space.

This tag location address determination circuit system can help support a virtualized tag access mode, wherein for a bit address translation performed by the address translation circuit system in response to a tag access instruction that specifies the data location address, when a virtualized tag access mode is enabled for a given address translation stage to remove the address from the first address null... When translating from one address space (e.g., a virtual address space or an intermediate address space) to a second address space (e.g., an intermediate address space or a physical address space): the address translation circuit system obtains a tag location physical address in the physical address space based on the translation of the tag location address determined by the tag location address determination circuit system based on the data location address. This virtualized tag access mode can help reduce the requirement for the memory system to allocate physical memory for tags or provide tag-specific access mechanisms.

In some instances, virtualized tag access mode may be the only supported mode for accessing tags (e.g., corresponding to the second tag translation mode mentioned above). Other instances may also support entity tag access mode (e.g., the first tag translation mode mentioned above).

In some instances, the address translation circuit system is configured to support the virtualized tag access mode for both of the following: a first address translation stage, in which the first address space is a virtual address space and the second address space is an intermediate address space; and a second address translation stage, in which the first address space is the intermediate address space and the second address space is the physical address space. Other instances may support virtualized tag access modes for only one of the first and second address translation stages.

In an example where the virtualized tag access mode is supported for both the first address translation stage and the second address translation stage, the tag location address determination circuit system may include a shared hardware circuit system configured for use in both of the following: when the virtualized tag access mode is enabled for the first address translation stage, the tag location address in the virtual address space is determined based on the data location address in the virtual address space; when the virtualized tag access mode is enabled for the second address translation stage, the tag location address in the intermediate address space is determined based on the data location address in the intermediate address space. Aside from reading in different information about the base address of the label table, the mapping function used to map data location addresses to label location addresses can be the same, whether that mapping function is applied to transform corresponding data/label virtual addresses in the virtual address space or to transform corresponding data/label intermediate addresses in the intermediate address space. Therefore, it is possible to share the same hardware for the two address translation stages to reduce the total pad surface area cost.

As described above, some implementations may support virtualized tags (e.g., virtual or intermediate tags as referred to herein). Therefore, allocation tags can be stored together with data items in an address space (virtual or intermediate address space), and thus can be accessed using data memory access requests. For example, an allocation tag stored at a given address location in the address space can be accessed using a data access operation that specifies that given address location.

Access to an allocation tag with a data memory access request can be unintentional or intentional (and in some cases legal, as discussed further below). For example, due to a programming error, the address location in the memory storing the allocation tag can be unintentionally accessed by a data memory access operation. On the other hand, an attacker can attempt to read or write the value of the allocation tag as part of an attempt to exploit the access provided to the allocation tag with a data memory access request.

As described herein, the assignment tag can be used as part of tag checking, and therefore its value can affect the result of tag checking, i.e., whether an error handling response is executed. Therefore, allowing unintentional or intentional access to the assignment tag via data memory access operations may be undesirable. For example, an attacker could attempt to exploit tag checking's use of the assignment tag to intentionally trigger or not trigger an error handling response based on the assignment tag's value (e.g., as part of a denial-of-service attack, modifying the assignment tag to deny memory access could result in a disruption of the victim software's functionality). Even if an attacker triggers data access to the tag storage area without interrupting the victim's memory access, reading the tag value can provide side-channel information about the victim's program's memory usage. Therefore, an attacker can attempt to read the current value of the assigned tag or attempt to modify the assigned tag value to affect the tag check results. Furthermore, even if there is no malicious attempt to access the assigned label, but this access is solely due to a programming error, the unintentional update of the assigned label value caused by an error affecting one data access operation can lead to false reports of label mismatch errors in another data access operation (which itself is not subject to any programming error). This can cause software developers to unnecessarily spend development time reviewing the code that is allegedly causing the error when the problem is actually elsewhere.

Therefore, it can be advantageous to provide architectural support to identify data access requests that specify the target address corresponding to the memory address of the storage allocation tag.

Therefore, in some examples, an apparatus includes the tag inspection circuit system mentioned above and a tag data access inspection circuit system for performing a tag data access inspection. The tag data access check includes: determining, based on memory address region definition information defining an allocation tag memory address region designated for storing allocation tags, whether a data memory access request specifies a target address corresponding to a memory address in the allocation tag memory address region; and, in response to determining that the data memory access request specifies a target address corresponding to a memory address in the allocation tag memory address region, refusing read or write access to a data value stored at that memory address in the allocation tag memory address region.

Therefore, read or write access to a data value can be denied based on the target address of a data memory access request corresponding to an address specified in the memory region for the storage allocation tag. This provides a mechanism within the architecture for controlling access to the memory region of the storage allocation tag, which prevents unintentional or unauthorized access to the allocation tag.

As discussed above, this method prevents exploitation by potentially malicious attackers by preventing requesters from accessing allocation tags using data memory access requests that directly specify the address of the allocation tag. Compared to alternatives such as data memory access requests based on an address in a specified memory region designated for storing allocation tags, this method provides increased security to prevent attackers from attempting to exploit implementation responses to tag checks.

Additionally, it prevents unnecessary or unintentional access to allocation tags. For example, the requester of a data memory access request may not know the location (virtual or physical) of the allocation tag in memory, or the requester may unintentionally specify a target address corresponding to the memory address in the allocation tag memory address region specified for storing the allocation tag. For example, as discussed herein, when operating in a virtualization tagging mode (such as a virtual tag or intermediate tag), it is possible for memory access instructions to specify a virtual or intermediate entity address as the target address they intend to use to define the location of a given data item, which actually corresponds to a virtual or intermediate entity address within the memory region designated as the storage allocation tag. This prevents such unnecessary or unintentional access to the allocation tag.

In some instances, denying read or write access may include triggering an error, reading the data value as zero, and ignoring one or more of the following: a write request for the data value. For example, to deny read access, in some instances, the data value may be read as zero (in some cases, the read operation may not be triggered and a zero value may be returned). In some cases, to deny write access, the write access may be ignored. In some cases, denying read or write access may trigger an error. For example, an error message may be generated.

In some instances, the memory address region designated for storing the allocation tag is specified to be located in an address space other than a physical address space. For example, in some cases, the memory address region designated for storing the allocation tag is specified to be located in a virtual or intermediate physical address space. Therefore, this access control method can be applied to non-physical (e.g., virtualized) memory tag implementations, such as those discussed herein. Additionally, as discussed herein, in some instances, virtualized tag implementations (virtual or intermediate tags) can be used, and therefore this access control method can support virtualized tags.

In some instances, the memory address region definition information includes memory address region definition configuration information, which defines a variable location of the allocation tag memory address region within an address space. That is, in some instances, the location of the allocation tag memory address region within a given address space may not be fixed. Therefore, the allocation tag memory address region can be defined depending on the specific implementation, allowing software developers flexibility in how the region can be defined and used to store allocation tags.

The configuration information for allocating a tag memory address region may include at least one of the following: information indicating the base address of a tag table; and information indicating the size of a table. Therefore, the configuration information may include information used to determine the range of addresses included in the allocating tag memory address region, rather than defining individual addresses in the allocating tag memory address region. In some instances (e.g., the dual-translatable region example discussed further below with respect to Figure 20), the address space may contain more than one allocation tag memory address region, and therefore, if the target address of a data memory access request corresponds to any of the allocation tag memory address regions defined by the allocation tag memory address region definition configuration information, read/write access may be denied during tag data access checks.

In some instances, for the tag data access check, the tag data access check circuit system is configured to: refuse read or write access to a data value stored at a memory address in the allocated tag memory address region in response to: determining that the data memory access request specifies the target address corresponding to a memory address in the allocated tag memory address region; and determining that the tag data access check enable message indicates that the tag data access check is enabled for the data memory access request.

Therefore, it is also possible to determine whether to deny read or write access based on the tag data access check enabled information, which indicates whether the tag data access check is enabled for the data memory access request (and whether the data memory access request specifies the target address in the allocated tag memory address region). Thus, it is possible to deny read or write access based on whether the tag data access check is currently enabled. This selective enabling of tag data access checks supports the following implementation scenarios: tag data access checks may be performed in some cases but not in others, for example, performed for some data memory access requests but not for others, or performed at some times and not at others. For example, there may be legitimate reasons to allow data access memory operations to read or write to allocated tags, such as when performing a garbage collection operation. In this case, tag data access checks can be disabled based on tag data access check enable information that indicates that tag data access checks are disabled for data memory access requests. Therefore, providing architectural support to enable configurable access to allocation tags that have data memory access requests may be advantageous.

In some implementations, the tag data access check enable information identifies whether the tag data access check is enabled for read-only data memory access requests, and independently identifies whether the tag data access check is enabled for write-only data memory access requests. Therefore, separate control can be provided for read and write requests. Thus, in some cases, read access can be denied while write access can be allowed; and in other cases, read access can be allowed while write access can be denied. Therefore, read-only and write-only control can be supported. Read-only control provides protection against attackers tampering with (i.e., modifying) the value of the allocation tag, while still allowing software to inspect the value of the allocation tag. Write-only control allows software to write to the allocation tag, but prevents the software from inspecting the value of the allocation tag.

In some instances, the tag data access check circuitry is configured to enable tag data access checks for write memory access requests, independent of the tag data access check enable message. Therefore, in some instances, tag data access checks can be performed on write memory access requests, regardless of whether the tag data access check enable message indicates that tag data access checks are enabled. In some cases, it may be advantageous to perform tag data access checks on any data memory access request that is a write memory access request. For example, a write memory access request could be executed by a potential attacker attempting to influence the results of tag checks as discussed herein.

In some instances, the tag data access check enable information identifies whether the tag data access check is enabled for privileged data memory access requests. Therefore, in some instances, tag data access checks can be enabled or disabled for privileged data memory access requests. Garbage collection operations or other authorized data access to assigned tags are more likely to be performed by privilege codes, and therefore, it may be advantageous to be able to disable tag data access checks for such privilege codes.

In some instances, the tag data access check circuitry is configured to enable tag data access checks for non-privileged memory access requests, independent of the tag data access check enable message. Therefore, in some instances, tag data access checks can be performed on non-privileged memory accesses, regardless of whether the tag data access check enable message indicates that tag data access checks are enabled. In some cases, it may be advantageous to perform tag data access checks on any memory access request that is a non-privileged memory access. For example, a non-privileged memory access request might be executed by a non-privileged code that may not be trusted to access and allocate tags.

In some instances, the tag data access check enable information is independent of whether the tag data access check is enabled for privileged data memory access requests, and identifies whether the tag data access check is enabled for non-privileged data memory access requests.

This allows for separate read/write access control for privileged and non-privileged data memory access requests. In some implementations, tag data access checks can be enabled for non-privileged data memory access requests, but disabled for privileged data memory access requests (i.e., the code executes at a privilege level higher than a predetermined privilege level). Therefore, in this implementation, non-privileged data memory access requests attempting to read or write data stored in the allocated tag memory address area can be rejected, while privileged data memory access requests can be allowed to read or write data stored in the allocated tag memory address area. Therefore, reading or writing access to the allocation tag stored in the allocation tag memory address area can be allowed or denied based on the privilege level of the code requesting data memory access to the allocation tag.

In some instances, updating tag data access check enable information is prohibited by instructions executed with insufficient privileges. Therefore, in some instances, code executed with sufficient privileges might be able to update tag data access check enable information to enable or disable tag data access checks, while code executed with insufficient privileges might not. An attacker could potentially attempt to use code to update tag data access check information, and preventing unprivileged code from doing so increases security against potential attackers. Additionally, it may be advantageous for a super administrator or security manager to selectively enable tag data access checks.

In some examples, the tag data access check enable information includes a field in a control register. Therefore, the control register can be checked to efficiently determine whether to enable tag data access check for a given data memory access request. Alternatively, in some examples, the tag data access check enable information may include a first field in a control register for enabling the tag data access check for read operations, and a separate second field (in the same control register or in a different control register) for enabling the tag data access check for write operations. This provides separate control over tag data access checks for read and write operations.

In some examples, the tag data access check enable information may be included in a first field in a control register for enabling the tag data access check for privileged data memory access operations, and a separate second field (in the same control register or in a different control register) for enabling the tag data access check for non-privileged data memory access operations. This provides separate control over tag data access checks for privileged and non-privileged data memory access operations.

In some instances, the tag data access check enable information includes range information that defines at least one address space range that enables the tag data access check. In some instances, the tag data access check enable information can be checked to determine whether the target address of the data memory access request is included within the address space range defined by the range information. Therefore, a plurality of addresses can be efficiently indicated as having tag data access checks enabled for data memory access requests with target addresses within that plurality of addresses.

In some instances, the label data access check enable information may include separate scope information for read and write operations. Therefore, in some instances, the label data access check information includes scope information for defining at least one address space range for enabling the label data access check for read operations, and scope information for defining at least one address space range for enabling the label data access check for write operations. In some instances, the label data access check enable information may include separate scope information for privileged and non-privileged data memory access requests. Therefore, in some embodiments, the tag data access check enable information includes range information for defining at least one address space range for enabling the tag data access check for privileged data memory access requests, and range information for defining at least one address space range for enabling the tag data access check for non-privileged data memory access requests. In some embodiments, the tag data access check enable information includes one or more of the range information for read data access operations, the range information for write data access operations, the range information for privileged data memory access requests, and the range information for non-privileged data memory access requests.

In some instances, the label data access check enable information is specified in a translation table entry corresponding to the target address of the data access request. This provides an efficient indication of whether label data access checks are enabled. In some instances, since access to the translation table entry is already required to perform the translation of the target address, using the translation table entry information corresponding to the target address of the data access request provides a particularly efficient mechanism for determining whether to enable label data access checks.

In some instances, for the tag data access check, the tag data access check circuit system is configured to: refuse read or write access to a data value stored at a memory address in the allocation tag memory address region in response to: determining that the data memory access request specifies the target address corresponding to a memory address in the allocation tag memory address region; and the memory access request is triggered by an instruction other than at least one type of data access instruction that allows access to the allocation tag in the allocation tag memory address region.

Therefore, in some instances, read or write access can be denied because the class of the instruction triggering the data memory access request is not a data access instruction class that allows access to the allocation label in the allocated label memory address region. In some instances, the class of the data access instruction can be specified as allowing access to the allocation label, while instruction classes other than the allowed classes can be denied access to the allocation label. Thus, the type of data memory access can be used to selectively deny or allow read or write access to the allocation label.

In some instances, for the tag data access check, the tag data access check circuit system is configured to refuse read or write access to a data value stored at a memory address in the allocated tag memory address region in response to: determining that the data memory access request specifies the target address corresponding to a memory address in the allocated tag memory address region; and determining that the data memory access request is a non-privileged memory access request. Therefore, read or write access can also be refused based on the data memory access request being a non-privileged memory access. As discussed above, preventing non-privileged memory access from accessing allocation tags may be advantageous, as attackers may use non-privileged memory access to attempt to read or modify allocation tags to affect the results of tag checks.

In some embodiments, a tag location address determination circuit system is provided for determining, when operating in a virtualized tag mode, a tag location address corresponding to an assigned tag in a first address space other than a physical address space, based on identifying a data location address of a given data item at a location in a first address space; wherein the tag data The access check circuit system is configured to refuse read or write access to a data value stored at a memory address in the allocation tag memory address region in response to the following: determining that the data memory access request specifies the target address corresponding to a memory address in the allocation tag memory address region; and determining that the tag location address determination circuit system is operating in the virtualized tag mode.

Therefore, this method supports tag data access checks in a virtualized tag mode, where an address is designated for storing the tag in a first address space, which is translated into a physical address space through one or more address translation stages. Furthermore, it can also refuse read or write access based on the tag location address determination circuit system operating in a virtualized tag mode. Thus, this method supports virtualized tags (i.e., virtual tags or intermediate tags discussed herein).

The techniques described above can be implemented within a data processing device having a hardware circuit system that provides for implementing the tag checking circuit system, address translation (memory management) circuit system, tag location address determination circuit system, and/or tag data access checking circuit system described above. However, the same techniques can also be implemented within a computer program that runs on a host data processing device to provide an instruction execution environment for executing object code. Even if the host data processing device itself does not support the architecture, this computer program can control the host data processing device to simulate the architectural environment it will provide on hardware that actually supports object code based on a certain instruction set architecture. The computer program may have tag checking program logic, address translation (memory management) program logic, tag location address determination program logic, and/or tag data access checking program logic, which simulates the functions of the corresponding circuit system discussed above, including support for virtualized tag modes, architectural suppression of tag address translation operations, tag location address determination, and/or tag data access checking. For implementations that use software to simulate the functionality of a hardware implementation scheme, the reference to "physical address space" in the description of the corresponding hardware implementation can be understood as referring to the simulated physical address space in the simulation. Since the physical address space of the simulated target instruction does not actually refer to the location in the host's hardware memory storage when the simulated target instruction executes the function of the environment, it can be further mapped to the virtual address space used by the host data processing device.

For example, such simulators can be useful when legacy code written for an instruction set architecture is executed on a host processor that supports a different instruction set architecture. Furthermore, because software execution in a simulator allows software testing to run in parallel with ongoing development on hardware that supports the new architecture, simulation can allow software development for a newer version of the instruction set architecture to begin before the processing hardware supporting that new architecture is ready. Simulators can be stored on a storage medium, which can be a non-transitory storage medium.

The following diagrams illustrate specific examples.

Figure 1 illustrates an example of a data processing device 2, which may be a processor, such as a central processing unit (CPU). Device 2 includes an instruction fetch/decode circuit system 4, which fetches program instructions from an instruction cache or memory for execution by an execution circuit system 16, and decodes the instructions to generate control signals to control the execution circuit system 16 to execute the operations represented by the instructions. The execution circuit system includes several execution units 20, 22, and 28 for executing various types of instructions by referring to register states stored in register 14. For example, the execution circuit system 16 may include: an arithmetic/logic unit (ALU) 20 for performing arithmetic and logical operations (e.g., Boolean operations); a branch unit 22 for executing branch instructions that trigger discontinuous jumps in the program flow; and a load/store unit 28 for performing load/store operations to load data from the memory system to register 14 or store data from register 14 to the memory system. The memory system may include one or more levels of cache memory and random access memory storage.

The memory management unit (MMU) 6 is an example of an address translation circuit system provided to support the load/store unit 28 in performing memory access operations (load/store operations) and to support the instruction fetch circuit system 4 in fetching instructions from the memory system. Although Figure 1 shows a single MMU 6 for both instruction fetching and load/store operations triggered by executed instructions, it will be understood that in some examples, two different MMU units may be provided, one for handling the memory management functions of instruction fetching and the other for handling the memory measurement functions of the load/store operations performed by the load/store unit 28.

MMU 6 controls access to the memory system based on address mapping information and memory attribute information specified by a translation table structure stored in the memory system. The address mapping information is used to translate between virtual addresses in the virtual address space (used to identify executable instructions to be fetched and/or target data to be accessed by load/store operations) and physical addresses in the physical address space (used by the underlying memory system to identify the storage location of the required instructions and/or data). Memory attribute information can specify permissions or memory region attributes that control whether a given memory access request is allowed to access information at the corresponding memory address and/or control how memory access operations to that address are processed within CPU 2 or in the memory system itself. The translation table structure is set by software running on device 2. The software can write translation table entries of the translation table structure into the memory system and set the base address stored in the base address register of MMU 6 to indicate the location where the translation table structure can be accessed. Updates to the base address register may be limited to software running at a given privilege level or higher (e.g., application-level software may not be allowed to update the base address register, but operating system-level or super-manager-level software may be allowed to update the base address register).

MMU 6 includes one or more Translation Backup Buffers (TLBs) 8 for caching information derived from a translation table structure stored in the memory system. This allows future memory accesses to be processed more quickly than if the same information had to be retrieved from memory again, as the translation table information already retrieved from the memory system for previous accesses can be reused. If the required information is not available in TLB 8 for a given memory access, the table walk circuit system 12 can perform a translation table walk operation to issue one or more memory access requests to the memory system to locate the required translation table information. In some instances, this translation table walkthrough may involve a series of related memory accesses to traverse multiple levels of translation tables, where higher-level tables in the translation table structure include pointers that reference entries in lower-level tables.

As shown in Figure 2, in some implementations, MMU 6 can support a two-stage address translation system, where the translation between virtual address space 40 and physical address space 52 includes a first address translation stage and a second address translation stage. The target address for a given memory access operation is specified by instruction fetch circuit system 4 or execution circuit system 16 as the target virtual address 42 in virtual address space 40. In the first address translation stage, the target virtual address 42 is mapped to the target intermediate address 48 in intermediate address space 46 based on the address mapping information defined in the stage 1 translation table structure 44 (as mentioned above, which may contain multiple levels of tables). In the second address translation stage, based on the address mapping information defined in the stage two translation table structure 50 (which may also contain tables at multiple levels), the target intermediate address 48 is mapped to the target physical address 54 in the physical address space 52. The Phase 1 translation table structure 44 can be controlled by the operating system, and the Phase 2 translation table structure 50 can be controlled by the super administrator (that is, the update of the base address register used to provide the base addresses of the Phase 1 and Phase 2 translation tables 44 and 50 can be restricted to instructions executed by operating system level privileges or higher (for the Phase 1 translation table base address) or instructions executed by super administrator level privileges or higher (for the Phase 2 translation table base address).

Two-stage address translation facilitates virtualization, where several different client operating systems (each managing a corresponding set of Stage 1 translation tables 44 for applications managed by the operating system) coexist on the same hardware platform. Each client operating system can behave as if it were a unique operating system, and from the operating system's perspective, the intermediate addresses generated in Stage 1 translation may appear to be physical addresses referencing memory system locations. However, since different client operating systems may specify the same intermediate address for different data items used by the respective operating systems or for applications managed by the operating system, the super manager can set up a Stage 2 translation table 50 for each client operating system to ensure that the same intermediate address value specified for different client operating systems can be mapped to different physical addresses in the physical address space 52 depending on which client operating system is in operation. The super manager can update the stage 2 base address register, which identifies the location of stage 2 translation table 50 in context switching between client operating systems (similarly, the operating system can update the stage 1 base address register, which identifies the location of stage 1 translation table 44 in context switching between applications, to manage switching between several different translation table structures).

The translation table entry that provides the address mapping for either the intermediate address in stage 1 or the physical address 54 in stage 2 is called a page descriptor (distinguished from table descriptors at higher levels of the table, which do not provide address mappings but instead provide pointers to subsequent levels of the table structure). As shown in Figure 3, in addition to the translated address mapping (e.g., an indication of an intermediate address mapping translated in stage 1 or a physical address mapping translated in stage 2), page descriptor 60 may also specify memory attribute information and/or permissions. The memory attribute information indicates the nature of the address space region corresponding to this page descriptor 60, and the permissions indicate information used to define rules used to control whether various types of memory access operations are allowed to access the address space region corresponding to page descriptor 60. As shown in Figure 3, while some memory attribute information can be specified directly in page descriptor 60, page descriptor 60 may also specify references to indirect tables 62 that provide memory attribute information (e.g., stored in register 14 of processor 2). This can be helpful when the encoding space for attribute information is limited within page descriptor 60 itself. Indirect table entry identifiers encoded directly in page descriptor 60 can indicate which entry in indirect table 62 specifies the attribute information of the associated address space region (page). A given entry in indirect table 62 can have a larger capacity than page descriptor 60 itself can store for additional attribute information. Using indirection can also be helpful because it means that if the same update to memory attribute information is required for multiple different pages in the address space, this update can be performed more efficiently by simply updating a single indirect table entry referenced by many page descriptors, rather than updating each page descriptor individually. Therefore, it will be understood that when referring to memory attribute information below, that information can be specified directly or indirectly in the translation table entry 60 used to identify the memory attribute information (indirect specification refers to the case where the translation table entry 60 contains an index value that identifies an entry in the indirect table 62 that provides the required memory attribute information).

In addition to supporting the two-stage address translation system shown in Figure 2, MMU 6 can also support other translation systems involving single address translation stages (directly from virtual address to physical address, using a set of translation tables similar to stage 1 and stage 2 translation tables 44 and 50 shown in Figure 2, which may be multi-level). When multiple translation systems are supported, which particular translation system is used at a given time may depend on, for example, the current operating state of the processor. For example, the current operating mode, exception/privilege level, and/or other control information stored in register 14 can be used to determine the currently used translation system.

Referring again to Figure 1, device 2 includes a tag checking circuit system 34, which supports tag checking operations performed on memory access operations to the load/store unit 28. Such tag checking operations can be useful for detecting memory security errors. As discussed later, device 2 may also have a tag location address determination circuit system 10 and a tag data access checking circuit system 32. Although Figure 1 shows an example where the tag checking circuit system 34 and the tag data access checking circuit system 32 are separate from the load/store unit 28 and the MMU 6, other examples may provide these components as part of the load/store unit 28 or the MMU 6. Similarly, although the tag location address determination circuit system 10 is shown in the example of Figure 1 within the MMU 6, the tag location address determination circuit system 10 can also be provided separately from the MMU 6.

Software intended to be executed by a data processing device is typically written in a high-level programming language and then compiled into code according to the instruction set architecture supported by the device on which the software will be executed. For example, the software may initially be written in a higher-level language (such as Java, C, or C++) and then compiled into a natively supported instruction set architecture (such as x86 or ^Arm® ).

Because some higher-level programming languages (such as Java) include runtime error detection checks to check for certain memory access-related errors, they are considered memory-safe languages. Conversely, memory-unsafe languages (such as C and C++) do not include such runtime error checks. The continued use of the term "memory-unsafe language" implies that a large number of memory-related errors may exist in compiled code based on a given instruction set architecture, potentially creating vulnerabilities that can be exploited by attackers or other malicious parties. Such errors may include: • Boundary violation, where an array index supplied by the code is outside the legal boundaries of the array; • Use-after-free error, where memory is accessed after the memory location has been deallocated or freed; • Use-after-return, where memory is accessed for an address associated with a variable (such as a value on the heap) used within the function after a return from the function; • Use-out-of-scope error, where a variable is accessed outside its declared scope; and • Use-before-initialisation error, where the memory address associated with a variable is accessed before the variable has been initialized.

These are just some examples of memory-related errors that can lead to unpredictable behavior and potentially provide avenues for attackers to exploit. Therefore, providing architectural support within the instruction set architecture supported by a given processing device is desirable to assist in the detection of certain classes of memory security errors at runtime.

One method to prevent certain types of memory misuse as described above is to provide allocation tags stored in the memory system, which are associated with blocks of one or more memory locations. When a memory access operation is requested to check the tags based on a target address calculated from a given addressing operand (e.g., a register operand stored in one of registers 14), the memory access circuit system can compare the address tag associated with the given addressing operand with the allocation tag, which is associated with a data item stored at a location in the memory system identified based on the target address. The memory access circuitry system can generate an indication of whether a match has been detected between the allocation tag and the address tag. This indication can be used to control whether memory access is allowed to proceed successfully, or whether subsequent operations can succeed, or it can be reported only when memory access is allowed to continue normally (e.g., in an error log or by setting an indication in a register). The allocation tag may also be called a "guard tag," "memory colouring tag," or "memory safety check tag."

Such tag checks can be useful because software based on memory-unsafe languages (such as C or C++) can set allocation tags associated with data item blocks when initializing memory regions, allowing access to specific values via expected codes. The corresponding address tag values can be associated with the address pointer operands used to generate the target address to access those blocks. Different allocation tag values can be assigned to adjacent memory regions intended for different purposes, so that if the address pointer intended for one region is accidentally set to a value that causes it to access another region, an error can be detected based on tag mismatch. Therefore, if a memory usage error occurs, such as an address pointer being used out of bounds or extending beyond its initialized valid range, the allocation label associated with the accessed data item may not match the address label associated with the address operand used to access the data item. In this case, it remains to be seen whether a matching indication can be detected to trigger an error handling response or error reporting mechanism. The specific response taken may depend on the specific requirements of the software being implemented or the specific microarchitecture implementation of the architecture. Therefore, even if high-level languages do not have means for performing runtime error checks to prevent memory access errors, an ISA for compiled code can still include architectural features for performing such checks.

Figure 4 schematically illustrates the concept of a tag checking operation performed by the tag checking circuit system 34 in response to a tag checking memory access. The address space used to refer to the memory location within the memory system can be logically divided into several blocks 70, each of which is assigned a corresponding tag 72. For example, the address space block corresponding to a tag 72 can be 16 bytes, for instance. As further described below, there are several ways to manage the association between data item block 70 and its corresponding tag 72, or based on a virtualized tagging scheme, wherein the address translation function of MMU 6 is used to identify the separate physical address of the data item in the given block 70 and its corresponding allocation tag 72, or based on a physical tagging scheme, wherein the data item 70 and its corresponding allocation tag 72 are identified using the same physical address, and the memory system is responsible for managing the storage of allocation tag 72 and providing a mechanism for retrieving data items and/or tags associated with a given physical address. Therefore, there is flexibility in implementing the association between data item 70 and corresponding allocation label 72 in various ways, but generally, data items in each block 70 of the memory address space can be associated with corresponding allocation label values 52. The specific value assigned to a given allocation label of a given block 50 of the address space is arbitrary (e.g., selected by software) and can be controlled based on the execution of label setting instructions supported by the instruction set architecture (ISA) supported by the processor 2. Similarly, instructions for setting address labels for address pointer operands can be supported in the ISA.

Therefore, when a memory access needs to be checked via a tag, address tag 80 (which is associated with address operand 82 used to derive the target address of the data item to be accessed) is compared with allocation tag 72, which is associated with the block containing data item 70 corresponding to data item 84 at the target address. For example, in Figure 4, the target address points to data item B1, which is labeled 84 in Figure 4. Therefore, allocation tag B associated with the block containing data item B1 is obtained from the memory system and compared with address tag 60 associated with target address 62. As shown at the top of Figure 4, address tag 80 can be dynamically determined based on the selected bits of the address operand used to calculate the target address. Specifically, address label 80 is derived from a portion of address operand 82 that is not used to indicate the address bits used to calculate the target address of the required data item 84. For example, in some ISAs, the top portion of the address value's bits may always have a specific fixed value (such as sign extension) (all 0s or all 1s), and thus the address operand can be labeled with address label 80 by overwriting these unused bits with any label value. The specific address label value may be selected by, for example, a programmer or compiler. Address label 80 and allocation label 72 may be relatively small in number of bits (e.g., 4 bits), and therefore do not need to occupy much space in memory or at the target address. Providing a 4-bit label space (i.e., 16 possible values for the label) is often sufficient to detect many common types of memory access errors.

Therefore, when performing a tag check memory access, the tag check circuit system 34 compares the address tag 80 obtained from the bit arithmetic units with the allocation tag 72 obtained from the memory system and determines whether they match. The tag check circuit system 34 generates a match indication indicating whether the address tag 80 and the allocation tag 72 match. For example, this match indication may be an error signal generated when there is a mismatch between the address tag 80 and the allocation tag 72; or it may be an indication placed in a status register indicating whether a tag match exists; or it may be an entry added to an error report to indicate the address where an error was detected and/or the instruction address that triggered the error instruction. Whether a match is detected between the assignment label and the address label, and the specific form of the resulting indication, can vary between different implementation schemes.

In some cases, tag checking operations may include controlling whether memory access is allowed for data items associated with a target address, depending on whether a match is detected between the allocation tag and the address tag.

However, in other instances, tag-based memory access checks may involve performing a memory access to the data item associated with the target address regardless of whether a match is detected between allocation tag 72 and address tag 80. For example, in some cases, accessing the allocation tag may sometimes require sending separate read requests to memory, separate from the requests for the corresponding data item. Thus, if a memory access to the data item is delayed until the allocation tag and address tag have been compared, the actual memory access processing may be delayed. Therefore, it may be desirable to perform a memory access to the data item before the allocation tag becomes available, and then check the allocation tag after it becomes available.

In one example, the indication of whether a match was detected could be a signal indicating an error condition, generated when a mismatch is detected between the allocation tag and the address tag. For example, if an access permission is violated or an unmapped address is accessed, the memory access circuitry system could signal a similar memory error to the resulting error, or it could indicate a different type of error condition. Error signals can trigger the processing circuit system to execute exception handling routines in response to the detected error, and can prevent successful memory access (or prevent code from advancing beyond the point where the label mismatch is detected if the label mismatch is not detected until some time after the memory access has been initiated).

Alternatively, a status indication can be recorded in a control register accessible by the device's processing circuitry to indicate whether a match or mismatch was detected when comparing the assignment tag and the address tag. The status information can then be read by subsequent instructions to check if the memory access is valid.

Another option for reporting matching or mismatched address and allocation tags is to log information in an error log associated with the executed code segment, tracking any allocation tag errors detected throughout the code segment. For example, in response to a mismatched allocation and address tag, the target address that triggered the mismatch or the instruction address that triggered the mismatched memory access could be logged in the error log, which could be stored in memory. In this case, instead of performing any specific action to block code operation, the error could simply be logged in the error log. The error log can then be used by the software provider to help them review the code for errors and identify development areas for bug fixing in subsequent software versions.

Therefore, it will be understood that there are various methods in which the memory access circuitry system can generate tag match/mismatch indications (and thus there are various possible error handling responses that can be taken).

In some instances, each addressable data item may have its own allocation label (e.g., each block 70 shown in Figure 4 may contain memory of a single byte).

However, in practice, the management burden of setting individual allocation labels for each addressable data item (e.g., each byte of memory address space) can be too high, and associating each allocation label with a block of address space containing multiple bytes can be more efficient. In this case, a block 70 containing several adjacent bytes in memory (each byte can be individually addressed by a different address corresponding to a data item within block 70) can share the same allocation label, which is sufficient to detect common forms of memory-related errors.

Address tags can be associated with target addresses in different ways. In some cases, the address tag can be specified separately from the tag address, for example, using a separate register specified by a tag-check memory access instruction that triggers a tag-check memory access operation. However, in other instances (as shown in Figure 4), the address tag can be determined based on one or more select bits of the target address. That is, the address tag can contain information derived from a portion of the target address itself. In many cases, although the instruction set architecture may support addresses with a certain number of address bits (e.g., 64 bits), a given hardware device may not actually need so much memory capacity that it will use all feasible addresses that can be represented using that number of address bits. For example, given the current trend in device usage, there is no current need to provide ²⁶⁴ individually addressable locations. Therefore, in many cases, some bits of a memory address can be effectively unused and can always have the same value or be a sign extension of the most significant "real" address bit (so that the unused portion is set to all 0s or all 1s). This unused portion can thus be reused to represent address tags or to derive values from address tags, avoiding the need to access separate registers to obtain address tags and making it easier to track the correspondence between addresses and corresponding address tags, since the address tag, by definition, can be transmitted along with the address whenever it is manipulated or moved between registers.

In instances where a portion of a target address is used to determine an address label, it's important to note that this address label is distinct from the label portion of the target address. This label portion can be used by the cache to derive a cache label used to determine whether information associated with the target address is stored in the cache. Many caching schemes store a label portion of one address of a cached data segment next to that data in the cache, allowing for comparison of that address portion with the cache label stored next to the cached data when searching for a given address in the cache, to determine whether the cached data actually corresponds to the desired address. However, in this case, the tag portion of the address, compared to the tag stored in the cache, will be derived from the portion of the address that actually identifies the specific data item requested for access. That is, changing the address of the cache tag portion, by definition, will result in addresses pointing to different locating locations within the memory system, causing read/write operations to operate on different data items. Conversely, when address tag 80 is used for tag-checking memory operations, the memory access circuitry can independently select the location to store the required data item based on address tag 80. In other words, even if the address tag 80 within the address operand has different values, the location in memory referenced by the target address may still be the same. The choice of location for accessing the required data item in memory depends only on the portion of the target address other than address label 80. This output compiler has the freedom to set the address label associated with a specific address to any value to match the corresponding allocation label value of the relevant data block allocated in the memory system.

In some implementations, the instruction decoder may support separate unlabeled and labeled variants of memory access instructions. In this case, a labeled memory access operation can be triggered in response to a labeled variant of the memory access instruction. Conversely, an unlabeled memory access instruction can simply trigger an access to the addressed location identified by the target address specified by the instruction, without requiring an allocation tag or performing any comparison between the address tag and the allocation tag.

However, in other implementations, all memory accesses can be viewed as tag-check memory accesses. Therefore, in some cases, any memory access instruction can be considered as triggering the memory access circuitry to perform a tag-check memory access operation as described above.

However, even if all memory access instructions are interpreted as tag-check memory access instructions, the instruction set architecture can still support selectively disabling assignment tag comparisons for certain operations in other ways. For example, control parameters in the control registers of a processing device can be selectively disabled for tag comparisons.

Furthermore, as described below, the memory attribute information encoded directly or indirectly in the translation table entry associated with the target address can specify whether the accessed memory region is a tagged memory region that requires tag checking or an untagged memory region that does not require tag checking. Therefore, even for the same instruction encoding, whether tag checking is performed depends on the memory attribute information set for the target address in the translation table entry accessed by MMU 6.

Another option is to interpret a specific value of the address label or assignment label as a "match all" value. This effectively disables the effect of label comparison for any feasible value of the relative label, treating "match all" label values as matches, so that no error is reported regardless of whether the address label matches the assignment label. Therefore, in some cases, the comparison in label checking can detect whether there is a mismatch between assignment label 72 and address label 80. However, not all cases where the values of assignment/address labels 72 and 80 are different need to be detected as mismatches that trigger an error handling response. Since if one or both of assignment label 72 and address label 80 are "match all" labels, no error handling response needs to be triggered.

Figures 5, 6, and 7 illustrate some example use cases, showing how support for this type of tagging can help catch memory security usage errors, such as out-of-scope use or use after release errors. Figure 5 illustrates the steps performed by software (e.g., an operating system) responsible for allocating memory regions for a specific purpose to set allocation tag values associated with the allocated memory regions. As shown in the left portion of Figure 5, there is initially a free memory region that has not yet been allocated for any specific purpose, and its initial assigned allocation tag value is 4 (in this example, each 16-byte data grain has a separate allocation tag value). After a memory allocation operation, a portion of the free memory area is allocated to store specific data. The memory allocation software executes a tag setting instruction to set the allocation tag value associated with the newly allocated data area to a different value of 6, distinguishing it from the allocation tag value of 4 for surrounding memory areas. When the memory allocation software subsequently dealslocates the same area, it updates the allocation tag value of the deallocated area to a different value (tag=7) than the value before deallocation (tag=6). The specific allocation tag values shown in Figure 5 are arbitrarily chosen (for example, the new allocation tag value 7 for the deallocated memory region is arbitrary and can be replaced by 2 or 3 or any other value different from 4 or 6, the value set for the allocation tag in adjacent regions, and the value set for the allocation tag of the deallocated region before deallocation). However, typically, allocation software will be designed to ensure that the allocation tag values associated with a given memory region are updated when allocating or deallocating memory, such that the allocation tag values change when transferring between free and allocated regions or when transferring between allocated regions allocated for different purposes.

Figure 6 illustrates how tag checking can be used to detect out-of-bounds use of a pointer, setting the allocation tag value of a memory region according to the middle portion of Figure 5 (before the deallocation of the memory region assigned the allocation tag value 6). The assigned address pointer "ptr" loaded from memory is used as an address operand to generate the target address of the memory. The software developer or compiler that generates the executing software wants to use this pointer to reference the data region 86 assigned the allocation tag value 6, and therefore at the allocation point, the pointer "ptr" is similarly assigned the address tag value 6. Therefore, in order to use the pointer "ptr" correctly within the limits, the address calculated based on the pointer falls within the data area 86. The allocation tag 72 obtained from the memory system has a value of 6, and the address tag 80 obtained from the address operand (pointer) used to calculate the target memory address also has a value of 6. Thus, a tag matching indication is generated, and no error response needs to be triggered.

However, sometimes the same pointer "ptr" can be used out of bounds to generate a target address in a memory address region 88 that is different from the region 86 to which the pointer is intended to be accessed. For example, data region 86 may have been allocated as a buffer data structure, to which data items can be pushed for processing by another software program. The buffer data structure may have been allocated with a maximum size corresponding to the range of the allocated data region 86, and for robust memory security software, software developers or compilers should ideally ensure that the software includes one or more instructions to check for buffer overflow before pushing further data onto the buffer. However, some software developers may forget to include such security checks in their software code. Therefore, if too many function instances that push data to the buffer are executed, the address pointer used to track the next point in the buffer where data should be inserted may extend out of bounds, beyond the region 86 allocated to the buffer. This could potentially corrupt other data in the memory region beyond the region 86 allocated to the buffer (in this example, the region beyond the buffer is an empty region, so the error may not necessarily lead to incorrect functionality, but it may have already been allocated for other data, which could be corrupted due to the out-of-bounds use of the pointer "ptr"). This poses a risk because (although buffer overflow itself may not always be a problem,) it can be exploited by attackers to interrupt the operation of the victim software or to branch into harmful utility code, allowing attackers to access information they would otherwise have access to. However, by supporting memory tags, tag checking can be used to detect such out-of-bounds use of the pointer "ptr," because for address space region 92 accessed using the pointer, the address tag value 6 will not match the allocated tag value 4. Therefore, a label mismatch indication can be generated to prevent memory access from continuing and/or an error report can be generated that can be sent back to the software developer to help them fix vulnerabilities or potential errors in their code.

Similarly, Figure 7 illustrates that even when a pointer is used within its intended address bounds, there may be timing errors in the timing of memory accesses to a given address space region based on the pointer. When data is stored in a given memory region 86, a given address pointer "ptr" may have been created for use within a finite number of cycles, but after that memory region has been deallocated, the pointer may still remain in memory and may be accidentally used to calculate the target address for another memory access. This could potentially corrupt data now stored in the same memory region that should not be accessed using the pointer "ptr". Since the allocation label value is updated from 6 to 9 when the allocated data area 6 is deallocated, the use of the pointer generated before deallocation (which will be associated with address label 6) can be detected based on the mismatch between address label 6 and allocation label 9, and used again to trigger an error report.

It will be understood that Figures 6 and 7 only show some types of memory usage errors that can be detected using these tags. However, in general, support for assigning address tags to address pointers stored in memory associated with the corresponding data items and for allocating tags can help catch memory security errors, which can help software developers develop more robust and secure code.

Figure 8 illustrates the steps performed by the tag checking circuit system 34 for the tag checking operation. In step 800, in response to a tag-checked memory access instruction, the tag checking circuit system 34 obtains an address tag 80 from an address operator 82, which is used to calculate the target address of the data item accessed in response to the tag-checked memory access instruction. Furthermore, the tag checking circuit system 34 obtains an allocation tag 72 from the memory system associated with the data item identified by the target address of the memory access instruction. In step 802, the tag checking circuit system 34 compares address tag 80 and allocation tag 72, and in step 804 detects whether a tag mismatch is detected. Typically, a tag mismatch may be detected when the address operand is not equal to the allocation tag. However, in some implementations, "match all" values are supported, so if either the address operand or the allocation tag has a "match all" value, a tag match can be detected regardless of the values of the other tags. If a tag match is detected (e.g., because address tag 80 and allocation tag 72 are equal, or because one of the tags has a "match all" value), a tag mismatch error is not required to be transmitted in step 806. If a tag mismatch is detected, an error handling response is triggered in step 808. Error handling responses may include reporting errors and/or updating error log information.

To support the aforementioned tag checking, a mechanism is provided to support the storage of allocation tags 72 associated with given data items stored in the memory system. Various different methods exist for managing this association, either using address translation functionality provided by MMU 6, or using hardware in the memory system to identify the location of the allocation tag corresponding to the given data item.

Figure 9 shows an example of associating an allocation label with its corresponding data item using entity labels. In this example, when locating the allocation label associated with a given data item, the allocation label is identified based on the same entity address used to identify the corresponding data item. Therefore, the address translation performed by MMU 6 does not require any special translation function to generate the address of allocation label 72. Instead, an address translation from virtual address to physical address to obtain the physical address of the data item will be performed sufficient for any operation requiring the associated allocation tag 72 (e.g., the operation could be a tag check associated with a tag-checked memory access to the data item, or it could be writing to or reading the allocation tag 72 without also accessing the separate tag set instruction or tag read instruction for the corresponding data item). Using this method, the memory system supports a mechanism for identifying the location of stored data items and associated allocation tags based on the physical address of the data item/tag pair, so that the required allocation tag can be read/written to the memory system during tag access.

Various mechanisms can be used by the memory system to specify tag storage. As shown in Figure 9, one option is to implement separate physical memory units for storing data and tags, where the same physical address obtained in address translation is sent to the data physical memory (for data access) and the tag physical memory (for tag access), and used to identify the location of the corresponding data item or assign a tag. Another option is to store the assigned tag value together with the corresponding data item in a shared memory storage unit. For example, some memory storage units may include spare capacity for error correction codes associated with the stored data items. Error correction functionality may not always be in use, so error correction code storage can be reused for storing allocation tag values. Another option is to partition a portion of a given data entity memory unit used to store data items and reserve allocation tags associated with the data items stored in that memory unit. The partitioned region can be fixed or variable. If a variable region is specified, some storage status information (e.g., base address or a table structure separate from the base address and translation table structure used by MMU 6) can be maintained in memory to identify which region of data storage provides a tag associated with a specific data item. Using the partitioning method, since the tag storage system can be based on a portion of the internal address space of the physical memory system, it is also possible to use the mapping information in translation tables 44 and 50 to map the physical storage location of the storage tag to a virtual address. However, unlike the virtualization tagging method discussed below, in this case, the virtual address mapped to the tag storage will be translated into a physical address, just like any other data address, where MMU 6 does not support tag-specific address translation functionality separate from data address translation. If entity tags are used, the specific mechanisms by which the memory system maintains the association between data items and tags may be implementation-specific and may be invisible to the software running on device 2.

Figures 10 and 11 illustrate examples of using virtual tags to associate assignment tags 72 with their corresponding data items. In these examples, the address translation functionality provided by MMU 6 is used to translate the data location virtual address (VA) that identifies a given data item into separate physical addresses PA1 and PA2 that identify the data item and its associated assignment tag. By supporting a virtualized tag translation mode, in which the assigned tag 72 is assigned a physical address different from its corresponding data item (based on separate address translation mapping at least one of the phase 1 and phase 2 address translations), the implementation of physical memory becomes simpler because the memory system does not need to implement any special mechanisms for managing tag storage. From the memory system's perspective, allocation tags appear to be data items. Therefore, for tag-checked memory access that accesses a given data item and its associated tag value, two separate memory access requests can be issued to the memory system: one specifying the data location entity address PA1 that identifies the location of the stored data item, and the other specifying the tag location entity address PA2 that identifies the location of the stored allocation tag. The MMU (Address Translation System) can support mechanisms that allow software to define translation table structures to control the translation from data location VA to the separate data location and tag location entity addresses PA1 and PA2.

In the example of Figure 10, virtual labels are used so that the address translation stage that maps the target address of a data item to separate addresses of the data item and the label is Stage 1 address translation. In this example, two independent Stage 1 address translation mappings are used to obtain the respective data location and label location intermediate addresses IPA1 and IPA2 corresponding to the specified data item virtual address VA. Each of these intermediate addresses IPA1 and IPA2 can then be further translated in Stage 2 into the corresponding physical addresses PA1 and PA2 for accessing the corresponding data stored in the memory system and allocating the label. As shown by the dashed lines in Figure 10, one way to control the use of separate Stage 1 translation mappings for data and label translation is as follows: For label translation, a modification is applied to the data location VA to generate a modified VA that identifies the location of the assigned label in the virtual address space, and then this modified VA is used as the input to look up the translation table structure, such that the separate entries of Stage 1 translation table 44 are used for label address translation compared to the entries from the same Stage 1 translation table 44 used for data address translation. Other embodiments may not apply the address modification, but instead select different sets of translation tables 44 (based on different base address registers) depending on whether the Stage 1 address translation is performed for data item access or label access.

On the other hand, in the example of Figure 11, using intermediate labels, the address translation stage that maps the address of the identified data item to separate addresses of the data item and the label is a stage 2 address translation. In this example, stage 1 address translation translates the VA of the data item into the corresponding intermediate address IPA1 (where the same stage 1 address translation mapping is shared by both the data item and the label), but stage 2 translation then selects separate stage 2 address translation mappings to generate the data location entity address PA1 and the label location entity address PA2, respectively. Similarly, as shown by the dashed lines in Figure 11, for label address translation, some instances may apply an address modification operation to determine the label location intermediate address IPA2 within the intermediate address space based on the data location intermediate address IPA1, such that the separate entries in the stage 2 translation table 50 are used for label address translation compared to the entries from the same stage 1 translation table 44 used for data address translation. Other instances may not apply that address modification, but instead select different sets of stage 2 translation tables 50 (based on different base registers) depending on whether the stage 2 address translation is performed for data item access or label access.

As shown in Figure 10 (which is not shown in Figure 11 for simplicity, but can also be applied to intermediate labels), for example, when the number of bits in an allocation label is less than the number of bits in an addressable memory location (e.g., a byte), two or more allocation labels can be stored at the same label location entity address PA2, and therefore a portion of the data location address VA or IPA1 can be used to select among the labels stored at the same label location entity address PA2.

Therefore, virtualized tag translation mode is typically supported. In the given address translation stage that maps addresses from a first address space to a second address space, the first address of the data location in the first address space is translated into separate data locations and tag locations in the second address space. The first address of the data location depends on the data virtual address used to identify the data item in the virtual address space, and the physical addresses of the data item and the associated allocation tag depend on the separate data location and tag location second addresses, respectively. For the example with virtual labels shown in Figure 10, the address translation stage is stage 1 translation, the first address space is the virtual address space 40, the second address space is the intermediate address space 46, the first address of the data location is the data location virtual address, and the second address of the data location and the label location are intermediate addresses. These intermediate addresses are further translated into corresponding physical addresses in the second address translation stage. For the example with intermediate labels shown in Figure 11, the first address space is the intermediate address space 46, the second address space is the physical address space 52, the first address of data positioning is the intermediate address IPA1 generated in stage 1 translation corresponding to the virtual address of data positioning, and the second addresses of separate data positioning and label positioning generated in stage 2 translation are the physical addresses PA1 and PA2 used to identify the data in memory and allocate the corresponding storage location of the label.

Some examples support at least one virtualization tag translation mode, such as the virtualization tag mode shown in Figure 10 and/or the intermediate tag mode shown in Figure 11. Some examples support both virtualization tags and intermediate tags, allowing selection of which mode to apply, for example, based on a control state set by software. The advantage of supporting at least one virtualization tag translation mode is that it eliminates the need for a mechanism to be implemented in physical memory for managing the storage of allocation tags 72. This simplifies the memory system implementation.

Even though the memory system does support mechanisms for managing the storage of allocation tags 72, using address translation functionality to identify the tag storage location for certain data items can help enable more efficient use of available physical memory storage capacity. Software that sets up address translation tables may be better able to know whether a particular data item block might require tag checking, and thus can avoid setting up translation table entries that map allocation tags to physical memory for data item address areas that are unlikely to require tag access. Therefore, unlike physical memory systems, which may conservatively require the assumption that any data item might need physical storage for a corresponding tag, or may have been statically defined as reserving a block of physical storage for the allocation tag, the software that manages address translation mappings has more visibility into which allocation tags will be needed and which are unlikely to be accessed. Thus, the software can identify which allocation tags should be allocated to physical storage based on the corresponding valid translation table entries, and which allocation tags may only be nominally associated with the corresponding data items but are not allocated to physical memory for a given time (e.g., using a page mechanism to page in/out external storage, so that allocation tags are allocated to physical memory only when actually needed/when actually needed, to make more efficient use of the limited memory capacity of the physical memory system). Furthermore, the software can select address mappings such that, during the given address translation phase from the first address space to the second address space, in cases where two or more data item blocks will share the same allocation tag value, the translated entries accessed for tag address translation of two or more different data item blocks can map the corresponding tag address to the same second address in the second address space. This means that less physical memory needs to be allocated for tag storage. Since multiple data item blocks can share the same tag storage location in physical memory, separate physical storage in memory will be allocated for each different data item "granule" (where "granule" is a data item block that shares a single allocation tag). This is because, compared to the method where tags/data share the same physical address and the memory system cannot benefit from any software-provided hints about whether tags for different physical data address blocks have the same allocation tag value, multiple data item blocks can share the same tag storage location in physical memory.

It is possible to provide an MMU 6 that only supports virtualized label translation modes (e.g., one or both of the virtual/intermediate label modes shown in Figures 10 and 11), but not physical labels as shown in Figure 9. However, other implementations may also support the option of using physical labels, as shown in Figure 9. Supporting flexibility to change the method used can be useful, since the memory system does support an implementation that locates the assigned label associated with a given data item based on the same physical address used to identify the data item and the label. This can simplify the software implementation by reducing the management burden of separately managing separate translation table mappings for data and labels. Therefore, for a given address translation stage from the first address space to the second address space, MMU 6 can choose between a first label translation mode and a second label translation mode. In the first label translation mode, any translation performed for a label access simply reuses the same translation as the corresponding data item access. In the second label translation mode, the translation performed for a label access involves separate label address translation operations, which are separate from the data address translation operations. The label address translation operations and the data address translation operations use different translation table entries to provide address mapping for the given address translation stage. For the example in Figure 10, stage 1 translation uses the second label translation mode, and stage 2 translation uses the first label translation mode. For the example in Figure 11, stage 1 translation uses the first label translation mode, and stage 2 translation uses the second label translation mode. For the example in Figure 9, both stage 1 and stage 2 translations use the first label translation mode. The first label translation mode can be viewed as translating a given input address based on a data location address translation operation, and the second label translation mode can be viewed as translating a given input address based on a label location address translation operation. The selection between the first and second label translation modes can be based on control information set by the software, such as configuration values in the control register.

When virtualized tag translation mode is supported, the tag location address translation operation to obtain the physical address PA2 of the assigned tag requires separate translation table entries compared to the data location address translation operation used to obtain the physical address PA1 of the corresponding data item. Using the virtual tagging method shown in Figure 10, both stages 1 and 2 can use tag translation table entries created to translate the modified VA to IPA2 and IPA2 to PA2, which are separate from the entries for translating VA to IPA1 and IPA1 to PA1. Using the intermediate labeling method shown in Figure 11, stage 2 can use separate translation table entries to translate IPA2 into PA2 for label access, separate from the entries used to translate IPA1 into PA1 for data access. Therefore, performing label-based address translation may carry the risk of additional errors that would not occur with non-label-based data access checks. Memory errors may occur, causing processing interruptions, if the operating system or hypervisor has not configured appropriate translation table entries for label-based address translation, or if the translation table entries accessed in label-based address translation have insufficient memory access permissions. In order to reduce performance costs, it may be undesirable to increase the risk of errors associated with performing tag-based address translation by accessing memory areas that do not require tag checking.

To address this issue, translation tables can define attribute information, directly or indirectly encoded in attribute/authorization information within translation table entries 60 that provide address space regions for given data items. This attribute information indicates whether the region is a tagged region (where access to the region should be considered a tagged memory access requiring tag checking) or an untagged region (where tag checking is not required). In some instances, dedicated attribute types can indicate whether the region is tagged or untagged. However, it is also possible to infer the tagged/untagged status from one or more other attribute types. For example, attribute information can indicate whether the region is a normal memory type or a device memory type (device memory types are subject to additional restrictions that prevent memory access operations to device memory regions from being repeated more than once, interrupted after partial operation and then restarted, and/or reordered compared to the order in which memory access operations were requested, while normal memory types are not subject to any of these restrictions). Furthermore, attribute information can indicate caching capability attribute information, which indicates whether data from the corresponding address space region should be cached in cache memory once accessed from main memory. For example, caching property information can indicate whether a region is a write-back cacheable region (allowing cached memory to store dirty data that has been updated but not yet written back to memory), a write-through cacheable region (where any update to cached data is immediately propagated to memory's backup storage), or a non-cacheable region (where data should not be cached in any cached memory). In some instances, a region's tagged status can be determined when its property information indicates that the region is a normal write-back cacheable memory region. Any region with property information indicating that it is not a normal write-back cacheable region can be considered untagged.

Therefore, based on the attribute information associated with the address space page containing the accessed data item, MMU 6 can determine whether a label-location address translation needs to be performed on the architecture to obtain the label-location entity address of the associated allocation label. If the memory access instruction targets an unlabeled region of memory, then a label-location address translation is not performed on the architecture. For example, either no label-location address translation is performed at all, or any architectural effects of the translation are performed but suppressed—the system's architectural state remains the same as if the translation had never been performed. For example, if translation is suppressed at the architectural level (but not necessarily in practice), errors may not be triggered based on translation, performance counters visible to the architecture may not be updated based on translation, and memory access may not be triggered based on addresses obtained from tag-located address translations.

Figure 12 is a flowchart illustrating how to enable/disable tag location address translation based on memory region attribute information associated with the address of the data item to be accessed.

In step 1200, a tag-checked memory access instruction for a specified target data address is detected. The tag-checked memory access instruction can be any instruction that requests a read or write access to a target data item identified by the target data address, and at least when the target data address corresponds to a tagged memory region for the memory attribute information specified by the data item identified by the target data address, the instruction causes the tag checking circuit system 34 to perform a tag check between the address tag associated with the address operand used to complete the address operation of the target data address and the allocation tag stored in the memory system associated with the target data item. In some instances, a dedicated category for tagged memory access instructions can be provided, separate from the category for untagged memory access instructions. This allows the steps in Figure 12 to be executed for tagged memory access instructions, rather than for untagged memory access instructions. In other instances, instruction encoding may not distinguish between tagged and untagged memory access instructions, and all memory access instructions that access data items may, in principle, function as tagged memory access instructions. However, whether a tag check is actually performed may depend on the memory attribute information described below. Furthermore, in some cases, whether a given memory access instruction is a tag-checked memory access instruction may depend on the mode indicator or other tag-check enable/disable control values, which can be used to control whether tag checking is enabled or disabled.

In step 1200, in response to a tag-checked memory access instruction, MMU 6 obtains the memory region attribute information specified by the translation table entry associated with the target data address. Memory access operations can be triggered by performing a table walk operation via table walk circuit system 12 to traverse the stage 1 and/or stage 2 translation table structures 44, 50 (tracing any pointer traces between multi-level tables in translation table structures 44, 50) and locate the page descriptor 60 corresponding to the target data address to obtain this type of attribute information. Alternatively, if the attribute information corresponding to the target data address is already cached in TLB 8, the memory region attribute specified by the translation table entry associated with the target data address can be obtained from TLB 8 instead of performing a table walkthrough.

In step 1202, MMU 6 determines which memory region type is specified by the memory region attribute associated with the target data address. If the target data address is located in an unlabeled memory region (e.g., any region other than a normal write-back cache region), then in step 1204, MMU 6 determines that label location address translation does not need to be performed on the architecture. Therefore, either the label-based address translation operation is not performed at all, or if it is performed speculatively, a memory error is not triggered based on the label-based address translation, even though the label-based address translation would lead to an error detection when performed on the architecture (e.g., an error detection might occur if there is no valid address translation entry defined for the mapping "Modified VA->IPA2" or "IPA2->PA2" shown in Figures 10 and 11 for the virtualization translation mode). Therefore, by suppressing errors in tag-based address translation when accessing unlabeled memory regions, the management burden on software developers is reduced. Since, when virtualization translation mode is in operation, it is not necessary to configure and map the address translation table entries for the corresponding data item addresses. The software only needs to configure and map the tag mapping translation table entries for the data addresses that actually require tag checking. For access to unlabeled memory regions, in step 1206, MMU 6 or the tag checking circuit system 34 determines that tag checking is not required.

If the target data address is determined to be in a tagged memory region (e.g., a normal write-back cacheable region), then in step 1208, MMU 6 determines whether virtualization tagging is currently enabled (e.g., one of the virtual and intermediate tagging methods shown in Figures 10 and 11). As further discussed below with reference to Figures 18 and 19, the tag translation control information VTE and IPMTE stored in the control register can be used to determine whether the virtualization tagging mode is active.

If virtualization tags are enabled and tagged memory regions are accessed, then in step 1210, MMU 6 performs a tag location address translation operation on the architecture to obtain the translated tag location entity address PA2, which identifies the location of the allocation tag of the data item identified by the target data address specified by the tag-checked memory access instruction. The steps used to perform the tag location address translation are described in more detail in the examples of Figures 14 to 17 and Figure 24 below. If any error is detected during the label location address translation operation, a communication memory error occurs, which may cause the current processing to be interrupted and cause processor 2 to switch to execute instructions from an error handler, which may investigate the error and determine how to continue (e.g., if such a mapping has not been provided before, the operating system or super manager responsible for detecting the error in the address translation phase is triggered to configure the translation table entries for the required address mapping).

If no memory error is detected during the label address translation operation, then in step 1212, the load/store unit 28 publishes a memory access request to the memory system, specifying the label physical address PA2 obtained by MMU 6 during the label address translation operation. The label access memory access request for PA2 requests access to the allocated label, which is separate from the data access memory access request for the specified physical address PA1, the latter of which is published to the memory system to request access to the corresponding data item. In step 1214, when the memory system returns the data word corresponding to the tag location entity address PA2, the load/store unit 28 or the tag checking circuit system 34 selects between the allocation tags contained in the returned data word (e.g., between two allocation tags in the example shown in FIG10) based on tag selection information determined by identifying the target data location address of the desired target data item. For example, the tag selection information may be half-byte selection information explained below with reference to FIG22 and FIG23. In step 1216, the tag checking circuit system 34 performs the tag checking operation of FIG8 using the assigned tag selected in step 1214 and the address tag 80 associated with the address operand of the memory access instruction (e.g., the address tag 80 can be extracted from the high-order bits of the address operand, as shown in FIG4).

On the other hand, if memory access is for data items in a tagged region of memory, but virtualization tags are currently disabled, then in step 1218, tag location address translation is not performed on the architecture. Since tag translation in this case is based on the entity tagging system shown in Figure 9, the allocation tag 72 associated with the target data item can therefore be located based on the same entity address PA1 as the data item itself. Both the allocation tag and the data item are associated with the same data location entity address PA1. In step 1220, if no data access has been published, a memory access request for the specified data location entity address is published to the memory system to request access to the allocation tag (and data item) associated with that address. When the allocation tag is returned from the memory system, a tag check is performed in step 1222 using the acquired allocation tag and the address tag associated with the address operation of the memory access instruction (as shown in Figure 8).

Figure 13 illustrates the steps of performing a tag-based address translation operation for a tag access instruction used to access one or more allocation tags corresponding to a specified data address. The tag access instruction can be a tag-check memory access instruction, which also triggers access to the corresponding data item (as in the example of Figure 12), or it can be a tag read/write instruction that requests read/write access to (multiple) allocation tags corresponding to a data item block at a specified data address, without accessing the corresponding data item. In this example, the allocated address translation stage (hereinafter referred to as stage n translation) from the first address space to the second address space involves selecting between a first tag translation mode and a second tag translation mode. When using a single-stage address translation system, stage n translation can be a single address translation stage used in that system (where the first address space is the virtual address space 40 and the second address space is the physical address space 52, and the single translation table stage directly maps the address from the virtual address space 40 to the physical address space 52). When using a two-stage address translation system, stage n translation can be stage 1 translation (where the first address space is the virtual address space 40 and the second address space is the intermediate address space 46, and the translated address mapping is determined based on stage 1 translation table 44) or stage 2 translation (where the first address space is the intermediate address space 46 and the second address space is the physical address space 52, and the translated address mapping is determined based on stage 2 translation table 50).

In step 1300, MMU 6 determines the tag location address translation to be performed to obtain the tag location entity address corresponding to the data address specified by the address operand of the tag access instruction. The data address can be specified as a virtual address in virtual address space 40.

In step 1302, the first address of the data location in the first address space 40, 46 is determined based on the data address specified by the tag access instruction. If the stage n translation is a translation in a single-stage translation system or a stage 1 translation in a two-stage translation system, then the first address of the data location can simply be the data address specified by the instruction. If the stage n translation is a stage 2 translation in a two-stage translation system, then the first address of the data location can be an intermediate address obtained by translating the data address VA in the stage 1 translation (e.g., IPA1 in Figure 11).

In step 1304, MMU 6 determines which label translation mode is the selected label translation mode to be used for stage n address translation from the first address space to the second address space. For example, the determination of the selected label translation mode may be based on label translation control information stored in control register 14, which is set by software to operate at least a certain privilege level (e.g., if stage n translation is a single-stage translation or a stage 1 translation in a two-stage architecture, it is an operating system level privilege, or if stage n translation is a stage 2 translation, it is a super administrator level privilege).

If MMU 6 determines that the first label translation mode (the translation mode that disables virtualized labels for stage n translation) has been selected, then in step 1306, MMU 6 obtains the second data location address. This second data location address identifies the position of the data item corresponding to the data address and its associated allocation label within the second address space. For example, the first data location address obtained in step 1302 can be used to look up TLB 8 and/or translation tables 44 and 50 to obtain the address mapping information used to translate the first data location address into the second data location address. In this case, both data translation and label translation are controlled based on the same translation table entry, which provides an address mapping from the first data location address (e.g., VA or IPA1) to the second data location address (e.g., IPA1 or PA1). In step 1308, MMU 6 determines the label location entity address based on the second data location address.

If MMU 6 determines that the second label translation mode (the translation mode for enabling virtualized labels for stage n translation) has been selected, then in step 1310, MMU 6 obtains the label-located second address (e.g., IPA2 or PA2), which identifies the location of the allocation label in the second address space, separate from the location of the data item identified by the data-located second address (e.g., IPA1 or PA1). Separate translation table entries are identified to the label-located second address mapping compared to the entries used to obtain the address mapping for the data-located second address. Two examples of how such separate translation table entries can be located are explained below with reference to Figures 14 through 17. In step 1312, MMU 6 determines the physical address of the tag location based on the second address of the tag location determined in step 1310.

In steps 1308 and 1312, if stage n translation is a translation in a single-stage translation system or a stage 2 translation in a two-stage translation system, then the tag-located entity address can be simply equivalent to the data location second address determined in steps 1306 or 1310, since the data location second address is already an entity address in the entity address space. If stage n translation is a stage 1 translation in a two-stage translation system, then the data location second address (also used as the tag location second address) can be further translated into the tag-located entity address, for example, based on a further stage 2 translation. When the first label translation mode is selected for stage 1 translation in a two-stage address translation system, in step 1308, either the first or second label translation mode can be used for stage 2 translation performed to obtain the tag-located entity address, depending on the configuration value selected for any mode specified for stage 2 translation. When the second label translation mode is used for stage 1 translation in a two-stage translation system, in step 1312, stage 2 translation can be performed based on the first label translation mode (to prevent uncertainties arising from using the second label translation mode for both stage 1 and stage 2 translations).

It will be understood that the steps shown in Figure 13 may not need to be performed each time a tag access instruction is executed. Although any translation stage required by the current translation system can be performed on the first access to a given address space region that does not have relevant information cached in TLB 8, for subsequent accesses to the same address space region, information cached in TLB 8 from the previously accessed address space region can be used to avoid the need to perform the full translation procedure again. For example, some TLB 8 may simply cache information defining the association between a given data address in the virtual address space and the corresponding tag location entity address (which has been previously determined according to the procedure defined in Figure 13) to avoid having to consider which tag translation mode is selected each time. Therefore, although MMU 6 may have a configuration that supports the operation shown in Figure 13 for tag access instructions, it is not always necessary to use that configuration for each tag access instruction. For example, the control information used to select which tag translation mode is selected can be checked in the page table walkthrough, but this control information may not be needed when the address of the tag access is hit in TLB 8.

Therefore, if the second label translation mode is selected for the given address translation stage, different translation table entries can be used to identify the second addresses in the translated second address space corresponding to the data item and the label, respectively. Figures 14 to 17 show two example techniques for identifying different translation table entries used to obtain the mappings for the data location second address and the label location second address.

As shown in Figure 14, one option is to provide different translation table base address registers to store the base addresses of the translation tables used for accessing data location address translation and label location address translation, respectively. This means that the same input address can be used to select the corresponding entry from two different translation table structures, one for data access and the other for label access, so that the same input address in the first address space can be mapped to two different addresses in the second address space. The software responsible for controlling the address translation stage can store the translation table entries required for each different translation table structure into memory and set the translation table base address registers to point to the respective translation table structures. From the hardware perspective of MMU 6, the translation procedure can be the same for both data and tag access. The difference lies in whether the translation is currently used for data access or to allocate tag access, and whether it is selected between the first translation table base address register and the second translation table base address register.

Therefore, as shown in Figure 14, for stage n translation from the first address space 90 (virtual or intermediate address space) to the second address space 92 (intermediate or physical address space), for the data location address translation operation, the given data location first address 94 in the first address space 90 is used to select the corresponding translation entry 98 from the stage n data translation table structure 96 used for data access. The stage n data translation table structure 96 is identified based on the first translation table base address TTBR_data stored in the first translation table base address register. Based on the access to the selected data address mapping translation table entry 98, the corresponding data location second address 104 in the second address space 92 is determined. Although Figure 14 shows for simplicity the mapping of the selected translation table entry 98 directly to the data location second address 104, it will be understood that the stage n data translation table structure 96 can typically be a multi-level table, and therefore the entry 98 selected based on the data location first address 94 can actually specify the table pointer that identifies further translation tables, and the data location second address 104 can be obtained from the translation table entries obtained after traversing one or more steps of such table pointers.

On the other hand, for the tag location address translation operation, the first data location address 94 is used to select the corresponding entry 102 from the stage n tag translation table structure 100, which is separate from the stage n data translation table structure 96. The stage n tag translation table structure 100 is identified based on the second translation table base address TTBR_tag, which is separate from the first translation table base address TTBR_data. The second translation table base address is stored in a second translation table base address register, which is separate from the first translation table base address register. Based on access to the selected label address mapping translation table entry 102 from the stage n label translation table structure, the corresponding label is located at the second address 106 in the second address space 92 (similarly, although a single level of table 100 for label translation is shown in Figure 14, it will be understood that some instances may traverse two or more levels of the translation table before obtaining the mapping of the label to the second address 106).

Therefore, in the example of Figure 14, no special "data-to-tag" address manipulation or transformation needs to be applied to the first address of the data location before performing a TLB or translation table lookup. The same first address of the data location is used as input to the TLB or translation table lookup procedure, but is used to select from different translation table structures accessed by different base addresses for data and tag access.

Figure 15 illustrates the steps for performing tag translation of tag access instructions based on the example in Figure 14. Steps 1500 to 1504 are the same as steps 1300 to 1304 in Figure 13.

If the first label translation mode is the translation mode selected for stage n translation, then in step 1506, MMU 6 obtains the stage n translation table entry 98 corresponding to the first address 94 of the data location from the data translation table structure 96 identified based on the data translation table base address TTBR_data. In step 1508, MMU 6 uses the address mapping information from the stage n translation table entry obtained in step 1506 to translate the first address 94 of the data location in the first address space 90 into the second address 104 of the data location in the second address space 92. Step 1510 for obtaining the label location entity address is the same as step 1308 in Figure 13.

If the second label translation mode is the translation mode selected for stage n translation, then in step 1512, MMU 6 obtains the stage n translation table entry 102 corresponding to the first address 94 of the data location from the label translation table structure 100 identified based on the base address TTBR_tag of the label translation table. In step 1514, MMU 6 uses the address mapping information from the stage n translation table entry obtained in step 1512 to translate the first address 94 of the data location in the first address space 90 into the second address 106 of the label location in the second address space 92. Step 1516 for obtaining the entity address of the label location is the same as step 1312 in Figure 13.

Figure 16 illustrates a second example of locating different translation table entries for the same address translation stage in both data access and tag access translation applications. In this example, the same translation table structure 112 (accessed via the base address TTBR shared between data and tag access) is used to provide address mapping for both data location address translation and tag location address translation. For the data location address translation of a given address translation stage (stage n) from the first address space 90 to the second address space 92, the data location first address 110 in the first address space 90 is used to look up the stage n translation table structure 112 to obtain the data mapping translation table entry 116, which is used to identify the data location second address 120 in the second address space 92. Similarly, although not shown in Figure 16 for simplicity, the information in the accessed data mapping translation table entry 116 selected based on the first address 110 of the data location may be used to traverse one or more further table-level table indicators before locating the mapping information of the second address 120 of the specified data location.

On the other hand, for tag location address translation, before looking up the shared translation table structure 112 shared with data location address translation, the tag location address determination circuit system 10 applies a transformation function to the first data location address 110 to obtain the first tag location address 108. Note that this transformation is within the same (first) address space 90 (different from the address translation stage from one address space to another). Examples of the transformation function will be described later with reference to Figures 22 and 23. The transformed label location first address 108 is used to look up TLB 8 or as input for a page table traversal procedure to traverse stage n translation table structure 112, such that the transformed label location second address 118 depends on the label mapping entry 114 of the stage n translation table structure, which may be different from the data mapping entry 116 used for data location address translation. Note that although Figure 16 shows different label mapping entries 114 and data mapping entries 116 separated in the first translation table level based on the first address 108 of the label location and the first address 110 of the data location, in the case where the stage n translation table structure 112 is implemented as a multi-level structure, where the different levels of the table are looked up based on different parts of the bits from the input addresses 108 and 110, in some cases, the same entry in the first-level translation table may be used for both label and data translation, and it may be an entry at a subsequent level of the translation table, which is selected differently for label and data translation, to ultimately provide second addresses 118 and 120 for different translations for allocating label and data items, respectively.

Figure 17 illustrates the steps for performing tag translation of tag access instructions based on the example in Figure 16. Steps 1700 to 1704 are the same as steps 1300 to 1304 in Figure 13.

If the first label translation mode is the translation mode selected for stage n translation, then in step 1706, MMU 6 uses the address mapping information from the stage n translation table entry 116 selected from the stage n translation table structure 112 based on the data location first address 110 to translate the data location first address 110 of the first address space 90 into the data location second address 120 of the second address space 92. Step 1708, which is used to obtain the label location entity address depending on the data location second address, is the same as step 1308 in Figure 13.

If the second label translation mode is the translation mode selected for stage n translation, then in step 1710, the label location address determination circuit system 10 obtains the label location first address 108 of the first address space 90 corresponding to the data location first address 110 of the first address space 90. For example, the transformation from the data location first address 110 to the label location first address 108 can be based on applying the offset selected based on the data location first address 110 to the label storage area base address that defines the location of the label storage address area within the first address space 90. In step 1712, MMU 6 uses address mapping information from stage n translation table entry 114 selected from stage n translation table structure 112 based on label-located first address 108 to translate the label-located first address 108 of the first address space 90 into the data-located second address 118 of the second address space 92. Step 1714 for obtaining the label-located entity address depending on the label-located second address is the same as step 1312 in Figure 13.

Figure 18 illustrates an example of a subset of control register states stored in register 14, which relate to the tag address location translation operation performed by MMU 6 and the tag data access check performed by tag data access check circuitry system 32. Register 14 includes a set of control registers separate from the general-purpose registers used to provide general-purpose operands for instructions, which define architectural states with specific meanings in the instruction set architecture. For example, control register states can be used to control the operating mode/state of processor 2. Control register states can affect how processor 2 processes instructions.

For example, the executing circuit system 16 may support processing instructions in multiple exception levels associated with different privilege levels. For instance, the supported exception levels may include exception levels EL0 to EL3, where EL0 is the lowest privilege and EL3 is the highest privilege. Exception level EL0 is used for application-level code, exception level EL1 for operating system-level code, exception level EL2 for super administrator-level code, and exception level EL3 for security monitoring code performing certain security management operations. It will be understood that this is only one example of a possible privilege scheme, and other examples may use different methods to specify different privilege levels available in different operating states, but subsequent examples refer to this particular scheme description.

In the register names shown in Figure 18, a register name with the suffix _ELy (where y = 1, 2, or 3) indicates that the lowest privilege exception level allowed to update the architecture state in that register is exception level ELy. Therefore, attempting to write to that register from a privilege exception level lower than ELy will result in a transmission error (for example, a register with the suffix _EL2 can be written from EL2 or EL3 instead of EL1). The registers displayed with the suffix _ELx are database registers, for which multiple versions of the registers corresponding to different exception levels can be provided (for example, one version _EL2 is associated with the super manager level exception level EL2, and another version _EL1 is associated with the operating system level exception level).

Therefore, in this example, the following set of control registers is provided, specifying the following control status information items: SCTLR2_ELx (System control register, partitioned to provide separate versions of registers for EL1, EL2, and EL3—which register is used at a given time depends on whether the current exception level is EL1, EL2, or EL3), specifying: • VTE: An instance of the first-stage label translation mode indicator, used to specify whether virtual labels should be enabled or disabled (using the second-stage label translation mode for stage 1 address translation). For example, VTE can be encoded as follows: ○ 0: Virtual label is disabled; ○ 1: Virtual label is enabled. (This encoding helps ensure backward compatibility with older codes that assume reserved bits in the SCTLR2 register, which has been reused to provide the VTE indicator, have a value of 0.) • nDGA: Tag data access check enable indicator, used to specify whether tag data access checks are enabled (described further below). For example, nDGA can be encoded as follows: ○ 0: Tag data access checks are enabled ○ 1: Tag data access checks are disabled (Implementing nDGA using negative encoding, where checks are disabled when nDGA is 1) can help with backward compatibility with legacy code that assumes reserved bits in the register SCTLR2, which has been reused to provide the nDGA indicator, will have a value of 0, thus assuming that enabling tag data access checks might be safer, unless the software aware of the tag data access checks has explicitly opted to disable them by setting nDGA to 1.)

TCR2_ELx (Translation Control Register, which is partitioned to provide separate versions associated with exception levels EL1, EL2, and EL3 depending on the current exception level) specifies several tag table base address information VTB, VTB0, VTB1, and VGB used to define the base address of the tag region in the address space for the translation from the first address of the data location 110 to the first address of the tag location 108, as shown in Figure 16. The VGB item is only provided in the TCR2_EL2 version associated with EL2 and is not provided for EL1 or EL3. Which label table base address information is used for a given translation operation depends on the translation system used and which address translation stage has enabled the second label translation mode: • For stage 2 translation, if intermediate labels are enabled (stage 2 translation is performed using the second label translation mode), the label table base address is determined by VGB in register TCR2_EL2; • For Stage 1 translation in a translation system that supports a single translatable address region (see Figure 20 below for a more detailed description of translatable address regions), if virtual tags are enabled (Stage 1 translation using the second tag translation mode), the tag table base address is determined by the VTB in register TCR2_ELx, where ELx is the current exception level; and • For Stage 1 translation in a translation system that supports two translatable address regions (again, see Figure 20 discussed below), if virtual tags are enabled, the base address of the tag table is determined by either VTB0 or VTB1 in register TCR2_ELx, where ELx is the current exception level. If the most significant bit of the first address of the data location is 0 (i.e., the address is in translatable region 0), VTB0 is used; and if the most significant bit of the first address of the data location is 1 (i.e., the address is in translatable region 1), VTB1 is used.

Regardless of which label table base address information VTB, VTB0, VTB1, or VGB is used, the label table base address can be encoded so that the label table base address information only specifies a few high bits of the corresponding base address (so that the lower significant bits that are implicitly set to 0 for the corresponding base address can be omitted from the stored register state).

HCR2_EL2 (or alternatively, VTCR_EL2): A register used to store supermanager control information (or information set by the supermanager for controlling address translation virtualization). HCR2_EL2 or VTCR_EL2 specifies the second-stage label translation control indicator IPMTE, which indicates whether the intermediate label is enabled or disabled (stage 2 translation is performed using the second label translation mode). IPMTE has the following codes: ○ 0: Intermediate label is disabled; ○ 1: Intermediate label is enabled. (Similarly, this coding can help with backward compatibility, as older codes can be assumed to be reused to provide reserved bits for IPMTE control that can have a value of 0).

TCR1_ELx (Translation Control Register, partitioned to provide separate versions for EL1, EL2, and EL3) – Another register provides translation control information associated with the exception level ELx. TCR1_ELx specifies information defining the size of each translatable address region: • T0SZ: Defines the size of a single translatable address region in a single-region translation system or the size of translatable address region 0 in a two-region translation system; • T1SZ: Defines the size of the second translatable address region 1 in a two-region translatable system.

For example, T0SZ and T1SZ can specify a value x such that the size of the corresponding translatable address region is 2 ^(64-x) bytes.

TTBR: Several translation table base address registers (TTBRs) are used to provide the base addresses of translation table structures. For data access, TTBRs can specify multiple translation table base address registers, including, for example: - TTBR0_ELx (separate versions of EL1, EL2, and EL3): The base address of the translation table to be used for data access in a single-area translation system or for data access in the translateable area 0 of a two-area translation system; - TTBR1_ELx (separate versions of EL1 and EL2): The base address of the translation table to be used for data access in the translateable area 1 of a two-area translation system.

For example, TTBR_data in Figure 14 and TTBR in Figure 16 may be based on an address specified by one of the following selected TTBR0_ELx and TTBR1_ELx: (i) the current exception level, and (ii) whether a single or dual translatable region translation system is in operation (other control states not shown in Figure 18 may specify which translation system is currently in operation). For label translation, if the method shown in Figure 16 is used, label translation uses the same translation table base address as the translation table base address used for data translation. However, if the method shown in Figure 14 is used, as indicated by the dashed lines in Figure 18, the TTBR may also include several further TTBRs to provide additional base addresses TTBR_tag for the tag translation table structure 100 corresponding to the data translation table structure 96 referenced by the corresponding TTBR used for data access. Thus, each TTBR may have two versions in this case: one for data access and one for tagging.

It will be understood that the specific control registers provided and the particular layout of the control states within those registers may vary significantly from one ISA to another. Therefore, the specific allocation of control state items to specific registers, or the characteristic of assigning a given group of control states to a single register or distributed across separate registers, is not particularly important and can be implemented in other ways. Similarly, it is not necessary to provide separate versions of the same registers associated with different exception levels, and other instances can provide a single version of each architectural state item (the software switches the state value when switching between one exception level and another). However, separate state items for different exception levels can be used to reduce the software's administrative burden when handling exceptions and returning from exceptions.

Nevertheless, for operations related to control and virtualization tag support, the following information is typically useful: - Tag translation control information (e.g., the first-stage tag translation mode indicator VTE and the second-stage tag translation mode indicator IPMTE), which controls whether the first or second tag translation mode is used to perform tag address translation during the given address translation stage; - Tag data access check enable information (e.g., nDGA), which controls whether tag data access checks are enabled or disabled; - Information used to define the location and size of the allocation tag storage area in the first address space 90 is useful for tag translation involving address transformation applied to data location first address 110 to generate tag location first address 108, as shown in Figure 16, and is useful in determining whether data access has been specified in the address within the tag storage area of the first address space during tag data access checks; and/or - In instances where tag translation uses a separate set of translation tables from the translation tables used for data translation (as shown in Figure 14), those translation table structures have one or more additional base addresses to be used for tag translation.

This information may be provided in a different format than that shown in Figure 18, but for the sake of example, the following description refers to the specific indicator shown in Figure 18.

Figure 19 illustrates the control used in a two-stage address translation system to determine whether to perform a label address translation operation (corresponding to the second label translation mode mentioned above) or a data address translation operation (corresponding to the first label translation mode) to obtain the operation of locating a second address for the label in the address translation stage when a translation operation is pending to be performed to obtain the address of (multiple) allocation labels to be accessed by a label access instruction. Figure 19 shows this determination for both stage 1 and stage 2 address translations.

In step 1900, MMU 6 determines which type of instruction to execute to cause a tag-location address translation. For example, the tag access instruction being executed could be: - A tag-check memory access instruction that identifies the target data address of a given data item and requests a read/write memory access to the given data item itself. It also requests (if the target data address corresponds to a tagged memory region, as discussed in Figure 12) to perform a tag check using the corresponding allocation tag stored in the memory system and the address tag associated with the instruction's address operands; - Non-subject tag read/write instructions specify the target data address that identifies a block of one or more data items of a specific size (a single tag grain or data items corresponding to multiple tag grains), but do not require access to the data items themselves. Instead, they request read/write operations to be performed at (multiple) locations of (multiple) allocation tags corresponding to those data items. These instructions can be used to set tag values when allocating or deallocating memory regions, as shown in Figure 5. Non-subject tag read/write instructions indirectly specify the addresses of (multiple) tags to be read or written by specifying the corresponding data item addresses. In the example of Figure 16, for instance, a non-subject tag read/write instruction can specify the virtual address corresponding to the first data location address 110 in the first address space 90 as its target data address, but may result in memory access being performed at the physical address corresponding to the second tag location address 118 instead of the physical address corresponding to the second data location address 120. - Subject tag read/write instructions, which are a special type of tag read/write instruction, directly specify the address of the tag itself, rather than indirectly specifying the tag's location by specifying the address of the corresponding data item. For example, referring to Figure 16, the subject tag read/write instruction can specify the virtual address corresponding to the first address 108 of the tag location as its target address (for example, if the address translation stage shown in Figure 16 is stage 1, then the address operand of the subject tag read/write instruction specifies the first address 108 of the tag location as the virtual address, or if the stage shown in Figure 16 is stage 2, then the first address 108 of the tag location is the result of the translation of the virtual address specified by the instruction in stage 1). The first address of the label location, 108, is translated as if it were a data address, which then results in a read/write access to the physical address of the second address of the label location, 118, corresponding to the label mapping entry 114 translated based on stage n translation. Providing such main label read/write instructions that directly specify the label address instead of indirectly specifying it via a data address can be useful, simplifying the super manager's management of the stage 1 translation table for the client operating system.

If the current instruction requiring tag-based address translation is an instruction that specifies the tag location by specifying a data address (e.g., a tag-check memory access instruction or a non-subject tag read/write instruction), then in step 1902 of Figure 19, MMU 6 determines that the first-stage tag translation mode indicator VTE corresponding to the current translation system indicates that virtual tags are enabled for stage 1 address translation (e.g., if multiple library versions of VTE with different exception levels are supported, then VTE can be read from the version SCTLR2_ELx associated with the register associated with the current exception level ELx). If virtual tags are enabled for Stage 1 translation of the current translation system, then in step 1904, MMU 6 applies a tag address translation operation (e.g., according to the second tag translation mode shown in Figures 13, 15, or 17) to the Stage 1 translation of the data address specified by the tag access instruction. In step 1906, Stage 2 translation is then performed according to the data address translation operation (e.g., according to the first tag translation mode shown in Figures 13, 15, or 17). The combination of steps 1904 and 1906 means that the overall two-stage address translation is generally performed in the virtual tagging method shown in Figure 10. The stage 1 translation maps the virtual data address to the separate data and tag addresses in the intermediate address space. These addresses can then be further translated into separate physical addresses in the stage 2 translation.

If the first-stage label translation mode indicator indicates that virtual labels are disabled for stage 1 translation (N in step 1902), or if the instruction executed to cause label access is a subject label read/write instruction specifying a label address (not a data address), then in step 1908, a data address translation operation (i.e., the first label translation mode shown in Figures 13, 15, or 17) is applied to the stage 1 address translation, thus disabling virtual labels for stage 1. In step 1910, MMU 6 determines whether the second-stage label translation mode indicator IPMTE stored in the control register HCR2_EL2 or VTCR_EL2 corresponding to the current translation system indicates that the intermediate label is enabled. If enabled, in step 1912, MMU 6 applies a label address translation operation (the second label translation mode shown in Figures 13, 15, or 17) when performing stage 2 translation from the intermediate address space to the physical address space, and thus applies intermediate labels, as shown in Figure 11, where stage 1 translation translates data and label access together from the virtual address space to the intermediate address space, but maps the given intermediate address IPA1 that identifies the location of data in the intermediate address space to the label location entity PA2 that identifies the assigned label location, which is separate from the physical address PA1 that identifies the corresponding data item.

On the other hand, if the second-stage label translation mode indicator checked in step 1910 identifies that intermediate labels are disabled in stage 2, then the data address translation operation (first label translation mode) is also applied to stage 2 in step 1906. Therefore, in this case, the combination of steps 1908 and 1906 will be that both stages 1 and 2 use the data address translation operation (first label translation mode), and thus the entity labeling method will be used, as shown in Figure 9, in which the two types of data and their associated allocation labels use the same entity address for identification, and the memory system is left to locate the storage location of the label based on the data location entity address.

As described above with respect to Figure 16, some embodiments of the tag location address translation operation (second tag translation mode) may include the following steps: The tag location address determination circuit system 10 determines the tag location first address 108 in the first address space 90 based on the data location first address 110 that identifies the location of a given data item in the first address space 90, and then applies a given address translation stage to translate the tag location first address 108 into the tag location second address 118 in the second address space 92. Any mapping function can be used to derive the tag location first address 108 from the data location first address 110. For example, a data-to-tag address mapping table can be maintained in memory by software to specify the mapping between the data location first address 110 and the corresponding tag location first address 108. For example, a further base address register can be provided in the ISA's control register to store the base address used to access the data to the tag address mapping table. This method provides greater flexibility in storing the location specified by the tag in the first address space 90, but may increase the management burden of software setting the data to tag address mapping and the management burden of hardware, resulting in additional latency in accessing the data to the tag address mapping table. Another method could be that each data location's first address has a one-to-one fixed mapping with the corresponding tag location's first address (with a fixed mapping function that restricts the mapping, such as each tag location's first address and the corresponding data location's first address having a certain offset). However, in cases where the software cannot change the mapping between the first address 110 of the data location and the first address 108 of the label location, this may unacceptably limit where data items can be placed within the first address space 90, leading to a greater burden when adjusting address space areas used by the data for other purposes.

Figures 20 to 23 illustrate a method for performing a tag location address determination operation that balances the flexibility of software changes in allocating addresses in the first address space 90 for storing allocated tags with a simpler and more efficient operation performed in hardware.

As shown in Figure 20, a given translation system can restrict valid data addresses to one of a finite number of translatable address regions. Figure 20 shows an example with a single translatable address region (left side of Figure 20) and an example with two translatable address regions (right side of Figure 20). Attempting to access data using an address in a non-translatable address region (other than any of the translatable address regions) can result in a transmission memory error. This approach can be useful because, although address operands in a 64-bit instruction set architecture can theoretically address 2 ^{^64} different bytes of address space, current usage requirements do not necessitate that much addressable memory capacity, and therefore a smaller number of bits may be sufficient to support the required number of addressable locations. For example, the size of a translatable region might be limited to an address space of 2 ^{^48} , 2 ^{^53} , or 2 ^{^56} bytes, choosing some arbitrary examples. This has several advantages by leaving some non-translatable regions that do not support any valid addresses specified in those regions. First, this means that the software assuming address translation mappings does not need to provide any valid address mappings corresponding to the non-translatable regions, thus reducing the burden of maintaining the translation table structure. Furthermore, some unused bits are placed at the top of larger (e.g., 64-bit) address operands to leave some space for encoding other information in the address operand, such as the address label 80 shown in Figure 4.

As shown in the example on the left of Figure 20, for a translation system that uses a single translatable region 200 for the first address space 90, that region can cover an address space of ^2t bytes, extending from address 0 to address ^2t -1, where t is the size of the translatable region determined according to the region size indicator value TOSZ in the register TCR1_ELx as described above (again, the TOSZ parameter may have more than one version corresponding to different exception levels, where the specific region size of the current translation system depends on the current exception level).

To accommodate the label location addresses used to locate allocation tags within the first address space, a label table address region 202 is defined within the translatable address region 200. The size of the label table address region 202 scales with the size of the translatable region 200, depending on the comparison between the size of the allocation tag and the size of the corresponding data block associated with that allocation tag. Typically, if 2 ^{^n} bytes of data items share one or more allocation tags stored in a single-byte address space, the label table address region is 1/2 ^{^n} times the size of the translatable region 200. For example, if allocation tags are assigned to each 16-byte data block, and two 4-bit allocation tags fit into a byte address space, then 32 bytes of data share a byte allocation tag, so n=5. This means that the size of the label table address region 202 will be 1/ ^32th the size of the translation region 200. To support efficient label address determination operations, the simplest approach is to align the address boundary of the label table base address that identifies the starting label table address region with the boundary at the interval between the label table address regions (i.e., interval 2 ^(tn) , where ^2t is the size of the translatable address region and ²ⁿ is the ratio between the label table address region size and the translatable address region size). This means that there are up to 2 ^{^n} distinct alignment locations within the translatable region 200 for the label table address region 202. Therefore, the location of the label table address region 202 can be represented by n-bit label table base address values VTB and VGB, as shown in Figure 18. In the example of Figure 22, n=5. By using the aligned label table base address, operations combining base addresses and offsets do not require addition, but can be performed simply by concatenating the base address and offset. This is much faster and consumes less power for the hardware than addition.

As shown in the example on the right side of Figure 20, for a translation system using two translatable address regions 206 and 204, there exists a lower translatable region (region 0) 206 of size 2 ^t0 , where t0 is the region size of translatable region 0, defined using the region size indicator value T0SZ in the register TCR1_ELx selected based on the current exception level ELx. Transducible region 0 (206) extends from address 0 to address 2 ^t0 -1, and in the address space of 64 bits [63:0], bits [63:t0] are restricted to all 0s for valid addresses in translatable region 206. There is also an upper translatable region (region 1) 204 of size 2 ^t1 , where t1 is the region size of translatable region 1, defined by the region size indicator value T1SZ in the register TCR1_ELx selected based on the current exception level ELx. Transducible region 1 (204) extends from address 2 ⁶⁴ -2 ^t1 to address 2 ⁶⁴ -1, and in the address with 64 bits [63:0], bits [63:t1] are restricted to all 1s for valid addresses in translatable region 206. This leaves a large, non-transferable address region extending from address 2 ^t0 to address 2 ⁶⁴ -2 ^t1 -1 as a coding space for other purposes, including support for defining address labels 80, which have values other than all 0s or all 1s in the high bits [63:t0] of the valid address in one of the transferable address regions 206, 204. The transferable region sizes t0, t1 can be different from each other—for example, the upper transferable region 204 can be smaller or larger than the lower transferable region 206. Support for two translatable regions can help isolate data in the core region of the address space used by the operating system (which can use the upper translatable region 204) from data in the user region of the address space used by the application code (which can use the lower translatable region 206). This makes it less likely that address pointers calculated by the user code will accidentally point to a location in the core region of address space 204.

When two translatable address regions 204 and 206 are supported, each of these regions may have its own corresponding label table address regions 208 and 210, which are designated with allocation tags for storing the corresponding data items in the translatable address regions 204 and 206. As is generally the case with a single translatable region, the ratio between the size of the given translatable regions 204 and 206 and the size of the corresponding label table address regions 208 and 210 may be fixed, depending on the size of the allocation tags and the number of bytes of data sharing a single allocation tag, and therefore the size of the label table address regions 208 and 210 is scaled according to the size of the corresponding translatable address regions 204 and 206 as defined by T0SZ or T1SZ. The location of label table address regions 208 and 210 within the given translatable address regions 204 and 206 depends on the label table base address information VTB1 (for translatable region 1, 204) or VTB0 (for translatable region 0, 206) stored in register TCR2_ELx for the corresponding entry of the current exception level ELx. The label table base addresses VTB0 and VTB1 are defined independently for the two translatable regions 204 and 206; therefore, the relative positions of the label table address regions within the translatable regions can be different for the two translatable regions 204 and 206.

Figure 21 illustrates an example of a tag location address determination circuit system 10 performing a tag location address determination operation for a tag access instruction that requires a tag location address translation operation. The tag location address determination operation acts on the first address 110 of a given data location, which is equal to or depends on the virtual address specified by the tag access instruction (e.g., already obtained in a previous stage of address translation applied to that virtual address).

In step 2100, based on the execution of the tag access instruction, it is determined that tag access is required. In response, in step 2102, MMU 6 determines whether the virtualized tag translation mode (e.g., the second tag translation mode mentioned above) is currently enabled (e.g., based on the control state VTE or IPMTE associated with the current address translation phase of the current translation system). If the virtualized tag translation mode is currently disabled for the current address translation phase, it is not necessary to map the data location address to the tag location address in the first address space, and therefore in step 2110, the address of the tag in the second address space 92 is executed based on the translated data location first address 110. If virtualized label translation is enabled for the current address translation stage, in step 2104, MMU 6 determines whether the first address 110 of the data location is a valid address within any of the translatable address regions 200, 204, and 206 supported by the current translation system. If not, an error is sent in step 2106 to prevent uncertain results caused by triggering label access corresponding to an untranslatable address. If the first address of the data location 110 is located in the translatable address regions 200, 204, and 206, then in step 2108, the first address of the label location 108 is determined by applying the offset determined based on the predetermined portion of the first address of the data location to the label table base address represented by the label table base address information VTB, VTB0, VTB1, and VGB. For single-transferable area stage 1 translation, the label table base address is determined based on VTB. For stage 2 translation, the label table base address is determined based on VGB. For dual-transferable area stage 1 translation where the data location address is located in translatable area 0 (206), the label table base address is determined based on VTB0. For dual-transferable area stage 1 translation where the data location address is located in translatable area 1 (204), the label table base address is determined based on VTB1. Furthermore, in step 2108, the tag location address determination circuit system 10 identifies half-byte selection information based on one or more bits of the first address 110 of the data location (which is less significant (but adjacent) compared to the portion used to derive the offset), which can be used to select among two or more allocation tags in the address space of the same byte.

Figure 22 illustrates the label location address determination operation in step 2108 for a single-area translation system (for stage 1 or stage 2 translation). Here, ^2t is the configurable translation area size defined by TOSZ, and this example assumes that the label table base address "table base" is defined by the 5-bit field VTB (for stage 1) or VGB (for stage 2) in the system register, and therefore this example assumes that the ratio between the translation area size and the label table area size is 32 (2 ⁵ ). For ease of explanation, Figure 22 is shown as being applied to the virtual address as the first address 110 of the data location, but the same operation can be performed on the translation of stage 2, where the first address 110 of the data location will be the intermediate address, and the label location address determination operation can be the same as in stage 1, except that a different label table base address value VGB is used instead of VTB (and in some instances, different size parameters of the size ^2t of the translatable address region of Figure 22 are defined).

As shown in Figure 22, for a single translatable region of size ^2t , the first address 110 of the data location can be considered as including meaningful address bits [t-1:0] equal to the address value given, and high bits [55:t] that are restricted to 0 for the valid address (this example assumes that there are no meaningful bits above bit [55], since bits before bit [56] may be reserved for other purposes, such as storing address tags 80).

As shown in the portion marked 110' in Figure 22, for the purpose of generating the first address 108 of the tag location, the same address 110 can be interpreted as containing a tag index value at bits [t-1:5], which represents an offset relative to the base address of the tag table (this offset is an indication of which specific address within the tag table address region 202 should be the first address 108 of the tag location for this particular access). The offset-corresponding address portion identifies which of several different tag granules the address 110 falls into, where the tag granules are address space blocks in which all addresses share the same allocation tag 72 stored in the memory system.

Therefore, when the corresponding tag location first address 108 is generated, the location bits [t-6:0] are set based on the tag index values in bits [t-1:5] of the data location first address 110. In fact, an arithmetic right shift (5 bits in this example) is performed, although no shift logic is actually needed, since the tag location first address 108 can be formed simply by concatenating the bit values in the appropriate bit locations. The bits [t-1:t-5] of the tag location first address 108 are set to the corresponding bits of the 5-bit table base address identifier VTB (for stage 1) or VGB (for stage 2). Therefore, by defining the base address as an address naturally aligned to the ^2t address boundary, this eliminates any need to add an offset ("tag index") to the base address when calculating the first address 108 of the tag location. The high bits [55:t] in the first address 108 of the tag location are kept all 0, so that the tag table is entirely within the translatable address region 200.

The generated nibble selection information 220 is equal to the bit of the first address 110 of the data location [4]. This reflects that, in this particular example, as shown in Figure 10, using 4-bit labels and 8-bit addressable locations, each byte addressable location stores two labels, requiring only a single state bit to select which of the two allocation labels returned from the given byte memory is associated with the data item identified by the first address 110 of the data location. However, other examples may have a different number of allocation labels in each byte of the label address storage area, and therefore if there are more than two allocation labels in each byte, more than one nibble selection bit can be used, which will be the next least significant bit after the least significant bit of the label index (offset).

Figure 23 illustrates a similar operation of Phase 1 translation performed in a translation system with two translatable address regions 204 and 206. The principle is the same as in Figure 22, where the tag location first address 108 is determined as an offset relative to the base address, the amount of which is determined by bits [t-1:5] of the data location first address 110. However, in Figure 23, the translatable region size t and the tag table base address ("table base [s]") depend on whether the data location first address 110 is located in the upper translatable address region 204 or the lower translatable address region 206. If the first address of data location 110 has a most significant bit equal to s=0 [55], then address 110 is located in the lower translatable address area 206, the size of the translatable area t=t0 is determined by the control state T0SZ, and the base address of the label table (the value specified in the bits [t0-1:t0-5] of the first address of label location 108) is determined by VTB0. If the first address of data location 110 has a most significant bit equal to s=1 [55], then address 110 is located in the upper translatable address area 204, the size of the translatable area t=t1 is determined by the control state T1SZ, and the base address of the label table (the value specified in the bits [t1-1:t1-5] of the first address of label location 108) is determined by VTB1. In addition to considering whether the high bit[55] is 0 or 1 to take into account different area sizes and the base address of the label table, the first address 108 of the label location and the half-byte selection information 220 are determined in a manner similar to that in Figure 22.

Although the examples in Figures 22 and 23 are based on a fixed ratio of 1/32 between the size of the label table address regions 202, 208, and 210 and the corresponding sizes of the translatable address regions 200, 204, and 206, and therefore based on a fixed 5-bit size of the label table base address value injected at bits [t-1:t-5] of the first address 108 of the label location, other examples may support variable allocation of label sizes or variable sizes of data item granules sharing a single allocation label. In this case, the bit positions marking the boundaries of the table base address and the label table index shown in Figures 22 and 23 can vary.

In the example supporting both Stage 1 and Stage 2 translation of label location address determination, the same hardware can be shared between the two address translation stages. Since the mapping function remains the same regardless of which stage of address translation the label location address determination is applied to, except for using different values for the translatable region size t and the table-based address "table-based". Therefore, the label location address determination circuit system 10 can be shared among several different translation systems.

Figure 24 is a flowchart illustrating a specific example of the steps for implementing label address translation when supporting a variable label translation mode (enabling/disabling virtualized labels in the first address translation stage and the second address translation stage). It will be understood that Figure 24 is a specific implementation of some of the features described more generally above, and therefore other ways of implementing similar functionality exist.

In step 2400, a tag access instruction is executed. A tag access instruction can be any instruction that can (at least for some settings of control status information and/or memory attribute information in the translation table address) trigger an operation using one or more allocation tags stored in memory. The tag access instruction specifies the target address.

In step 2402, MMU 6 determines whether stage 1 address translation is currently enabled. There may be address translation systems where stage 1 translation is disabled and only stage 2 translation is used to translate intermediate addresses specified by operands using tag access instructions into physical addresses (as described below, there may also be systems that disable stage 2 translation, allowing only stage 1 to be used, or for certain most secure codes operating at supermanager exception levels or higher privilege exception levels, allowing the code to directly specify physical addresses without any address translation stage). For example, control status (limited to software updates that can be performed by software with super-manager level privileges or higher) can be used to indicate whether stage 1 translation and/or stage 2 translation are currently enabled.

If it is determined that Phase 1 address translation will be enabled, then in step 2404, MMU 6 determines whether to enable virtual tags (referred to as VMTE for simplicity) for Phase 1 translation (for example, this can be determined based on the Phase 1 tag translation control indicator VTE mentioned above). Furthermore, MMU 6 determines whether the current tag access instruction is a body tag read/write instruction. If virtual tags are currently disabled or the current tag access instruction is a body tag read/write instruction, then no special tag address translation operation different from the data address translation operation of Phase 1 translation is required. Conversely, in step 2406, a data address translation operation is applied to stage 1 to translate the virtual address (data location first address VA) designated as the target address of the tag access instruction into the corresponding data location intermediate address in intermediate address space 46. This data address translation operation is the same as the operation performed to locate the intermediate address corresponding to the data item (multiple) to be allocated tags.

In addition to obtaining the intermediate address of the data location, the Stage 1 address translation also identifies memory attribute information directly or indirectly defined using page descriptor 60 from the Stage 1 address translation table. This provides an indication of whether the memory region associated with the first address of the data location is located in a tagged or untagged region of memory as described above. The tagged/untagged status can be inferred from other memory permission information, such as whether the address is located in a normal write-back cache region of the memory. In some implementations, further options may be supported for memory regions to be treated as "canonical tagged" regions. A "canonical tagged" region is one where, although no allocation tag for data items is explicitly stored in that address space region, a tag check can be performed in a dual-translatable region translation system. This assumes allocation tag 72 sets all bits to 0 to access addresses in lower translatable region 206 and sets all bits to 1 to access addresses in upper translatable region 204. This canonical tag can be used to match the expected value of the upper address bits in the addresses "canonically" set for lower/upper translatable regions 206 and 204, respectively. In some instances, specification label options can be separate attribute types, distinct from labeled and unlabeled memory regions. However, in other instances, the attribute information itself may only distinguish between labeled and unlabeled regions, where the control value stored in the control register indicates whether, in the current operating mode, an unlabeled memory region should be considered truly "unlabeled" (without any label value) or "with a specification label" (an implicit allocation label sets all bits to the most significant bit corresponding to the target address). If stage 1 translation is currently disabled in step 2402, stage 1 does not provide memory attribute information and is therefore accessible via default processing labels, just as stage 1 memory attribute information would specify labeled memory regions.

If the translation of step 1 is disabled in step 2402, steps 2404 and 2406 can be omitted, and the method will proceed directly to step 2408.

In step 2406, if Stage 1 translation is disabled or executed for a read/write instruction for the main label or for an access instruction for another label with a disabled virtual label, in step 2408, MMU 6 determines whether to enable Stage 2 translation.

If stage 2 translation is enabled, in step 2430, MMU 6 determines whether the memory region type determined from stage 1 is a tagged region (based on stage 1 memory attribute information, or if stage 1 translation is disabled, based on the default determination of the "tagged" region type) and whether to enable intermediate tags for stage 2 translation (for example, this can be determined based on the second stage tag translation control indicator IPMTE mentioned above).

If the memory region being accessed is not a labeled region or intermediate labels are disabled, then in step 2412, MMU 6 performs a Stage 2 address translation from the target intermediate address (or the target address of the label access instruction itself if Stage 1 translation is disabled, or the address obtained from Stage 1 translation in step 2406) to the corresponding physical address based on the corresponding entry in Stage 2 address translation table 50. In this case, since neither Stage 1 nor Stage 2 uses virtualization labeling methods (VMTE or IPMTE is enabled), the physical labeling method shown in Figure 9 is used.

If Stage 2 translation is disabled for the current translation system, steps 2430 and 2412 are omitted.

In steps 2414 and 2416, different results are possible depending on the type of memory region being accessed. If the type of memory region being accessed is a canonical address region (no in step 214, yes in step 2416), then in step 2418, the canonical tag value is returned by MMU 6 (based on the fact that if an address in the lower translatable address region 206 is accessed, the allocation tag bits are implicitly set to all 0s, and if an address in the upper translatable address region 204 is accessed, they are set to all 1s), without needing to send any explicit request to the memory system to obtain the canonical allocation tag value. On the other hand, if the region is unlabeled (both steps 2414 and 2416 are no), label access may not actually be performed because in step 2420, any read request for the allocated label returns the default value 0 (read as zero, RAZ) and any write request for the allocated label is ignored (write ignore, WI) without generating any error. However, if the access is identified as an address with a label (e.g., based on memory attributes associated with the first address of the data location), then in step 2422, a request is sent to the memory system specifying the data location entity address translated from stage 1 and/or stage 2 (or, if both stage 1 and stage 2 are disabled, based on the entity address specified by the label access instruction itself), and the request returns the allocation label corresponding to that address. Assuming no error occurs in the tag access request, in step 2424, the memory system returns a "physical tag" based on an implementation-specific mechanism implemented by the memory system according to the physical tagging method explained above with reference to Figure 9. If an error occurs in the tag access request specifying the data location of the physical address (e.g., the memory system cannot locate the allocation tag corresponding to this physical address), an error is transmitted in step 2426.

If in step 2430 it is determined that the target address of the tag access instruction corresponds to a tagged memory region and the intermediate tag is enabled using the IPMTE control described above, then in step 2432, the tag location address determination operation described in Figures 16 to 17 and Figures 20 to 23 is applied to transform the data location intermediate address obtained in step 1 translation 2406 (or directly specified by the tag access instruction if step 1 translation is disabled) into the corresponding tag location intermediate address, and then the tag location intermediate address is translated into the tag location physical address by performing step 2 address translation in step 2434.

In step 2436, additional checks are performed using the Stage 2 memory attribute information defined by the relevant Stage 2 translation table entries, which provide address mappings in the Stage 2 translations performed in step 2434, either directly or indirectly. Since the tag-location intermediate address has been modified relative to the corresponding data-location intermediate address, and may be associated with different Stage 2 memory attributes than the corresponding data-location intermediate address, additional checks are performed to determine whether the tag-location intermediate address corresponds to a "normal" address region. This avoids potential side effects from requesting allocation tag access to device-type memory regions. Therefore, if the Stage 2 attribute of the tag-located intermediate address specifies that this address is located in the normal area of memory, then in step 2438, a memory request specifying the tag-located physical address is sent to the memory system to request read/write access to (multiple) corresponding allocation tags. Since the physical memory system does not need to know about the supporting allocation tags (based on intermediate tags, as shown in Figure 11), the allocation tags(e) are implemented as virtualized tags. If the intermediate address of the memory attribute indicator tag in stage 2 corresponds to the device type memory area, then in step 2440, the tag access memory system request is not sent to the memory system to avoid side effects on the device memory area. In step 2440, if the tag access is a read operation, the tag access operation returns an allocated tag value of 0 (read is zero, RAZ), and if the tag access is a write operation, it is ignored (write ignore, WI).

Returning to step 2404, if it is determined that virtual tagging (VMTE) is enabled for stage 1 translation, then in step 2440, the tag location address determination operation is applied to the data location virtual address specified as the target address of the tag access instruction to obtain the corresponding tag location virtual address translated in stage 1 translation in step 2442. If stage 2 translation is enabled (yes in step 2444), then the stage 2 translation performed in step 2446 will further translate the tag location intermediate address generated by stage 1 translation into the tag location physical address. If Stage 2 translation is disabled (No in step 2444), step 2446 is omitted, and the result of Stage 1 translation is already the tag location entity address. In either case, in step 2448, any Stage 2 memory region attributes obtained in the Stage 2 translation are checked in a manner similar to the checks described in step 2436. If the Stage 2 attribute indicates that the tag location intermediate address is located in the device memory region (No in step 2448), then the tag read/write request is treated as RAZ/WI; otherwise, if the tag location intermediate address is located in normal memory... In the memory region (yes in step 2448), a memory system request is published to the memory system that specifies the tag location of the physical address obtained in step 2442 or 2446 to request a read/write operation on the allocation tag associated with the physical address (if step 2 translation is disabled in step 2444, step 250 is performed similarly to the case where the step 2 permissions have indicated a normal address region). Therefore, if step 2450 is executed, the allocation label is implemented as a virtualized label based on the virtual label, as shown in Figure 10, in which a separate address is allocated for the allocation label in the virtual address space, separate from the virtual address of the corresponding data item.

As shown in the annotations for read permission checks in Figure 24, whether any read permission checks are required for tag read operations when the tag access instruction is a tag-checked memory access instruction may vary depending on whether virtualization tags are enabled for either Phase 1 or Phase 2 translation. If a physical tagging method is used (and therefore virtualization tags are disabled in both steps 2404 and 2430), no specific read permission checks are required for tag reads, because it can be assumed that any read permission violations will be detected when a corresponding access is made to a data item that shares the same physical address as the corresponding allocated tag. If an intermediate labeling method is used (yes in step 2430), then the Stage 1 translation does not perform specific additional read permission checks for label access, because that translation is common to the corresponding Stage 1 translation performed for access to the corresponding data item. However, for the Stage 2 translation in step 2434, further read permission checks are performed to examine the data obtained in step 2432 corresponding to the data item access. The Stage 2 translation table entry for the tag-location intermediate address directly or indirectly indicates whether the Stage 2 memory permissions indicate the existence of permissions to read the tag at the corresponding intermediate address (since this Stage 2 translation table entry may differ from the Stage 2 translation table entry for the data-location intermediate address, the following is possible: there may be permissions to read data items without reading the corresponding tag). Similarly, if a virtual tagging method is adopted (yes in step 2404), then for a tag read of a memory access instruction that has been tag-checked, in step 2442 a read permission check is performed based on the Stage 1 read permission information obtained directly or indirectly from the Stage 1 translation table entry corresponding to the tag location virtual address (modified VA in FIG10), and in step 2446 a Stage 2 read permission check is performed based on the Stage 2 attribute specified directly or indirectly by the Stage 2 translation table entry corresponding to the tag location intermediate address (IPA2 in FIG10). If no read permission is granted for the label when any additional read permission check is performed for the label in steps 2434, 2442, or 2446, an error message is sent.

On the other hand, for label read/write instructions (where there is no corresponding data item access), each of the address translation steps 2406, 2412, 2434, 2442, and 2446 may include a corresponding check on the read/write permissions from the corresponding translation table entries used for translation, to check for the existence of permissions for reading or writing the label, and if the label access request violates the read/write permissions, an error may be transmitted.

Figures 25 to 28 provide an overview of the different options for supporting data and label translation.

Figure 25 illustrates an example of using entity tags, where both data access and tag access use the same translation mapping in both stages 1 and 2 of the two-stage address translation to obtain the entity addresses of the data item and its corresponding allocation tag within the entity address space 52. This method is selected if the first-stage tag translation control information (VTE) indicates that virtual tags are disabled and the second-stage tag translation control information (IPMTE) indicates that intermediate tags are also disabled.

Figure 26 shows an example where the first-stage Label Translation Control Information (VTE) indicates that virtual labels are disabled and the second-stage Label Translation Control Information (IPMTE) indicates that intermediate labels are enabled. This corresponds to the intermediate labeling method shown in Figure 11. In this case, for label or data access based on instructions specifying a given data virtual address VA, the first stage translation is the same for both label and data access, and the data virtual address VA is translated into the same data location intermediate address IPA used for both label and data access. However, for data access, the second stage translation maps the data location intermediate address to the data location data address. For label access, before the MMU 6 performs the second stage translation from the label location intermediate address to the label location entity address which is separate from the data location entity address, the label location address determination circuit system 10 converts the data location intermediate address into the label location intermediate address.

Figure 27 shows an example where the first-stage Label Translation Control Message (VTE) indicates that virtual tags are enabled, and the second-stage Label Translation Control Message (IPMTE) indicates that intermediate tags are disabled. In this case, for data access or tag access triggered by a Subject Tag Read/Write instruction (btag), stage 1 and stage 2 translations will be performed in the same manner as in Figure 25 to translate the data address or target address of the btag instruction into a physical address. Note that for the btag instruction, it is expected that the instruction will specify a different virtual address than the virtual address used for data access (since the virtual address of the btag instruction will be within the label table address ranges 202, 208, and 210, rather than the rest of the translatable address ranges 200, 204, and 206 as is the case for data access). However, from the perspective of address translation in MMU 6, the translation used for the btag instruction is handled using the same translation procedure as for data access (although it is expected to be applied to a different input address). On the other hand, for non-subject tag read/write instructions and tag reads performed by tag checking of tag-checked memory access instructions, before the stage 1 address translation, the tag location address determination circuit system 10 converts the data location virtual address specified by the instruction into the tag location virtual address before performing stage 1 and stage 2 address translation to translate the tag location virtual address IPA2 into the tag location physical address PA2 (nbtag PA).

Figure 28 shows an example where the first-stage Label Translation Control Message (VTE) indicates that a virtual label is enabled, and the second-stage Label Translation Control Message (IPMTE) indicates that an intermediate label is enabled. In this case, the translation of data access and non-subject label access is the same as in Figure 27 (since even if the IPMTE indicates that an intermediate label is enabled, the second address translation stage still uses the first address translation mode if the second address translation mode has already been enabled for the first address translation stage – see steps 1902 to 1906 in Figure 19). However, for the btag instruction, by default, it is considered to disable virtual tags for stage 1 translation. Then, if the IPMTE instruction enables intermediate tags, the translation of the btag instruction is executed as shown in Figure 26 instead of Figure 27. Therefore, Figure 28 corresponds to the functionality of data access and non-subject tag access from Figure 27, and the functionality of btag access from Figure 26.

As shown in Figures 26 to 28, when virtualization tags are enabled in Phase 1 or Phase 2, the following is possible: (In addition to subject or non-subject tag read/write instructions) memory access instructions can specify a virtual address as the target address they intend to use to define the location of a given data item to be accessed by the memory access instruction. This virtual address actually corresponds to a virtual address or intermediate address in the tag table address areas 202, 208, and 210 designated for storing the allocated tags. This is represented as "Data 2" in Figures 26 to 28 and corresponds to a tag data access operation.

This tag data access operation will be explained in further detail with reference to Figure 29. As shown in the figure, the address space region is designated as the allocated tag memory address region 240 (which may correspond to the tag table address regions 202, 208, 210). This address space may be a virtual address space or an intermediate virtual address space (i.e., depending on the translation stage, stage 1 or stage 2). Tag Z 242 is stored within the allocated tag memory address region 240. Data Z 244 (i.e., the data item) is also stored within the address space but outside the allocated tag memory address region 240. Tag Z 242 corresponds to the allocation tag associated with data Z and is used in the tag check performed when data access to data Z 242 is requested.

A load or store operation (LDR/STR) can be requested, and using the aforementioned techniques, the target data address of the address operand based on the LDR/STR can be determined. The target tag address can also be derived from the target data address of the LDR/STR. As shown in Figure 29, the target data address corresponds to a position in the address space of the stored data Z 244, and the target tag address corresponds to a position in the address space of the storage tag Z 242. Using tag Z 242 and the address tag derived from the address operand of the load or store operation, a tag check can be performed on the load or store operation. An example of a tag check operation is described with reference to Figure 4.

Alternatively, a tag access command (LDG(M)/STG(M, where LDG and STG represent non-body tag read and write commands respectively, and LDGM and STGM represent body tag read and write commands respectively)) can be requested instead of a tag-checked load or store operation. In this case, data access to data Z 244 will not be performed. Instead, the target tag address will be derived from the target data address of the tag access command, and tag Z 242 can be accessed using this target tag address.

However, separately, the load or store operation LDR/STR can specify the address operand corresponding to the data address in the tag region. As shown in the figure, the load or store operation can specify the address operand corresponding to the data address in the allocation tag memory address region 240 of the store tag Z 242. This load or store operation's address operand may be intended to define the location in the address space of a given data item to be accessed by the load or store instruction. That is, the load or store operation may be intended to access a data item located in the address space rather than a memory access operation of the allocation tag. However, because allocation tags are stored in a separate region of the virtual/intermediate physical address space (i.e., allocation tag memory address region 240), it is possible that a load or store operation may unintentionally (or intentionally, if used by an attacker as part of a potential vulnerability) specify a virtual address or an intermediate address in the allocation tag memory address region 240 instead. This is known as a tag data access operation.

By providing architectural support to respond to a data memory access (i.e., tag data access operation) request that specifies a target address corresponding to a memory address in the allocation tag memory address region 240 and refuses to read or write access to the data value (i.e., tag Z 242) stored at the memory address in the allocation tag memory address region 240, unintentional or intentional access (i.e., loading or storing) to the allocation tag that makes a data memory access request can be prevented.

Referring again to Figure 1, device 2 includes a tag data access check circuit system 32, which performs tag data access checks, such as those shown in Figures 30 and 31. The tag data access check will be explained in further detail with reference to Figure 30.

In step 3000, a data memory access request for the specified target address is executed. The data memory access request can be a load or store request, for example (e.g., a load/store request triggered by the general load/store instruction LDR/STR, having a different encoding (e.g., a different opcode) than the special tag read/write instructions LDG, STG, LDGM, STGM described above). As explained with reference to Figure 29, a data memory access request can be a tag data access memory access operation; that is, a data memory access request can be a load or store operation specifying an address operand corresponding to an address in a memory region designated as a memory allocation tag.

In step 3002, it is determined whether the data memory access request specifies a target address corresponding to a memory address in an allocation tag memory address region designated for storing allocation tags. This determination is based on memory address region definition information, which defines the allocation tag memory address region designated for storing allocation tags. As shown in Figure 29, the allocation tag memory address region can be in an address space other than the physical address space, such as a virtual address space or an intermediate physical address space.

Memory address region definition information may include memory address region definition configuration information that defines the variable location of the allocated tag memory address region in the address space. In some instances, the memory address region definition configuration information includes at least one of the following: information indicating a tag table base address; and information indicating a table size. In some instances, the tag table base address indicates the location within the address space that specifies the tag table region used to store the allocated tag, and may correspond to the tag table region discussed above. For example, the memory address region definition information may be the tag table base address information VTB, VTB0, VTB1, or VGB described above with respect to Figure 18.

In step 3004, if it is determined that the data memory access request specifies a target address corresponding to a memory address in the allocation tag memory address region designated for storage allocation tag, then reading or writing access to the data value stored at the memory address in the allocation tag memory address region is refused.

Denying read or write access may include triggering an error, such as generating an error signal indicating that read or write access has been denied. Denying read access may include reading the data value stored at the memory address as zero. In some instances, when a read access request is made, the data value is not read, but zero is returned instead. Denying write access may include ignoring the write access request, that is, not performing the requested write access.

In step 3006, if it is determined that the data memory access request does not specify a target address corresponding to a memory address in the allocation tag memory address region designated for storing the allocation tag, then read or write access to the data value stored at the memory address in the allocation tag memory address region is permitted. In some embodiments, permitting read or write access may include performing a read or write access on the data value. In other embodiments, permitting read or write access includes not denying read or write access by the tag data access check circuitry system. However, in such embodiments, read or write access may not be performed for one or more other reasons. In other words, in some cases, the fact that a read or write access was not rejected by the labeled data access check circuit system does not necessarily mean that the read or write access was actually performed (for example, the read/write access may not pass other types of permission checks by the MMU 6 application).

Another example of tag data access checking will now be described with reference to Figure 31. In step 3100, the data memory access request specifies a target address. Step 3100 corresponds to step 3000 in Figure 30. In step 3102, it is determined whether the data memory access request specifies a target address corresponding to a memory address in the allocation tag memory address region designated for storing the allocation tag. Step 3102 corresponds to step 3002 in Figure 30.

In step 3104, it is determined whether the tag data access check enable message indicates that the tag data access check is enabled for a data memory access request. The tag data access check enable message can identify whether the check is enabled for a privileged data memory access request.

In some cases, the tag data access check enable information is independent of whether the check is enabled for privileged data memory access requests to identify whether the tag data access check is enabled for non-privileged data memory access requests.

In some cases, the tag data access check enable information can identify whether the check is enabled for read memory access requests and independently identify whether the check is enabled for write memory access requests.

You can prevent the update of tag data access check enable information by instructions executed with insufficient privileges. For example, a non-privileged code might not be able to update the tag data access check enable information, while a privileged code might be able to.

Tag data access check enable information can include fields in control registers. For example, referring to Figure 18, a system control register (such as SCTLR2_ELx) can specify a tag data access check enable indicator nDGA to indicate whether tag data access checks are enabled. Separate read and write controls can be supported to specify whether tag data access checks are enabled for read operations and separately enabled for write operations. For example, a system control register (such as SCTLR2_ELx) can specify a read tag data access check enable indicator nDGAR and a write tag data access check enable indicator nDGAW. Therefore, in some examples, the read tag data access check enable instruction and the write tag data access check enable instruction can be stored in the same control register. In other examples, the read tag data access check enable instruction can be stored in a different control register than the one storing the write tag data access check enable instruction.

In some implementations, separate privileged and non-privileged data memory access controls can be supported to specify whether tag data access checks are enabled for privileged data memory access and separately for non-privileged data memory access. For example, different registers, such as different library versions of the system control register (e.g., SCTLR2_ELx discussed above), can specify different privileged/non-privileged versions of the tag data access check enable directive nDGA. In some implementations, both privileged and non-privileged data memory access tag data access check enable directives can be stored in the same control register.

Therefore, in some implementations, in order to determine whether the tag data access check enable message instructs that tag data access checks should be enabled for data memory access requests, the system control register can be checked to determine whether the tag data access check enable instruction (such as nDGA, nDGAR, nDGAW) specifies whether tag data access checks should be enabled for data memory access requests.

In some instances, the tag data access check enable information includes range information that defines at least one address space range that enables the tag data access check. Therefore, in some instances, to determine whether the tag data access check enable information instructs that the tag data access check be enabled for a data memory access request, the address specified by the data memory access request can be compared with at least one address space range to determine whether the address specified by the data memory access request is an address within at least one address space range that enables the tag data access check. It will be understood that at least one address space range can define at least one address range within a virtual or intermediate physical address space and a physical address space. In some instances, the tag data access check enable information may include separate scope information for read and write operations. In some instances, the tag data access check enable information may include separate scope information for privileged and non-privileged data memory access requests. Therefore, in some instances, the tag data access check information includes one or more of the following: range information for defining at least one address space range for enabling tag data access check for read operations; range information for defining at least one address space range for enabling tag data access check for write operations; range information for defining at least one address space range for enabling tag data access check for privileged memory access requests; and range information for defining at least one address space range for enabling tag data access check for non-privileged memory access requests.

Tag data access check enable information can also be specified in the translation table entry corresponding to the target address of the data memory access request. For example, a translation table entry (referred to herein as a page descriptor) that provides a stage 1 or stage 2 address mapping to generate an intermediate address in stage 1 or a physical address in stage 2 can also specify tag data access check enable information.

In step 3106, it is determined whether the tag location address determination circuit system is operating in virtualized tag mode. As discussed herein, a tag location address determination circuit system may be provided to determine, when operating in virtualized tag mode, the tag location address corresponding to the location of the assigned tag in the first address space based on the data location address that identifies the location of the given data item in the first address space other than the physical address space.

When the tag location address determination circuit system operates in virtualized tag mode, as discussed with reference to Figure 29, load or store operations may unintentionally specify address operators corresponding to data addresses in the area designated for storing the assigned tag. Therefore, enabling tag data access checks when operating in virtualized tag mode may help prevent unintentional data access to the assigned tag.

In step 3108, it is determined whether the data memory access request is triggered by an instruction other than at least one class of data access instructions that are permitted to access the allocation label in the allocation label memory address region. In some embodiments, a certain class of data access instructions may be permitted to access the allocation label in the allocation label memory address region. For example, a read or write instruction for a subject label or non-subject label (described above) or a label setting instruction (described with respect to Figure 29) may be a data access instruction class that is permitted to access the allocation label in the allocation label memory address region.

In step 3110, it is determined whether the memory access request is a non-privileged data memory access request. For example, it can be determined whether the code executing the memory access request is operating at a privilege level lower than a predetermined minimum privilege level.

In step 3112, read or write access to the data value stored at the memory address in the allocated tag memory address region may be denied. This step may correspond to step 3004 in Figure 30. Step 3112 may be executed in response to a determination that satisfies any combination of steps 3102 and steps 3104, 3106, 3108, and 3110 (i.e., a determination of affirmation). It will be understood that any of steps 3104, 3106, and 3108 may be omitted, or their order may be changed without altering functionality. For example, although Figure 31 shows each step leading to the next step, all steps 3102 to 3110 can be executed simultaneously, and the result is used to determine whether to refuse read or write access in step 3112.

In some instances, step 3112 can be performed independently of the determination in step 3104. For example, for non-privileged data memory access, if step 3104 determines whether the label data access check enable message instructs that label data access checks be enabled for the data memory access request, read or write access can be denied in step 3112.

In step 3114, read or write access is permitted to the data value stored at the memory address in the allocated tag memory address region. This step corresponds to step 3006 in Figure 30. In some embodiments, step 3114 may be performed if any of steps 3102 to 3110 (or the steps actually used in a given embodiment) produces a "No" result.

Figure 32 illustrates an example of data address translation including a label data access check. In step 3200, a data access instruction is executed.

In step 3202, it is determined whether stage 1 address translation is currently enabled. As discussed herein, in some implementations, stage 1 or stage 2 address translation may be enabled, or both stage 1 and stage 2 translation may be enabled.

If it is determined that Stage 1 address translation is enabled, then in step 3204 it is determined whether to enable the virtual tag (represented as VMTE). If Stage 1 address translation is disabled, the method can proceed directly to step 3214.

If it is determined that a virtual label is enabled, then in step 3206, it is determined whether label data access checks are enabled (indicated by "Label access checks are enabled?"). This can be determined based on the label data access check enabled information indicating that label data access checks are enabled for data access purposes, as discussed in Figures 30 and 31.

If it is determined that a tag data access check is enabled, then in step 3208, it is determined whether the data access corresponds to an access to a memory region specified for storage allocation tags. For example, it can be determined whether the data access specifies a target address corresponding to a memory address in the allocation tag memory address region.

If the data access is determined to correspond to access to a memory region specified for storage allocation, then in step 3210, a data access error is flagged. This may include triggering an error indication.

If virtual tags are disabled in step 3204, tag data access checks are disabled in step 3206, and/or the data access does not specify a target address corresponding to a memory address in the allocated tag memory address region, the method continues to step 3212. If a data access error is flagged in step 3210, the procedure continues to step 3212.

In step 3212, a data address translation operation is applied to stage 1 translation to translate the virtual address designated as the target address for the data access operation into the corresponding data intermediate address in the intermediate address space. Step 3212 corresponds to step 2406 in Figure 24.

In step 3214, it is determined whether stage 2 translation is enabled. If stage 2 translation is enabled, then in step 3216, stage 2 address translation is performed to translate the intermediate address of the data (if stage 1 translation is disabled, then it is the target address of the data access, or the address obtained in step 2406 through stage 1 translation). The method then proceeds to step 3218. If stage 2 address translation is disabled in step 3214, the method can directly proceed to step 3218.

In step 3218, the data access operation can be performed using the result of stage 2 address translation (if stage 2 address translation is enabled) or the result of stage 1 address translation (if stage 2 address translation is disabled).

The concepts described herein can be embodied in computer-readable code used to manufacture devices embodying the described concepts. For example, computer-readable code can be used in one or more stages of semiconductor design and manufacturing processes, including electronic design automation (EDA) stages, to manufacture integrated circuits containing devices embodying the concepts. The aforementioned computer-readable code can additionally or alternatively facilitate the definition, modeling, simulation, verification, and/or testing of devices implementing the concepts described herein.

For example, computer-readable code used to manufacture devices that implement the concepts described herein can define code implementations in a hardware description language (HDL) representing those concepts. For instance, the code can define a register-transfer-level (RTL) abstraction concept used to define one or more logical circuits in the device that implements the concepts. The code can define an HDL representing one or more logical circuits, implementing the device using Verilog, SystemVerilog, Chisel, or VHDL (Very High Speed Integrated Circuit Hardware Description Language) and intermediate representations such as FIRRTL. The computer-readable code can use system-level modeling languages such as SystemC and SystemVerilog to provide definitions of the implemented concepts, or other behavioral representations of the concepts that can be computer-compiled to facilitate the simulation, functional, and/or formal verification and testing of the concepts.

Alternatively or concurrently, computer-readable code may define a low-level description of an integrated circuit component that implements the concepts described herein, such as one or more wiring lookup tables or integrated circuit layout definitions, including representations such as GDSII. One or more wiring lookup tables or other computer-readable representations of the integrated circuit component may be generated by applying one or more logic synthesis procedures to the RTL representation to produce definitions for manufacturing the apparatus implementing the invention. Alternatively or additionally, one or more logic synthesis procedures may generate a bitstream from the computer-readable code, which is loaded into a field-programmable gate array (FPGA) to configure the FPGA to implement the concepts. FPGAs can be deployed for verification and testing purposes prior to the manufacturing of integrated circuits, or they can be deployed directly into products.

Computer-readable code may include a mixture of code representations used for manufacturing equipment, such as including RTL representations, wiring lookup table representations, or a mixture of one or more other computer-readable definitions used in semiconductor design and manufacturing processes to manufacture equipment implementing the present invention. Alternatively or additionally, the concept may be defined as a combination of the following computer-readable definitions and computer-readable codes: a computer-readable definition to be used in semiconductor design and manufacturing processes to manufacture equipment, and computer-readable code definitions of instructions to be executed by the defined equipment once it is manufactured.

Such computer-readable codes can be set in any known transient computer-readable medium (such as wired or wireless transmission codes over a network) or non-transient computer-readable medium (such as semiconductors, magnetic disks, or optical disks). Integrated circuits made using computer-readable codes can include components such as a central processing unit, a graphics processing unit, a neural processing unit, a digital signal processor, or one or more other components that implement the concept, either individually or collectively.

Figure 33 illustrates a possible simulator implementation. While the previously described embodiments implement the invention using devices and methods for operating specific processing hardware supporting the technology of concern, an instruction execution environment may also be provided according to the embodiments described herein, implemented using computer programs. Such computer programs are often referred to as simulators because they provide a software-based implementation of the hardware architecture. Types of simulator computer programs include emulators, virtual machines, models, and binary transcribers (including dynamic binary transcribers). Generally, simulator implementations can run on a host operating system 3304 and a host processor 3306 supporting simulator program 3302. In some configurations, there can be multiple layers of simulation between the hardware and the provided instruction execution environment and/or multiple different instruction execution environments provided on the same host processor. Historically, powerful processors have been needed to provide simulator implementations that execute at a reasonable speed, but this approach may be justified in certain situations, such as when it is necessary to run code native to another processor for compatibility or reuse reasons. For example, simulator implementations may provide instruction execution environments with additional functionality not supported by the host processor hardware, or instruction execution environments 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.

Where embodiments have been previously described with reference to specific hardware architectures or features, equivalent functionality can be provided in a simulated embodiment using appropriate software architectures or features. For example, a particular circuit system can be implemented as computer program logic in a simulated embodiment. Similarly, memory hardware (such as registers or caches) can be implemented as software data structures in a simulated embodiment. In configurations where one or more of the hardware elements mentioned in the previously described embodiments are present on host hardware (e.g., host processor 3306), some simulated embodiments can utilize the host hardware as appropriate.

The emulator program 3302 can 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 object code 3300 (which may include applications, operating systems, and a super manager), the same as the interface of the hardware architecture modeled by the emulator program 3302. Therefore, the program instructions of the aforementioned object code 3300 can be executed by the emulator program 3302 from within the instruction execution environment, enabling the host computer 3306, which does not actually possess the hardware characteristics of the device 2 discussed above, to emulate these characteristics.

Therefore, the emulator program 3302 may have an instruction decoding program logic 3314, which simulates instruction decoding and processing in a manner functionally equivalent to that provided by the aforementioned instruction decoding circuit system 4 and execution circuit system 16. The instruction decoding program logic 3314 decodes the instructions of the target code 3300 and maps these instructions to the corresponding instruction set in the native instruction set of the host device 3306. The memory management (address translation) logic 3308, the label checking logic 3312, and the label data access checking logic 3318 simulate the functionality of the MMU 6, the label checking circuit system 34, and the label data access checking circuit system 32 described above, including address translation, label checking, and support for virtual/intermediate labels. The host memory mapping logic 3310 maps the register access and memory access operations requested by the target code into accesses to corresponding data structures maintained on the host hardware of the host device 3306, such as accessing data in the registers or memory of the host device 3306. When memory management logic 3308 performs address translation based on translation tables defined by the target software, these translation tables translate addresses into analog physical address spaces. The target software 3300 understands that the analog physical address space corresponds to a physical location in the memory system. However, host memory mapping logic 3110 further maps the analog physical addresses obtained by memory management logic 3308 based on transfer tables defined for target code 3300 to host virtual addresses used to access host memory in host processing device 3306. These host virtual addresses can be translated into host physical addresses using the standard address translation mechanism supported by the host (the translation of host virtual addresses into host physical addresses is outside the scope controlled by the emulator program 3302).

In this application, the term "configured to..." is used to mean that a component of a device has a configuration capable of performing the defined operation. In this context, "configuration" refers to the arrangement or manner of hardware or software interconnection. 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 a device component needs to be changed in any way to provide the defined operation.

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

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

2: Data Processing Equipment 4: Instruction Fetch/Decoder Circuit System 6: Memory Management Unit 8: Translation Backup Buffer 10: Tag Location Address Determination Circuit System 12: Table Walkthrough Circuit System 14: Register 16: Execution Circuit System 20: Arithmetic/Logic Unit 22: Branch Unit 28: Load/Store Unit 32: Tag Data Access Check Circuit System 34: Tag Check Circuit System 40: Virtual Address Space 42: Target Virtual Address 44: Stage 1 Translation Table 46: Intermediate Address Space 48: Target Intermediate Address 50: Stage 2 Translation Table 52: Physical Address Space 54: Target Physical Address 60: Page Descriptor 62: Indirect Table 70: Data Item 72: Allocation Label 80: Address Label 82: Address Operator 84: Data Item 86: Data Region 88: Memory Address Region 90: First Address Space 92: Second Address Space 94: First Address of Data Location 96: Stage n Data Translation Table Structure 98: Translation Table Entries 100: Stage n Label Translation Table Structure 102: Translation Table Entries 104: Second Address of Data Location 106: Second Address of Label Location 108: Label Location First Address 110: Data Location First Address 110': Partial 112: Stage n Translation Table Structure 114: Label Mapping Entries 116: Data Mapping Translation Table Entries 118: Label Location Second Address 120: Data Location Second Address 200: Transducible Area 202: Label Table Address Area 204: Transducible Address Area 206: Transducible Address Area 208: Label Table Address Area 210: Label Table Address Area 220: Half-Byte Selection Information 240: Allocate Label Memory Address Area 242: Label Z 244: Data Z 800~808: Steps 1200~1222: Steps 1300~1312: Steps 1500~1516: Steps 1700~1714: Steps 1900~1912: Steps 2100~2110: Steps 2400~2408: Steps 2412~2426: Steps 2430~2450: Steps 3000~3006: Steps 3100~3114: Steps 3200~3218: Steps 3300: Target Code 3302: Emulator Program 3304: Host Operating System 3306: Host Computer 3308: Memory Management (Address Translation) Program Logic 3310: Host Memory Mapping Program Logic 3312: Tag Checker Logic 3314: Instruction Decoding Program Logic 3318: Tag Data Access Checker Logic IPMTE: Tag Translation Control Information; Second-stage Tag Translation Control Indicator IPA1: Given Intermediate Address IPA2: Tag Location Intermediate Address PA1: Physical Address PA2: Tag Location Physical Address VTB,VTB0,VTB1,VGB: Tag Table Base Address Information; Tag Table Base Address Information Entries; Tag Table Base Address Information Values VTE: Label translation control information; first-stage label translation mode indicator T1SZ: Area size indicator value T0SZ: Area size indicator value

Further features, characteristics, and advantages of this technology will become apparent from the following examples, which are read in conjunction with the accompanying figures: [Figure 1] illustrates an example of a data processing device including a label checking circuit system; [Figure 2] illustrates two-stage address translation; [Figure 3] illustrates translation table entries and the use of indirect methods to specify memory attribute information; [Figure 4] illustrates label checking; [Figure 5] illustrates an example of setting allocation label values when allocating or deallocating regions of memory address space; [Figures 6] and [7] illustrate examples of memory usage errors detected using label checking; [Figure 8] illustrates the steps performed for label checking operations; [Figure 9] Illustration of a physical label; [Figure 10] Illustration of a virtual label; [Figure 11] Illustration of an intermediate address label; [Figure 12] Illustration of the steps used to control whether to perform label location address translation on the architecture in response to a label-checked memory access instruction; [Figure 13] Illustration of the steps used to perform label location address translation; [Figure 14] Illustration of a first instance of the label location address translation operation; [Figure 15] Illustration of the steps used to perform the label location address translation operation based on the first instance; [Figure 16] Illustration of a second instance of the label location address translation operation; [Figure 17] illustrates the steps for performing a tag-based address translation operation based on the second instance; [Figure 18] illustrates an instance of a control register storing architectural state information used to control address translation for allocated tag access; [Figure 19] illustrates the steps for selecting whether to apply a data address translation operation or add a tag address translation operation to generate a physical address that identifies the memory system location storing a given allocated tag; [Figure 20] illustrates two instances providing tag table address regions in one or more translatable address regions within the address space; [Figure 21] illustrates the steps for generating a tag-based address; [Figure 22] illustrates a label location address determination operation for an address space containing a single translatable address region; [Figure 23] illustrates a label location address determination operation for an address space containing two translatable address regions; [Figure 24] illustrates the steps for label location address translation in an example supporting first and second address translation modes; [Figures 25] through [Figure 28] illustrate different methods of label location address translation depending on whether the first or second address translation mode is used in the first and second address translation stages; [Figure 29] illustrates a label data access operation; [Figure 30] illustrates an example of performing a label data access check; [Figure 31] illustrates another example of performing a tag data access check; [Figure 32] illustrates an example of data address translation including a tag data access check; and [Figure 33] illustrates a simulation example.

1300: Steps

1302: Step

1304: Steps

1306: Step

1308: Step

1310: Steps

1312: Steps

Claims (19)

An apparatus comprising: a tag checking circuit system for responding to a tag checking memory access instruction to perform a tag checking, the tag checking memory access instruction specifying an address operator corresponding to a target data address associated with a data item stored in a memory system, the tag checking including triggering an error handling response in response to detecting a tag mismatch between the allocation tag obtained from the memory system for the target data address and an address tag associated with the address operator; and An address translation circuit system for performing address translation based on address mapping information associated with at least one address translation stage, the at least one address translation stage including a given address translation stage from a first address space to a second address space; wherein: When the given address translation stage is executed in response to a specified given data address and a request to perform an operation using a given allocation label associated with a given data item corresponding to the given data address, the address translation circuit system is configured to: Determine whether a first label translation mode or a second label translation mode is a selected label translation mode to be used in the given address translation stage in response to the label access instruction; Respond to determining that the selected label translation mode is the first label translation mode by obtaining a data location second address, the data location second address identifying a location within the second address space for both the given data item and the given allocation label; and Respond to determining that the selected label translation mode is the second label translation mode by obtaining a label location second address, the label location second address identifying a location within the second address space for the given allocation label, a location separate from a location within the second address space for the given data item identified by the data location second address. The device of claim 1, wherein the address translation circuit system is configured to support a one- and two-stage translation system, wherein the address translation is performed based on a first address translation stage from a virtual address space to an intermediate address space and a second address translation stage from the intermediate address space to a physical address space. The device of claim 2, wherein the address translation circuit system is configured to support the use of the second label translation mode when the given address translation phase is the first address translation phase, wherein the first address space is the virtual address space and the second address space is the intermediate address space. The device of any of requests 2 and 3, wherein the address translation circuit system is configured to support the use of the second label translation mode when the given address translation phase is the second address translation phase, wherein the first address space is the intermediate address space and the second address space is the physical address space. The device as described in any of the preceding requests, wherein the address translation circuit system is configured to select the selected label translation mode based on label translation control information, the label translation control information being configurable to control which label translation mode is used for the selected label translation mode in the given address translation phase. The device, as in Request 5, wherein the label translates control information into information specified in a control register. For any of the devices in requests 5 and 6, the label translation control information includes a first-stage label translation mode indicator, which indicates whether the first label translation mode or the second label translation mode should be used as the selected label translation mode for a first address translation stage, wherein the first address space is a virtual address space and the second address space is an intermediate address space. As in the device of claim 7, wherein: In the first label translation mode, the address translation circuit system is configured to obtain the second address of the data location by processing an input address based on a data address translation operation; In the second label translation mode, the address translation circuit system is configured to obtain the second address of the label location by processing an input address based on a label address translation operation; and When the first address translation stage is executed in response to a subject tag read/write instruction to request the read or write of one or more assigned tags identified using a subject tag target address specified by the subject tag read/write instruction, the address translation circuit system is configured to apply the data address translation operation to an input address based on the subject tag target address to obtain a tag read/write target second address in the second address space, even when the first-stage tag translation mode indicator indicates that the second tag translation mode should be used as the selected tag translation mode for the first address translation stage in response to the tag access instruction. The device, as in request item 8, prohibits the execution of the subject label read/write command at at least one privilege level that would allow the execution of the label access command. For any of the claims 7 to 9, the device wherein the label translation control information includes a second-stage label translation mode indicator, the second-stage label translation mode indicator indicating that when the first-stage label translation mode indicator indicates that the selected label translation mode is used for the first address translation stage, either the first label translation mode or the second label translation mode should be used as the selected label translation mode for a second address translation stage, for the second address translation stage, the first address space is the intermediate address space, and the second address space is a physical address space. As in the device of claim 10, wherein the response to determining that the first-stage label translation mode indicator indicates that the selected label translation mode is the second label translation mode for the first address translation stage, the address translation circuit system is configured to determine that the first label translation mode should be used as the selected label translation mode for the second address translation stage. The apparatus of any of the foregoing claims, wherein when the given address translation phase is executed in response to the tag access instruction, and when the selected tag translation mode is the second tag translation mode for the given address translation phase, the address translation circuit system is configured to: obtain a tag location first address that identifies a location of the given allocation tag in the first address space based on a data location first address that identifies a location of the given data item in the first address space; and The second address of a tag is obtained by translating the first address of the tag location according to address mapping information selected from a given stage translation table structure based on the first address of the tag location. This given stage translation table structure is based on a given base address of the translation table. As in the device of claim 12, when the given address translation phase is executed in response to the tag access instruction, and when the selected tag translation mode is the first tag translation mode for the given address translation phase, the address translation circuit system is configured to: obtain the second address of the data location by translating the first address of the data location according to address mapping information selected from the given phase translation table structure based on the first address of the data location, the given phase translation table structure being based on the given translation table base address identification. The apparatus of any of claims 12 and 13, wherein, in the second tag translation mode, the address translation circuit system is configured to obtain the first address of the tag location based on: a tag table base address indicating a location within the first address space that specifies a tag table region for storing allocated tags; and a tag table offset derived from the first address of the data location. For any of the devices in claims 1 to 14, when the given address translation phase is executed in response to the tag access instruction, the address translation circuit system is configured to: In response to determining that the selected tag translation mode is the first tag translation mode, obtain the second address of the data location by translating a first address of the data location that identifies a position of the given data item in the first address space based on address mapping information, wherein the address mapping information is selected from a data translation table structure based on the first address of the data location, and the data translation table structure is based on a data translation table base address identification; and In response to the determination that the selected label translation mode is the second label translation mode, the second address of the label location is obtained by translating the first address of the data location based on address mapping information. This address mapping information is selected from a label translation table structure based on the first address of the data location. This label translation table structure is identified based on a label translation table base address that is separate from the base address of the data translation table. A computer-readable code for manufacturing equipment as described in any of the aforementioned requests. A method comprising: determining whether a first label translation mode or a second label translation mode is a selected label translation mode to be executed in response to a label access instruction, wherein the label access instruction specifies a given data address and requests to perform an operation using a given allocation label associated with a given data item corresponding to the given data address, the given allocation label including information for responding to a label-checked... A tag in a tag check pending a memory access instruction is checked. The tag check specifies an address operand used to define a target address for a memory access operation. The tag check includes a response to triggering an error handling response if an error is detected between the allocation tag obtained from the memory system for the target address and the address tag associated with the address operand. The response is to determine that a data location second address is obtained by selecting the first label translation mode, the data location second address identifying a position of both the given data item and the given allocation label within the second address space; and the response is to determine that a label location second address is obtained by selecting the second label translation mode, the label location second address identifying a position of the given allocation label within the second address space, the position being separate from a position of the given data item within the second address space identified by the data location second address. A computer program for controlling a host data processing device to provide an instruction execution environment for executing object code, the computer program comprising: A label checking procedure logic that responds to a label checking memory access instruction that specifies an address operand corresponding to a target data address associated with an allocation tag stored in a simulated memory system. The label checking includes a response to triggering an error handling response upon detecting a label mismatch between the allocation tag obtained from the simulated memory system for the target data address and the address tag associated with the address operand; and Address translation logic is used to perform address translation based on address mapping information associated with at least one address translation stage, the at least one address translation stage including a given address translation stage from a first address space to a second address space; wherein: When the given address translation stage is executed in response to a specified given data address and a request to perform an operation using a given allocation label associated with a given data item corresponding to the given data address, the address translation logic is configured to: Determine whether a first label translation mode or a second label translation mode is a selected label translation mode to be used in the given address translation stage in response to the label access instruction; Respond to determining that the selected label translation mode is the first label translation mode by obtaining a data location second address, the data location second address identifying a location within the second address space for both the given data item and the given allocation label; and Respond to determining that the selected label translation mode is the second label translation mode by obtaining a label location second address, the label location second address identifying a location within the second address space for the given allocation label, a location separate from a location within the second address space for the given data item identified by the data location second address. A storage medium that stores computer programs as described in request item 18.