Tag location address translation operation

Abstract

In response to a memory access instruction that specifies an address operand for defining a target data address corresponding to a target data item having an associated allocation tag stored in a memory system, it is determined whether the target data address is in a non-tagged memory region in which tag checking will not be required based on memory attribute information associated with the target data address. Whether to architecturally perform a tag-locating address translation operation to obtain a tag-locating physical address that locates the associated allocation tag within a physical address space separate from a data-locating physical address that locates the target data item within the physical address space is determined based at least on whether the memory attribute information indicates that the target data address is in the non-tagged memory region.

Description

[0001] This technology relates to the field of data processing.

[0002] Some data processing architectures can provide support for tag checking operations based on allocation tags stored in memory for a given data item and address tags associated with address pointers used to compute the address of that given data item. Such tag checking can help detect memory security errors (e.g., errors where, due to programming errors and / or unexpected results of program code, such as buffer overflows, an address pointer is used to induce access to a memory region that the address pointer was never intended to point to, thus posing a risk of data corruption and increasing vulnerability to malicious attacks).

[0003] At least some examples of this technology provide an apparatus comprising: a tag checking circuit configured to perform a tag checking in response to a tag checking memory access instruction specifying an address operand for defining a target data address corresponding to a target data item having an associated allocation tag stored in a memory system, the tag checking including triggering an error handling response in response to detecting a tag mismatch between the associated allocation tag for the target data address obtained from the memory system and an address tag associated with the address operand; and a memory management circuit configured to control access to a target data address based on memory attribute information associated with the target data address, the memory attribute information indicating whether the target data address is in a non-tag memory region where tag checking is not required; wherein: the memory management circuit is configured to determine, at least based on whether the memory attribute information associated with the target data address of the tag checking memory access instruction indicates that the target data address is in a non-tag memory region, whether to perform a tag positioning address translation operation at the architectural level to obtain a tag positioning physical address for locating the associated allocation tag in the physical address space, the tag positioning physical address being separate from the data positioning physical address for locating the target data item in the physical address space.

[0004] At least some examples of this technology provide computer-readable code for manufacturing the aforementioned apparatus. This computer-readable code can be stored on a storage medium. The storage medium can be a non-transitory storage medium.

[0005] At least some examples of this technology provide a method comprising: specifying an address operand for defining a target data address corresponding to a target data item having an associated allocation tag stored in a memory system, in response to a memory access instruction for tag checking; determining whether the target data address is in a non-tag memory region where tag checking is not required, based on memory attribute information associated with the target data address, the tag checking including triggering an error handling response in response to detecting a tag mismatch between the associated allocation tag for the target data address obtained from the memory system and an address tag associated with the address operand; and determining whether to perform a tag-locating address translation operation at the architecture level to obtain a tag-locating physical address for locating the associated allocation tag in the physical address space, separate from a data-locating physical address for locating the target data item in the physical address space, based at least on whether the memory attribute information associated with the target data address of the memory access instruction for tag checking indicates that the target data address is in a non-tag memory region; and determining whether to perform a tag-locating address translation operation to obtain a tag-locating physical address for locating the associated allocation tag in the physical address space, based at least on whether the memory attribute information for the target data address of the memory access instruction for tag checking indicates that the target data address is in a non-tag memory region.

[0006] At least some examples provide a computer program for controlling a host data processing device to provide an instruction execution environment for executing target program code. The computer program includes: tag checking program logic for performing tag checking in response to a tag checking memory access instruction, the tag checking memory access instruction specifying an address operand for defining a target data address corresponding to a target data item having an associated allocation tag stored in an analog memory system; the tag checking includes triggering an error handling response in response to detecting a tag mismatch between the associated allocation tag for the target data address obtained from the analog memory system and an address tag associated with the address operand; and memory management. The program logic, the memory management program logic, is used to control access to a target data address based on memory attribute information associated with the target data address, the memory attribute information indicating whether the target data address is in a non-tagged memory region that will not require tag checking; wherein: the memory management program logic is configured to determine, at least based 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 in a non-tagged memory region, whether a tag-locating address translation operation is performed on the architecture to obtain a tag-locating simulated physical address for locating the associated assigned tag in the simulated physical address space, the tag-locating physical address being different from the data-locating physical address for locating the target data item in the simulated physical address space.

[0007] Computer programs can be stored on storage media. The storage media can be non-transitory.

[0008] Further aspects, features, and advantages of this technology will become apparent from the following description, which is taken in conjunction with the accompanying drawings, in which:

[0009] Figure 1 An example of a data processing device including a tag inspection circuit is shown;

[0010] Figure 2 This illustrates a two-stage address translation;

[0011] Figure 3 Examples of translation table entries and the use of indirect methods to specify memory attribute information are shown;

[0012] Figure 4 An example of label checking is shown;

[0013] Figure 5 An example is shown where an allocation tag value is set when allocating or deallocating a region of memory address space;

[0014] Figure 6 and Figure 7 An example of using tags to check for detected memory usage errors is shown;

[0015] Figure 8 The steps for performing a label inspection operation are illustrated.

[0016] Figure 9 Physical tags are illustrated;

[0017] Figure 10 Virtual tags are illustrated;

[0018] Figure 11 An example of an intermediate address marker is shown;

[0019] Figure 12 The steps for controlling whether to perform tag location address translation on the architecture in response to memory access instructions for tag checking are illustrated;

[0020] Figure 13 The steps for performing tag location address translation are illustrated;

[0021] Figure 14 This illustrates a first example of a tag location address translation operation;

[0022] Figure 15 The steps for performing a label location address translation operation based on the first example are shown;

[0023] Figure 16 A second example of a tag location address translation operation is shown;

[0024] Figure 17 The steps for performing the label location address translation operation according to the second example are shown;

[0025] Figure 18 An example of a control register that stores architectural state information used to control address translation for allocated tag access is shown;

[0026] Figure 19 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 assigned tag are illustrated.

[0027] Figure 20 Two examples are shown that provide tag table address regions in one or more convertible address regions within an address space;

[0028] Figure 21 The steps for generating a tag location address are illustrated;

[0029] Figure 22 An example is provided for label-based address determination operations for an address space that includes a single convertible address region;

[0030] Figure 23 An example is given of a tag-based address determination operation for an address space that includes two convertible address regions;

[0031] Figure 24 The steps for tag-based address translation are illustrated in an example that supports both the first and second address translation modes;

[0032] Figures 25 to 28 The example illustrates different label-based address translation methods depending on whether the first address translation mode or the second address translation mode is used at the first-stage address translation and the second-stage address translation.

[0033] Figure 29 This example demonstrates how to access data via tags;

[0034] Figure 30 An example of performing a data access to tag check is provided;

[0035] Figure 31 This provides another example of performing a data access to tag check;

[0036] Figure 32 An example of data address translation, including data access to tag inspection, is given; and

[0037] Figure 33 A simulation example is shown.

[0038] An apparatus includes a tag checking circuit for performing a tag checking in response to a tag checking memory access instruction specifying an address operand for defining a target data address corresponding to a data item associated with an allocation tag stored in a memory system. The tag checking includes triggering an error handling response in response to detecting a tag mismatch between an allocation tag obtained from the memory system for the target data address and an address tag associated with the address operand. The error handling response may include, for example, denying memory access (e.g., signaling a fault in response to a memory access instruction that failed the tag checking), and / or logging information about the detected tag mismatch error (e.g., updating an error log to identify the target data address for which the tag mismatch was detected). When a tag mismatch is detected, it is not necessarily required to prevent memory access from continuing (e.g., in some cases, the purpose of the tag checking may simply be to generate a report for software developers to flag possible memory usage errors, rather than necessarily requiring the blocking of access to the underlying data in memory). However, by providing architectural support to assign allocation tags to data items stored in the memory system, assign address tags to address operands used to compute the addresses of such data items, and compare allocation tags and address tags when executing memory access instructions that perform tag checks, software developers can develop more robust program code that is less likely to cause errors or be compromised by attackers.

[0039] Address translation circuitry performs address translation based on address mapping information associated with at least one stage of address translation, including a given stage of address translation from a first address space to a second address space. In some examples, the address translation circuitry supports different tag translation modes for address translation at a given stage, for use when processing tag access instructions that specify a given data address and request to perform an operation using a given allocation tag associated with a given data item corresponding to the given data address. The tag access instruction may be a tag-checked memory access instruction, for which the operation performed using the given allocation tag is a tag check performed by tag-checking circuitry to compare the given allocation tag with an address tag associated with the address operand used to calculate the given data address, and the tag-checked memory access instruction also requests a read or write memory access to the given data item. Alternatively, the tag access instruction may be a tag read / write instruction for reading or writing the value of an allocation tag associated with a data item block corresponding to a given data address (such a 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. Responding to a tag access instruction does not necessarily require accessing the given data item itself.

[0040] When performing address translation for a given stage in response to a tag access instruction, the address translation circuitry can determine whether a first tag translation mode or a second tag translation mode is the selected tag translation mode to be used for the address translation of the given stage in response to the tag access instruction. In response to determining that the selected tag translation mode is the first tag translation mode, the address translation circuitry obtains a data location second address, which identifies the positions of both the given data item and the given allocation tag in the second address space. In response to determining that the selected tag translation mode is the second tag translation mode, the address translation circuitry obtains a tag location second address, which identifies the position of the given allocation tag in the second address space, separate from the position of the given data item in the second address space identified by the data location second address. If the tag access instruction does not require access to the given data item, obtaining the data location second address itself is not necessarily required in response to the tag access instruction when obtaining the tag location second address according to the second tag translation mode.

[0041] Using this approach, the address translation circuitry offers greater flexibility in determining how to associate allocation tags with their corresponding data items. If the first tag translation mode is selected, both a given data item and its associated allocation tag are mapped to the same address within the second address space (based on the address mapping information used in both accessing the data item and accessing its associated allocation tag). If the first tag translation mode is used for all stages of address translation, 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, leaving 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, the memory system can provide physical storage for storing allocation tags alongside each data location—for example, using spare bits that would otherwise be used for error correction codes or other information; or alternatively, the memory system can partition off a portion of its physical storage to reserve allocation tags associated with data items in another portion of its physical storage. The specific mechanism in the memory system for managing the association between data items and tags can be implementation-dependent and separate from the address translation mechanism provided by the address translation circuitry. While this approach simplifies software development (because the software does not need to control the address translation table structure to provide separate address mapping information for the translated data items and the associated allocation tags), it may place a greater burden on memory system hardware designers, requiring them to provide ways to specify the storage of allocation tags and associate the locations of those allocation tags with the corresponding items.

[0042] On the other hand, if a second translation mode is selected for a given address translation mode, a given allocation tag can be mapped to an address in the second address space that is separate from the address identifying 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 memory system's perspective, it does not need to manage any specific tag access mechanism (e.g., specifying physical memory that is permanently reserved for storing allocation tags), because when both the tag and the data need to be accessed, two memory access requests can simply be sent to the memory system—one access request for the tag to locate a physical address (depending on the tag locating a second address), and another access request for the data to locate a physical address (depending on the data locating a second address). By supporting data location address translation to identify a tag location second address that is separate from the data location address translation used to identify the data location second address, tag location virtualization can also help improve the utilization efficiency of available physical memory storage. This is because not every assigned tag that is mapped to a tag address in a given data address space needs to be allocated physical memory in the physical address space. Furthermore, the virtualization method enables the tag location addresses of assigned tags that are to be assigned the same allocation tag value and are associated with different data items to be mapped to the same translated tag location address, thereby reducing the number of physical storage locations in memory required to provide tag storage for a given number of data items.

[0043] Therefore, by providing address translation circuitry that supports selection between a first tag translation mode and a second tag translation mode, this allows for different configurations: whether software (by setting the relevant address translation mapping control) or the memory system hardware (if the software has already chosen to map tags / data to the same physical address) takes on the task of identifying the location of the assigned tag associated with a specific data item. This allows for different trade-offs, balancing the reduced complexity of maintaining tag address translation mappings (in the first tag translation mode) with more efficient use of available physical memory (in the second tag translation mode). Thus, a processor architecture that supports both the first and second tag translation modes better balances the needs of a wide range of workloads.

[0044] It is not necessary to perform address translation for a given stage based on either a first tag translation mode or a second tag translation mode each time a tag access instruction is executed. The address translation circuitry may have at least one translation lookup buffer (TLB) that caches information derived from previous instances of performing address translation for a given stage for a given target address. If information identifying the tag-located second address (or, in cases where the tag-located second address itself will require further translation into a physical address) is already available in the translation lookup buffer, then address translation for a given stage will not need to be performed again. Furthermore, as described below, in some examples, whether tag translation is performed at the architecture to obtain the tag-located second address may depend on attributes obtained in the data translation operation used to obtain the data-located second address corresponding to the given data address, at least when the second tag translation mode will be used for address translation in a given stage and the tag access instruction is a memory access instruction that also requires tag checking to access a given data item.

[0045] In some examples, the address translation circuitry can support a two-stage translation mechanism, where address translation is performed based on a first-stage address translation from the virtual address space to an intermediate address space and a second-stage address translation from the intermediate address space to the physical address space. This can help support virtualization, where multiple guest operating systems (each responsible for setting up address mappings for the first-stage address translation) can coexist on the same hardware platform, and thus the hypervisor can control the address mappings for the second-stage address translation to ensure that conflicting intermediate addresses in the intermediate address space, obtained based on mappings set by different guest operating systems, are mapped to different physical addresses in the physical address space.

[0046] When a two-stage translation mechanism is supported, support for both the first label translation mode and the second label translation mode can be provided for the first stage address translation (but not the second stage), or for the second stage (but not the first stage), or for both the first stage and the second stage.

[0047] Therefore, in some examples, the address translation circuitry can support the use of a second tag translation mode when the address translation for a given stage is a first-stage address translation. In this case, the first address space is a virtual address space, and the second address space is an intermediate address space. In this case, the data location second address and the tag location second address can undergo further translation in the second-stage address translation to obtain the corresponding data location physical address and tag location physical address in the physical address space. Therefore, the mode control used to select between the first tag translation mode and the second tag translation mode affects whether a given data item and a given allocation tag are mapped to separate addresses in the intermediate address space. These separate intermediate addresses may depend on separate address mapping information defined for the data item and its associated allocation tag in separate first-stage address translation table entries.

[0048] In some examples, the address translation circuitry can support the use of a second tag translation mode when the address translation of a given stage is a second-stage address translation, where the first address space is an intermediate address space and the second address space is a physical address space. In this case, the data positioning second address is the data positioning physical address, and the tag positioning second address is the tag positioning physical address. Therefore, the mode control used to select between the first and second tag translation modes affects whether a given data item and a given allocation tag are mapped to separate addresses in the physical address space, which are determined during address translation based on separate address mapping information defined for data and allocation tags in separate second-stage address translation entries. These separate second-stage address translation entries can be selected based on information dependent on the data positioning first address, which identifies the location of the given data item within the first (intermediate) address space, where the data positioning first address is obtained by translating the given (virtual) data address according to the first-stage address translation.

[0049] The address translation circuitry can select a chosen tag translation mode based on tag translation control information, which can be configured to control which tag translation mode is the selected tag translation mode for a given stage of address translation. Therefore, when the address translation circuitry hardware supports two modes, the configuration settings can select which mode to use for a given instance performing a given stage of address translation for a given tag access instruction.

[0050] In some examples, the tag translation control information can be a static configuration input fixed for a given processing system in which the address translation circuitry is implemented. For example, the same processor design including 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 (therefore, when the address translation circuitry is used in conjunction with that type of memory storage unit, it may be beneficial to constrain the address translation circuitry to use a second tag translation mode for address translation at least one stage).

[0051] However, in some examples, tag transition control information may include software-configurable configuration inputs that can be set by software running on the data processing system. For example, tag transition control information may include information specified in a control register that can be accessed by at least some software (e.g., by software executing at a given privilege level—software with a lower privilege level may not be able to set the information indicated in the control register). This allows for greater dynamic control over whether a particular software workload will be executed based on whether its tag access is controlled according to a first tag transition mode or a second tag transition mode.

[0052] Tag translation control information may include a first-stage tag translation mode indicator that indicates, at least for first-class tag access instructions, whether a first tag translation mode or a second tag translation mode should be used for address translation in the first stage where the first address space is a virtual address space and the second address space is an intermediate address space. Therefore, when the address translation for a given stage is a first-stage address translation, the first-stage tag translation mode indicator can be used to control which tag translation mode is used.

[0053] Given support for both a first tag translation mode and a second tag translation mode, different ways can exist to translate a given input address during a given stage of address translation: in the first tag translation mode, the address translation circuit obtains the data location second address based on processing the input address according to a data address translation operation; and in the second tag translation mode, the address translation circuit obtains the tag location second address based on processing the input address according to a tag address translation operation. The data address translation operation and the tag 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).

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

[0055] However, it may also be useful to provide instructions of the following type: instructions that apply data address translation operations to the address used to identify one or more allocation tags of interest, even when the tag access instruction applies tag address translation operations in a second tag translation mode. Thus, in some examples, when performing first-stage address translation for a bulk tag read / write instruction to request the read or write of one or more allocation tags identified using the bulk tag target address specified by the bulk tag read / write instruction, the address translation circuitry can obtain the tag read / write target second address in the second address space based on applying data address translation operations to the input address, which depends on the bulk tag target address, 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-stage address translation in response to the tag access instruction. Therefore, the bulk tag read / write instruction directly specifies the address identifying the location of one or more allocation tags, rather than indirectly specifying it by specifying the address of the corresponding data item, and for address translation purposes, it behaves similarly to a non-tag check data access instruction that does not require access to any allocation tags at all. Batch tag read / write commands that access allocation tags as if they were data items can be useful, for example, for hypervisors, allowing them to control the values ​​of allocation tags used by guest operating systems.

[0056] In at least one privilege level where tag access instructions are allowed to be executed, bulk tag read / write instructions can be disabled. This reduces the possibility of lower-privileged code tampering with assigned tags and reflects the common use case of bulk tag read / write instructions, which can be used by hypervisors with sufficient privileges to allow their execution.

[0057] For some examples supporting the use of a second label translation mode for second-stage address translation (where the first address space is an intermediate address space and the second address space is a physical address space), the label translation control information may also include a second-stage label translation mode indicator that indicates whether the first label translation mode or the second label translation mode should be used as the selected label translation mode for the second-stage address translation when the first-stage label translation mode indicator indicates that the selected label translation mode for the first-stage address translation is the first label translation mode. This allows the hypervisor to select which virtualized memory tags (where different address translation mappings are applied to data and associated allocation tags) to apply for the second-stage translation for a given guest operating system, even if the guest operating system is not designed to support virtualized tags at the first-stage address translation. This also helps support more efficient use of physical memory storage by avoiding the need for the memory system to carve out permanent areas of physical memory to store tags.

[0058] When the first-stage label translation mode indicator has a value indicating that the first label translation mode will be used for the first-stage address translation, the second-stage label translation mode indicator affects which label translation mode is used for the second-stage address translation. However, when the first-stage label translation mode indicator indicates that the second label translation mode will be used for the first-stage address translation, it may not be desirable to also apply the second label translation mode to the second-stage address translation, as this could lead to unpredictable results where the data / label addresses generated from the first-stage address translation are treated as separate data addresses, and these data addresses will each be mapped to separate data / label addresses in the second-stage address translation. Therefore, to reduce the software overhead of managing such unpredictable address translation mappings, it may be helpful to configure the address translation circuitry such that, in response to determining that the first-stage label translation mode indicator indicates that the selected label translation mode for the first-stage address translation is the second label translation mode, the address translation circuitry determines that the first label translation mode should be used as the selected label translation mode for the second-stage address translation (regardless of the value set for the second-stage label translation mode indicator).

[0059] When the selected label conversion mode is the second label conversion mode, there are multiple different ways to locate the second address based on the generated label.

[0060] In some examples, when address translation for a given stage is performed in response to a tag access instruction, and the selected tag translation mode for the given stage is the second tag translation mode, the address translation circuitry can obtain a tag positioning first address identifying the location of a given assigned tag in the first address space based on a data positioning first address identifying the location of a given data item in the first address space, and then obtain a tag positioning second address by transforming the tag positioning first address according to address mapping information selected from a given stage translation table structure based on the tag positioning first address identified by a given translation table base address. Therefore, the previously mentioned tag address translation operation may include transforming the data positioning first address to generate different tag positioning first addresses representing the location of a given assigned tag in the first address space, and then using the obtained tag positioning first address to select an entry in a given stage translation table structure that provides an address mapping to the tag positioning second address. This approach simplifies the software overhead of maintaining the translation table structure because a single translation table structure maintained by software can be shared for both data address translation operations and tag address translation operations.

[0061] Using this method, when address translation for a given stage is performed in response to a tag access instruction, and the selected tag translation mode for the given stage is the first tag translation mode, the address translation circuit can obtain the second data location address by translating the data location first address based on the address mapping information selected from the given stage translation table structure based on the given translation table base address identifier. Therefore, the same translation table base address can be used whether the tag address translation operation is performed in the second tag translation mode or the data address translation operation is performed in the first tag translation mode (or in the case of performing data address translation operation for the previously mentioned bulk tag read / write instruction).

[0062] In the second tag translation mode, the address translation circuit can obtain the tag location first address based on: a tag table base address indicating the location of the tag table region designated for storing the allocated tag within the first address space; and a tag table offset derived from the data location first address. Although other more complex transformations of the data location first address can be applied to generate the tag location first address, it is simpler to implement in hardware using a portion of the data location first address as the offset to be applied relative to the tag table base address.

[0063] In other examples, instead of transforming the data to locate the first address to obtain the tag to locate the first address (so that the data and tag address translations provide different first address inputs to the table lookup for address translation for a given stage), another approach could be to use the same data to locate the first address as the input address for the translation table lookup for address translation for that given stage, but use the same data to locate the first address to use different translation table structures defined by different base addresses, so that separate translation table entries for data and tag access can be identified from the corresponding translation table structures to map the same data to locate the first address in the first address space to the data to locate the second address in the second address space and the separate tag to locate the second address.

[0064] Therefore, when performing address translation at a given stage in response to a tag access instruction, the address translation circuit can be configured such that: in response to determining that the selected tag translation mode is a first tag translation mode, the address translation circuit obtains a second data location address by translating the data location first address based on address mapping information from a data translation table structure identified by a base address of the data translation table, which identifies the position of a given data item in the first address space. In response to determining that the selected tag translation mode is a second tag translation mode, the address translation circuit obtains the second tag location address by translating the data location first address based on address mapping information from a tag translation table structure identified by a base address of the tag translation table, which is separate from the base address of the data translation table.

[0065] While the examples above describe a specific implementation of the address translation circuitry that selects whether to apply a first tag translation mode or a second tag translation mode to obtain the address in the second address space that identifies the location of the allocation tag associated with a given data item, other examples may support the second tag translation mode (virtualized tag translation mode) for obtaining the address of the allocation tag, but may not support the first tag translation mode. In this case, physical tagging (where both the data item and its associated allocation tag are identified in memory based on the same physical address) may not be supported.

[0066] Regardless of whether physical tagging methods are supported (e.g., using the first tag translation mode), in specific implementations supporting 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-locating address translation operation to obtain a tag-locating address, an operation that may otherwise be unnecessary for non-tag-checked memory access instructions. This can introduce performance costs because performing tag-locating address translation operations carries the risk of more frequent address translation failures that are detrimental to processing performance. These failures occur when the entry providing the address translation mapping for the required tag address has not yet been configured by the software or indicates a failed access permission (in the case of virtualized tag translation mode, tag translation may use a different address translation entry than the one used to obtain the corresponding data location address, and therefore this does not guarantee that tag translation will not produce translation failures even if the entry used to obtain the data location address has been correctly configured). Therefore, while introducing such tag location address translation operations in virtualized tag translation mode may have the benefit of reducing the dependence on memory system management on the location of tags associated with corresponding data items (e.g., avoiding the need to allocate a portion of physical memory for tags), virtualized tag translation mode may pose a risk of performance degradation compared to the specific implementation of tag location address translation operations that are not performed separately from the corresponding data location address translation operations.

[0067] In the examples discussed below, the memory management circuitry can control access to the target data address of a memory access instruction for tag checking based on memory attribute information associated with the target data address. The memory attribute information may indicate whether the target data address is in a non-tag memory region that does not require tag checking. The memory management circuitry can determine, at least based on whether the memory attribute information associated with the target data address of the memory access instruction for tag checking indicates that the target data address is in a non-tag memory region, whether a tag location address translation operation should be performed on the architecture to obtain the tag location physical address for locating the associated allocated tag within the physical address space (the tag location physical address is separate from the data location physical address for locating the target data item within the physical address space).

[0068] Using this method, software can signal (by setting memory attribute information for a given set of addresses) whether access to those addresses requires tag checking, and for address regions that do not require tag checking, it can suppress tag-based address translation operations on the architecture, thereby reducing the frequency of processing interruptions caused by address translation failures. This can help improve processing performance.

[0069] The memory management circuitry can suppress tag-location address translation operations on the architecture in response to detecting that the target data address is in an untagged memory region.

[0070] Some examples may also consider other factors when determining whether to suppress label-based address translation operations on the architecture.

[0071] For example, in some examples, the memory management circuitry may include the address translation circuitry mentioned above, and thus may also support the first and second address translation modes as previously mentioned. In this case, determining whether to enable or disable tag-location address translation operations on the architecture may be related to the second address translation mode, but not to the first address translation mode.

[0072] Therefore, in some examples, the memory management circuitry may suppress the execution of tag-location address translation operations at the architecture level in response to detecting that at least one tag translation mode indicator indicates that a virtualized tag translation mode is disabled. This virtualized tag translation mode includes a mode where a target data item is mapped to a data location physical address based on data translation address mapping information corresponding to the target data address, and an associated allocation tag is mapped to a tag location physical address based on tag translation address mapping information corresponding to the target data address, the tag translation address mapping information being separate from the data translation address mapping information. For example, the virtualized tag translation mode could be the previously mentioned second address translation mode (and could be applied in either the first or second stage of address translation). The tag translation address mapping information can be separated from the data translation address mapping information for various reasons, depending on the specific implementation (e.g., because the tag translation address mapping information and the data translation address mapping information are selected from translation table structures accessed using different translation table base addresses, or because the tag 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 tag and data item, respectively). Therefore, even if the memory attribute information does not indicate that the target data address is in the untagged memory region, tag-based address translation operations can still be prevented from being performed on the architecture if virtualization tagging is currently disabled.

[0073] When virtualization tag translation mode is disabled, the memory management circuitry can map both the target data item and its associated allocation tag to the data location physical address. This corresponds to the first address translation mode described above.

[0074] Memory attribute information may also support the indication of the target data address as an encoding in a tagged memory region. In this case, whether tag-location address translation is performed on the architecture may depend on whether at least one additional condition is met (e.g., depending on instruction type information, and / or depending on a control indicator that controls whether the virtualization tag translation mode is enabled).

[0075] For example, additional conditions that are met 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 to be disabled, tag location address translation may not be performed on the architecture, even if memory attribute information indicates that the target data address is in the tag memory region.

[0076] When tag-based address translation operations are to be architecturally suppressed, memory management circuitry prevents signaling of any faults based on tag-based address translation operations. Faults are costly in terms of performance because they can disrupt ongoing workloads to allow exception handlers to execute. Therefore, by preventing signaling of address translation faults for tag-based address translation operations when accessing untagged memory regions, the likelihood of performance penalty is reduced.

[0077] In some cases, when tag-based address translation (TA) operations need to be architecturally suppressed, memory management circuitry can prevent TA from being actually performed. Therefore, TA can be completely avoided. Besides reducing the risk of spurious address translation failures, this eliminates the bandwidth cost of performing the translation, freeing up address translation bandwidth for other translation operations.

[0078] However, in some implementations, even when tag-based address translation (TA) operations are to be architecturally suppressed, memory management circuitry may still allow TA to be actually performed, but prevent changes in the architectural state caused by TA to result in the same architectural outcome as if TA were not performed. For example, memory management circuitry may prevent signaling of faults, updating architecturally visible performance counters, and / or triggering read / write operations in memory based on the results of TA that were performed but should have been architecturally suppressed. Even when architecturally suppressed, performing TA may be useful in some implementations because it allows TA to begin earlier than if the TA was postponed until the result of checking memory attribute information is actually known (while waiting for the memory attribute information associated with the target data address). Furthermore, in some cases, if performing a tag-locating address translation results in the translation table pointer being cached in a translation back buffer as a result of the tag-locating address translation, this may help speed up subsequent translations that require the same pointer (e.g., a given translation table pointer from a higher-level translation table in a multi-level translation table structure can be shared between some tagged memory regions and some untagged memory regions).

[0079] In some examples, a special memory attribute type corresponding to the unmarked memory region can be defined (or multiple variations of the "unmarked" memory attribute can be defined).

[0080] However, in other examples, memory management circuitry can infer whether a target data address is in an untagged memory region based on one or more memory attribute indicators from memory attribute information. These one or more memory attribute indicators are used to indicate one or more memory region attributes unrelated to the execution of tag checking. The spare coding space available for encoding attribute types in translation table entries can be severely limited, so it may sometimes be impossible to add new specialized attribute types to an existing address translation architecture. Therefore, in some cases, whether a region is tagged / untagged can be inferred from other attribute types already provided.

[0081] For example, a marked memory region can be restricted to a region indicated by memory attribute information as a general write-back cacheable memory region. A "general" memory region can be a non-device memory region, for which repeated or reordered accesses to the memory region are permitted (unlike a "device" memory region, for which repeated or reordered accesses are not permitted because this could lead to side effects). For example, device memory is often used as a buffer structure for controlling devices such as input / output (I / O) devices or hardware accelerators; therefore, unlike reading / writing to memory stores used for random access memory data, performing the same read or write multiple times or reordering the sequence of read / write operations relative to the order in which read / write requests were issued can lead to inappropriate operation of such devices. Memory marking is typically used for random access memory data, not device control structures, so addresses in device memory can be assumed to be unmarked by default. Similarly, non-cacheable memory regions (regions storing addresses that do not need to be allocated to a cache) are unlikely to store general random access memory data accessed by software prone to memory usage errors; therefore, non-cacheable memory regions can also be assumed to be unmarked. Therefore, in some examples, the memory management circuitry can determine that the target data address is in a non-tagged memory region in response to detecting that the target data address is in a region other than a normal write-back cacheable memory region.

[0082] It should be understood that this is only one example, and other examples may have different ways of encoding whether a memory region is tagged or untagged using memory attribute information associated with the target data address of the memory access instruction for tag checking.

[0083] Memory management circuitry can determine whether to perform a tag-locating address translation operation on the architecture based on memory attribute information derived from at least one translation table entry accessed in a data-locating address translation operation used to translate a target data address to a data-locating physical address. The data-locating address translation operation can be executed for tag-checking memory access instructions for the purpose of identifying the physical address of the target data item, regardless of whether the tag-locating address translation operation is performed on the architecture or suppressed. Therefore, enabling / disabling whether to perform tag-locating address translation operations on the architecture using memory attribute information available from the data-locating address translation operation provides an easily implemented technique for preventing unnecessary failures that could result from unnecessarily performing tag-locating address translation operations. It might be considered undesirable to enable / disable tag-locating address translation operations based on attribute information from the data-locating address translation operation, as performing tag-locating address translation operations after the data-locating address translation operation could risk excessive latency for tag-checking memory access instructions, especially when both data translation and tag translation require translation table traversal. However, in practice, because tag-location address translation (TA) operations are architecturally suppressed but not necessarily prevented from execution, they can be speculatively initiated before memory attribute information becomes available. This prevents any failures or other architectural consequences caused by speculatively executed TA operations if it is later discovered that the TA operations should have been suppressed. If it is later discovered that the TA operations will be architecturally disabled (suppressed), then no further work on the TA operations is required.

[0084] In some examples, for address translation at a given stage, memory management circuitry can perform tag-location address translation operations based on address mapping information from tag-translation table entries, which differ from the data translation table entries that provide address mapping information for address translation at a given stage in data-location address translation operations used to translate target data addresses to data-location physical addresses. As noted above, different methods can exist for tag / 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 tag / data translation table structures, or providing different tag / data input addresses to a common translation table structure shared between tags and data). Address translation at a given stage can be a first-stage address translation for transitioning from virtual address space to intermediate address space, or a second-stage address translation for transitioning from intermediate address space to physical address space.

[0085] In some examples, an apparatus includes: the tag inspection circuit mentioned above; a tag location address determination circuit for determining a tag location address in the first address space that identifies the location of an allocation tag corresponding to the given data item, based on a data location address that identifies the location of the given data item in the first address space; and an address translation circuit for performing at least one stage of address translation from the first address space to the physical address space. The tag location address determination circuit may determine the tag location address based on an offset relative to a tag table base address, which indicates the location of a tag table address region within the first address space designated for storing the allocation tag, the offset depending on an offset portion of the data location address.

[0086] Therefore, within the first address space (which will be converted to the physical address space using one or two stages of address translation), the data location address identifying the location of a given data item in the first address space is transformed to generate a corresponding tag location address identifying the location of the associated allocation tag in the first address space. This transformation is performed 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).

[0087] Compared to alternatives (such as looking up the data location address in a tag address translation table structure separate from the data address translation table structure), this approach simplifies the development of software for use with systems that support virtualized tags, because it means that the same translation table structure can be shared for both data translation and tag translation. The tag location address determination circuitry can modify the data location address to identify the tag location address, which can then be input for address translation using the same translation structure also used for data.

[0088] Furthermore, compared to alternatives such as defining a data-to-tag address mapping table to provide a more arbitrary mapping from a data location address in the first address space to a corresponding tag location address in the first address space, generating the tag location address based on an offset relative to the tag table base address (which depends on the offset portion of the data location address) reduces the hardware cost of implementing the tag location address determination circuit and the software development cost of setting up the control information for controlling the generation of the tag location address.

[0089] In some examples, the tag location address determination circuitry 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 contiguous with 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 is the allocation tag corresponding to the data location address. This can be useful for implementations where each allocation tag includes fewer bits than the number of bits of storage information corresponding to a single address in memory. For example, for a byte-addressable memory where each unique address value corresponds to a corresponding byte (8 bits) of data in memory, the allocation tag may include fewer than 8 bits (e.g., 4 bits). In this case, it may be useful to pack multiple allocation tags into a memory location corresponding to a single address, allowing the allocation tags to be stored more compactly in the memory address space. Thus, if the minimum size of the data returned from memory reads corresponds to the content of a single addressable location (e.g., one byte), multiple tags can actually be returned from the allocation tags read from memory. In order to select among allocation tags returned from memory (and 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 bits that are less significant (but contiguous) than the portion used to derive the offset. For example, in an example where the allocation tags are 4 bits wide and each address references 1 byte (8 bits) of memory, the next least significant bit after the portion used to derive the offset can be used to select between two allocation tags present at a given byte in the memory address space.

[0090] Other examples can use different tag sizes. If the tag size is equal to the size of an addressable memory location, then there is no need to derive tag selection information from the tag location address determination circuitry, because a read of a given address in memory can return a single assigned tag.

[0091] In some examples, the tag table base address includes an aligned address. An aligned address can be an address that is naturally aligned with an alignment boundary in memory. For example, the tag table base address can be explicitly or implicitly defined as an address where multiple least significant bits are 0. By using an aligned tag table base address, this reduces the complexity of the tag location address determination circuitry. For example, this means that an adder is not needed to combine the base address with the offset, as the offset bits can simply be inserted into the aligned base address to the location corresponding to 0. Since adders are relatively slow compared to circuitry used to multiplex bits from different sources into the appropriate bit locations, eliminating the cost of adders in each address translation cycle for looking up a tag address can help improve performance and make it easier for circuit designers to design circuitry that meets timing requirements. Furthermore, using an aligned base address means that less storage information is needed to define the base address, because the lower bits of 0 do not need to be explicitly stored. For example, those 0 bits can be omitted from the information stored in registers to define the base address. Alternatively, if a register does define the lower bits of the address, the lower bits of the register defining the base address can be ignored, so that even if they are set to non-zero values, the base address is still an aligned address with multiple lower bits set to 0.

[0092] In some examples, the tag table base address can be fixed by design (e.g., constrained to a specific location within the first address space in the instruction set architecture).

[0093] However, to increase flexibility for software developers, it can be useful to change the tag table base address based on the tag table base address information. The tag table base address information can be configured by software (e.g., in some cases, it is restricted to modification by software with at least a given privilege level). For example, the tag table base address information can be specified in a control register. In some examples, multiple tag table base address information corresponding to different conversion mechanisms can be specified, where the tag table base address to be used to generate the tag location address is selected by the tag location address determination circuitry based on an indication of which conversion mechanism is currently in use.

[0094] The first address space may include at least one translatable address region, each translatable address region having a corresponding tag table address region specified within the first address space. A translatable address region may be an address space region in which valid data address translation is permitted. Therefore, in response to a data memory access request to access a data item at an address outside the translatable address region, the address translation circuitry may trigger a fault. Restricting valid address translation to one or more translatable address regions can be helpful because this leaves available encoding space for encoding other information (such as address tags for tag checking) in the address values. Furthermore, limiting the size of the translatable address regions within the address space reduces the overhead for software developers, as they do not need to maintain a translation table structure covering such a large address space region.

[0095] In some examples, the tag table address region can be located within a given translatable address region. This is simpler for hardware / software designers because the introduction of the tag table address region may not require any changes to which addresses in the first address space are translatable or non-translatable.

[0096] However, the tag table address region for a given convertible address region can also be located outside of that region. For example, the tag table address region can be located in a region adjacent to the convertible address region, where data corresponding to tags in the tag table address region is stored. If the tag table address region is located outside the corresponding convertible address region, tag memory access to allocated tags in the tag table address region can be excluded from the requirement of accessing only addresses in the convertible region (unlike data access to data items), therefore tag access to addresses in the tag table address region may not trigger a fault. Data access to that tag table address region may trigger a fault. Tag access to addresses in a portion of a non-convertible address region other than the tag table address region may trigger a fault.

[0097] In some examples, for a given convertible address region with a variable region size based on region size information, the size of the corresponding tag table address region is variable, scaling proportionally with the size of the given convertible address region. For example, the convertible region size information can be set by software to define the size of a given convertible address region. Since the granularity of defining allocation tags for data items in a given memory region can be fixed (depending on the ratio of the allocation tag width to the size of the data block sharing an allocation tag), it can be useful for the tag table storage region size to scale proportionally with the size of the corresponding convertible address region, so that the convertible region size information also implicitly defines the size of the given tag table address region (and therefore the size of the offset portion used to form the tag location address and the bit positioning for applying that offset to the tag table base address). Therefore, this approach avoids the need to define separate configuration information (e.g., control register states) that defines the tag table size separately from the convertible address region size.

[0098] For example, the ratio between the size of a given convertible address region and the size of the corresponding tag table address region could be 2. n , of which 2 n It is the number of bytes of data corresponding to one or more allocation tags stored in a byte in the address area of ​​the corresponding tag table.

[0099] In some examples, the first address space may support a single translatable address region.

[0100] However, other examples may (at least for some operational states of some translation mechanisms or processing circuitry) support a first address space comprising multiple translatable address regions, each having a separate tag table base address identifying the location of its corresponding tag table address region. Providing multiple translatable address regions helps distinguish address spaces used for different purposes (e.g., one translatable region for user / application-level software and another for kernel / operating system-level software). Therefore, when determining tag location addresses while multiple translatable address regions are in use, the tag location address determination circuitry may apply an offset relative to the tag table base address corresponding to the translatable address region that includes the data location address. The tag table base addresses of the multiple translatable address regions may be variable, based on separate tag table base address information entries for each of the multiple translatable address regions (e.g., tag table base address information for each translatable address region may be stored in one or more control registers).

[0101] Similarly, a convertible address region can have a corresponding region size that varies based on individual region size information entries for multiple convertible regions. Likewise, the size of a given tag table address region can be scaled proportionally to the size of the corresponding convertible region; therefore, the tag table address region of one convertible address region can have a different size than the tag table address region of another convertible address region.

[0102] Some examples support both single-convertible-region and multi-convertible-region conversion mechanisms, where the control state stored in the control register defines the configuration of the currently used convertible address region.

[0103] In some examples, the offset portion of the data location address excludes the least significant n bits of the data location address, where 2 n It is the number of data bytes corresponding to one or more allocation tags stored in a byte in the corresponding tag table address area. Therefore, the offset portion can correspond to the part of the data location address that will select a unique allocation tag from the tag table address area (when determining the offset portion, the bits in the address that only distinguish different addresses sharing the same allocation tag are ignored).

[0104] In some examples, for a size of 2 t The tag location address is the data location address within a given convertible address region of the byte. The tag location address determination circuit can determine the tag location address as an address within the given convertible address region, where the bits [t-1:0] of the tag location address include:

[0105] The bits [tn-1:0] of the tag location address specify the offset portion obtained from the bits [t-1:n] of the data location address; and

[0106] The bits [t-1:tn] of the tag location address are set based on tag table base address information that indicates the tag table base address corresponding to a given convertible address region;

[0107] Among them 2 n It is the number of data bytes corresponding to one or more allocation tags stored in a byte of the corresponding tag table address region. This approach can be implemented relatively simply in hardware circuit logic and provides sufficient flexibility for software to change the location of the tag table address region within the first address space depending on which parts of the first address space need to be used for other purposes.

[0108] Tag location address determination circuitry can help support virtualized tag access modes, where, for address translation performed by address translation circuitry in response to a tag access instruction with a specified data address (the data location address depends on that data address), when virtualized tag access mode is enabled for address translation at a given stage for translating an address from a first 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 circuitry obtains the 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 circuitry based on the data location address. This virtualized tag access mode can help reduce the requirements on the memory system to allocate physical memory for tags or provide tag-specific access mechanisms.

[0109] In some examples, the virtualized label access mode may be the only supported mode for accessing labels (e.g., corresponding to the previously mentioned second label conversion mode). Other examples may also support physical label access modes (e.g., the previously mentioned first label conversion mode).

[0110] In some examples, the address translation circuitry is configured to support virtualized label access mode for both: first-stage address translation, where the first address space is a virtual address space and the second address space is an intermediate address space; and second-stage address translation, where the first address space is an intermediate address space and the second address space is a physical address space. Other examples may support virtualized label access mode for address translation only for one of the first-stage or second-stage address translation stages.

[0111] In an example supporting virtualized tag access mode for both the first-stage and second-stage address translation, the tag location address determination circuitry may include hardware configured to share hardware circuitry for: determining the tag location address in the virtual address space based on the data location address in the virtual address space when virtualized tag access mode is enabled for the first-stage address translation; and determining the tag location address in the intermediate address space based on the data location address in the intermediate address space when virtualized tag access mode is enabled for the second-stage address translation. Aside from reading different information defining the tag table base address, the mapping function used to map the data location address to the tag location address can be the same, regardless of whether the mapping function is applied to the translation between corresponding data / tag virtual addresses in the virtual address space or between corresponding data / tag intermediate addresses in the intermediate address space. Therefore, the same hardware can be shared for both stages of address translation, reducing overall circuit area cost.

[0112] As described above, virtualized tags (e.g., virtual or intermediate tags as mentioned herein) may be supported in some implementations. Therefore, allocation tags can be stored together with data items in the address space (virtual or intermediate address space), allowing the allocation tags to be accessed using data memory access requests. For example, an allocation tag stored at a given addressed location in the address space can be accessed using a data access operation specifying that given addressed location.

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

[0114] As described herein, allocation tags can be used as part of tag checks, and therefore their values ​​can affect the outcome of the tag check, i.e., whether an error handling response is executed. Therefore, it may be undesirable to allow unintentional or intentional access to allocation tags via data memory access operations. For example, an attacker might attempt to exploit tag checks to intentionally trigger or de-trigger error handling responses based on the value of the allocation tag (e.g., as part of a denial-of-service attack, if a modification of the allocation tag results in a denial of memory access, thus compromising the functionality of the victim software). Even if an attacker triggers data access to the tag's storage area without compromising memory access to the victim code, an attacker's reading of the tag value may still provide side-channel information about the victim process's memory usage. Therefore, an attacker might attempt to read the current value of the allocation tag or attempt to modify the value of the allocation tag to influence the outcome of the tag check. Furthermore, even if there is no malicious attempt in an unintentional data access to the assigned label, but the access is caused solely by a programming error, an unintentional update to the assigned label value caused by an error affecting one data access operation may lead to a false report of a label mismatch error on another data access operation that itself does not have any programming errors. This may cause software developers to unnecessarily spend development time reviewing the erroneous part of the code that is alleged to be causing the error, when the problem is actually elsewhere.

[0115] Therefore, it may be advantageous to provide architectural support to identify cases where data access requests specify a target address corresponding to a memory address with a storage allocation tag.

[0116] Therefore, in some examples, an apparatus includes the tag checking circuit mentioned above, and a data access to tag checking circuit for performing data access to tag checking. Data access to tag checking includes: determining, based on memory address region definition information defining an allocation tag memory address region specified 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, rejecting read or write access to the data value stored at the memory address in the allocation tag memory address region.

[0117] Therefore, read or write access to a data value can be denied based on the target address of the data memory access request corresponding to an address in the memory region designated for storing the allocation tag. This provides an in-architecture mechanism for controlling access to the memory region storing the allocation tag, preventing unintentional or unauthorized access to the allocation tag.

[0118] As discussed above, this approach prevents exploitation by potential malicious attackers by preventing a requester from accessing the allocation tag using a data memory access request that directly specifies the address of the allocation tag. Compared to alternatives such as denying read or write permissions based on data memory access requests that do not specify an address in the memory region designated for storing the allocation tag, this approach provides enhanced security against attackers seeking to exploit specific implementations of tag-checking responses.

[0119] Furthermore, unnecessary or unintentional access to allocation tags can be prevented. For example, the requester of a data memory access request may not know where the allocation tag is stored in memory (virtual or physical), or the requester may unintentionally specify a target address corresponding to a memory address in the allocation tag memory address region designated for storing the allocation tag. For example, as discussed herein, when operating in virtualized tag modes (such as virtual tags or intermediate tags), memory access instructions may specify a virtual or intermediate physical address as the target address intended to define the location of a given data item, which actually corresponds to a virtual or intermediate physical address in the memory region designated for storing the allocation tag. Therefore, such unnecessary or unintentional access to the allocation tag can be prevented.

[0120] In some examples, denying read or write access may include one or more of the following: triggering a fault, reading the data value as zero, and ignoring write requests for the data value. For example, to deny read access, in some examples, the data value may be read as zero (in some cases, a read operation may not be triggered and a zero value may be returned). In some cases, to deny write access, write access may be ignored. In some cases, a fault may be triggered to deny read or write access. For example, a fault indication may be generated.

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

[0122] In some examples, the memory address region definition information includes memory address region definition configuration information that defines the variable location of the allocation tag memory address region in the address space. That is, in some examples, the location of the allocation tag memory address region in a given address space may not be fixed. Therefore, the allocation tag memory address region can be defined according to a specific implementation, thus allowing software developers flexibility in how to define regions and use them to store allocation tags.

[0123] The configuration information defining the tag memory address region allocation may include at least one of the following: information indicating the base address of the tag table; and information indicating the table size. Therefore, instead of defining each individual address within the tag memory address region allocation, the configuration information may include information for determining the range of addresses included within the tag memory address region allocation. In some examples (e.g., below regarding...), Figure 20 (Further discussion of the dual convertible region example) The address space may include more than one allocated tag memory address region, and therefore, if the target address of a data memory access request corresponds to any of the allocated tag memory address regions defined by the allocated tag memory address region definition configuration information, read / write access may be denied in the data access to tag check.

[0124] In some examples, for data access to tag checking, the data access to tag checking circuitry is configured to deny read or write access to the 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 a target address corresponding to a memory address in the allocated tag memory address region; and determining that data access to tag checking enable information indicates that data access to tag checking is enabled for the data memory access request.

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

[0126] In some examples, the Data Access To Tag Check Enablement Information indicates whether Data Access To Tag Check is enabled for data storage access requests that are read requests, and independently of whether Data Access To Tag Check is enabled for data storage access requests that are write requests, it indicates whether Data Access To Tag Check is enabled for data storage access requests that are read 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 controls 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 inspection of the allocation tag value.

[0127] In some examples, the data access to tag checking circuitry is configured to determine whether data access to tag checking is enabled for a write data storage access request, independent of data access to tag checking enable information. Therefore, in some examples, data access to tag checking can be performed for a write data storage access, regardless of whether data access to tag checking enable information indicates that data access to tag checking is enabled. In some cases, performing data access to tag checking for any data storage access request that is a write data storage access may be advantageous. For example, a write data storage access request could be performed by a potential attacker attempting to influence the results of tag checks as discussed herein.

[0128] In some examples, the Data Access to Tag Check Enablement Information indicates whether the Data Access to Tag Check is enabled for privileged data storage access requests. Therefore, in some examples, the Data Access to Tag Check can be enabled or disabled for privileged data storage access requests. Garbage collection operations or other authorized data access to assigned tags are more likely to be performed by privileged code, so it may be advantageous to be able to disable the Data Access to Tag Check for such privileged code.

[0129] In some examples, the data access to tag checking circuitry is configured to determine whether data access to tag checking is enabled for non-privileged data memory access requests, independent of data access to tag checking enable information. Therefore, in some examples, data access to tag checking can be performed for non-privileged data memory access, regardless of whether data access to tag checking enable information indicates that data access to tag checking is enabled. In some cases, it may be advantageous to perform data access to tag checking for any data memory access request that is a non-privileged data memory access. For example, a non-privileged data memory access request may be executed by non-privileged code that may not be trusted to access the assigned tag.

[0130] In some examples, the Data Access to Label Check Enablement information identifies whether Data Access to Label Check is enabled for non-privileged data storage access requests, independently of whether Data Access to Label Check is enabled for privileged data storage access requests.

[0131] Therefore, separate read / write access control can be supported for privileged and non-privileged data memory access requests. In some implementations, data access to tag checks can be enabled for non-privileged data memory access requests but disabled for privileged data memory access requests (i.e., code is executing at a privilege level greater than a predetermined privilege level). Thus, in this implementation, non-privileged data memory access requests attempting to read or write data stored in the allocation tag memory address region can be denied, while privileged data memory access requests can be allowed to read or write data stored in the allocation tag memory address region. Therefore, read or write access to the allocation tag stored in the allocation tag memory address region can be allowed or denied based on the privilege level of the code requesting data memory access to the allocation tag.

[0132] In some examples, updating the data access to label check enable information is prohibited by instructions executed with insufficient privileges. Therefore, in some examples, code executed with sufficient privileges might be able to update the data access to label check enable information to enable or disable data access to label checks, while code executed with insufficient privileges might not be able to. A potential attacker might attempt to update the data access to label check information using code, so preventing unprivileged code from doing so increases security against potential attackers. Furthermore, the ability to selectively enable data access to label checks can be advantageous for hypervisors or security management processes.

[0133] In some examples, the data access to tag check (DATAT) enable information includes fields in a control register. Therefore, the control register can be checked to efficiently determine whether DATAT is enabled for a given data memory access request. Furthermore, in some examples, the DATAT enable information may include a first field in the control register for enabling DATAT for read operations and a separate second field for enabling DATAT for write operations (either in the same control register or in a different control register than the one storing the first field). Therefore, separate control over DATAT can be provided for read and write operations.

[0134] In some examples, the data access to tag check enable information may include a first field in a control register for enabling data access to tag check for privileged data memory access operations, and a separate second field (in the same control register, or in a different control register than the one storing the first field) for enabling data access to tag check for non-privileged data memory access operations. Thus, separate control over data access to tag check can be provided for both privileged and non-privileged data memory access operations.

[0135] In some examples, the data access to tag check enable information includes range information that defines at least one address space range for which data access to tag check is enabled. In some examples, the data access to tag check enable information can be checked to determine whether the target address of a data memory access request is included in the address space range defined by the range information. Therefore, multiple addresses can be efficiently indicated such that data access to tag check is enabled for data memory access requests pointing to a target address within these multiple addresses.

[0136] In some examples, the data access to tag check enable information may include separate range information for read and write operations. Therefore, in some examples, the data access to tag check enable information includes: range information defining at least one address space range for which data access to tag check is enabled for read operations, and range information defining at least one address space range for which data access to tag check is enabled for write operations. In some examples, the data access to tag check enable information may include separate range information for privileged and non-privileged data memory access requests. Therefore, in some examples, the data access to tag check enable information includes range information defining at least one address space range for which data access to tag check is enabled for privileged data memory access requests, and range information defining at least one address space range for which data access to tag check is enabled for non-privileged data memory access requests. In some examples, the data access to tag check enable information includes one or more of the following: range information for read data access operations, range information for write data access operations, range information for privileged data memory access requests, and range information for non-privileged data memory access requests.

[0137] In some examples, data access to tag check enable information is specified in the translation table entry corresponding to the target address of the data storage access request. This provides an efficient indication of whether data access to tag check is enabled. In some examples, since access to the translation table entry is already required to perform target address translation, using the translation table entry information corresponding to the target address of the data storage access request provides a particularly efficient mechanism for determining whether data access to tag check is enabled.

[0138] In some examples, for data access to tag checking, the data access to tag checking circuitry is configured to deny read or write access to the 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 a target address corresponding to a memory address in the allocation tag memory address region; and the memory access request being triggered by an instruction other than at least one type of data access instruction that is allowed to access the allocation tag in the allocation tag memory address region.

[0139] Therefore, in some examples, read or write access can be denied based on the fact that the instruction category triggering the data memory access request is not a data access instruction category permitted to access the allocation tag in the allocation tag memory address region. In some examples, one type of data access instruction can be designated as permitted to access the allocation tag, while instructions of other categories can be denied access to the allocation tag. Thus, the type of data memory access can be used to selectively deny or allow read or write access to the allocation tag.

[0140] In some examples, for data access to tag checks, the data access to tag check circuitry is configured to deny read or write access to the 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 a 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 denied based on the fact that the data memory access request is a non-privileged memory access. As discussed above, preventing non-privileged memory access to allocated tags can be advantageous because an attacker might use non-privileged memory access to attempt to read or modify the allocated tag to influence the result of the tag check.

[0141] In some examples, tag location address determination circuitry is provided to determine, when operating in virtualized tagging mode, a tag location address identifying the location of an allocation tag corresponding to a given data item in a first address space other than the physical address space, based on a data location address identifying the location of the given data item in a first address space. The data access to tag checking circuitry is configured to deny 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 a target address corresponding to a memory address in the allocation tag memory address region; and determining that the tag location address determination circuitry is operating in virtualized tagging mode.

[0142] Therefore, this method supports data access to tag inspection in a virtualized tagging mode, where an address is specified for storing the tag in a first address space of the physical address space to be translated through one or more stages of address translation. Furthermore, it can deny read or write access based on whether the tag location address determination circuit is operating in virtualized tagging mode. Thus, this method supports virtualized tagging (i.e., virtual tags or intermediate tags discussed herein).

[0143] The techniques discussed above can be implemented within a data processing device having hardware circuitry provided for implementing the tag inspection circuitry, address translation (memory management) circuitry, tag location address determination circuitry, and / or data access to tag inspection circuitry discussed above. However, the same techniques can also be implemented within a computer program that executes on a host data processing device to provide an instruction execution environment for executing target code. Such a computer program can control the host data processing device to emulate the architectural environment provided on the hardware device, which actually supports target code according to a specific instruction set architecture, even if the host data processing device itself does not support that architecture. The computer program may have tag inspection program logic, address translation (memory management) program logic, tag location address determination program logic, and / or data access to tag inspection program logic that emulate the functionality of the corresponding circuitry discussed above, including support for virtualized tagging modes, architectural suppression of tag address translation operations, tag location address determination, and / or data access to tag inspection discussed above. In the implementation scheme that simulates the functions of the corresponding hardware implementation in software, the reference to "physical address space" in the description of the corresponding hardware implementation scheme can be understood as referring to the simulated physical address space in the simulation. This is because when simulating the functions of the target instruction execution environment, the physical address space of that environment does not actually refer to the location stored in the host's hardware memory, but can be further mapped to the virtual address space used by the host data processing device.

[0144] For example, such emulation programs can be useful when executing legacy code written for one instruction set architecture on a host processor that supports different instruction set architectures. Additionally, emulation can allow software development for a newer version of the instruction set architecture to begin before the processing hardware supporting the new architecture is ready, because executing the software on a emulation environment allows software testing to be performed in parallel with ongoing development of the hardware that supports the new architecture. Emulation programs can be stored on a storage medium, which can be a non-transitory storage medium.

[0145] Specific examples are illustrated below with reference to the accompanying diagram.

[0146] Figure 1An example of a data processing device 2 is illustrated, which may be, for example, a processor, such as a central processing unit (CPU). Device 2 includes an instruction fetch / decode circuit 4 for fetching program instructions from an instruction cache or memory for execution by an execution circuit 16, and for decoding the instructions to generate control signals for controlling the execution circuit 16 to perform the operations represented by the instructions. The execution circuit includes multiple execution units 20, 22, and 28 for executing various types of instructions with reference to register states stored in register 14. For example, the execution circuit 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 non-sequential jumps in the program flow, and a load / store unit 28 for performing load / store operations to load data from the memory system into register 14 or store data from register 14 into the memory system. The memory system may include one or more levels of cache and random access memory storage devices.

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

[0148] 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. Address mapping information is used to translate between virtual addresses in the virtual address space (used to identify the executable instruction to be fetched and / or the 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 instruction and / or data). Memory attribute information specifies permissions or memory region attributes used to control whether a given memory access request is allowed to access information at the corresponding memory address and / or to control how memory access operations to that address are handled within CPU 2 or in the memory system itself. The translation table structure is set by software executing on device 2. The software can write translation table entries of the translation table structure to the memory system and set the base address stored in the base register of MMU 6 to indicate the location where the translation table structure is accessible. Updates to the base address register can be restricted to software executing 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 hypervisor-level software may be allowed to update the base address register).

[0149] MMU 6 includes one or more Translation Lookahead Buffers (TLBs) 8 for caching information derived from translation table structures stored in the memory system, such that future memory accesses that can reuse translation table information already obtained from the memory system by previous accesses can be processed faster than if the same information must be retrieved from memory again. If the required information is not available in TLB 8 for a given memory access, table traversal circuitry 12 can perform a translation table traversal operation to issue one or more memory access requests to the memory system to locate the required translation table information. In some examples, such a translation table traversal operation may involve a series of dependent memory accesses to traverse multi-level translation tables, where higher-level tables in the translation table structure include pointers to entries in lower-level tables.

[0150] like Figure 2As shown, in some examples, MMU 6 can support a two-stage address translation mechanism, where the translation between virtual address space 40 and physical address space 52 includes a first-stage address translation and a second-stage address translation. The target address for a given memory access operation is specified by instruction fetch circuit 4 or execution circuit 16 as a target virtual address 42 in virtual address space 40. In the first-stage address translation, based on address mapping information defined in stage 1 translation table structure 44 (which may include multi-level tables as mentioned above), the target virtual address 42 is mapped to a target intermediate address 48 in intermediate address space 46. In the second-stage address translation, based on address mapping information defined in stage 2 translation table structure 50 (which may also include multi-level tables), the target intermediate address 48 is mapped to a target physical address 54 in physical address space 52. The stage 1 translation table structure 44 can be controlled by the operating system, and the stage 2 translation table structure 50 can be controlled by the hypervisor (i.e., the update of the base address register used to provide the base addresses of the stage 1 translation table 44 and the stage 2 translation table 50 can be restricted to being performed by instructions executed with operating system-level privileges or higher (for the stage 1 translation table base address) or by instructions executed with hypervisor-level privileges or higher (for the stage 2 translation table base address)).

[0151] Two-stage address translation facilitates virtualization where multiple different guest 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 guest operating system can behave as if it were a unique operating system, and from the operating system's perspective, the intermediate addresses generated in the Stage 1 translation can appear as physical addresses referencing memory system locations. However, since different guest operating systems may have specified the same intermediate addresses for different data items used by the respective operating system or applications managed by the operating system, the hypervisor can set up a Stage 2 translation table 50 for each guest operating system to ensure that the same intermediate address value specified for different guest operating systems can be mapped to different physical addresses in the physical address space 52 depending on which guest operating system is active. The hypervisor can update the Stage 2 base address register identifying the location of the Stage 2 translation table 50 during context switching between guest operating systems (similarly, the operating system can update the Stage 1 base address register identifying the location of the Stage 1 translation table 44 during context switching between applications to manage switching between multiple different translation table structures).

[0152] The translation table entry that provides the stage 1 or stage 2 address mapping for generating intermediate addresses in stage 1 or physical address 54 in stage 2 is called a page descriptor (distinguished from higher-level table descriptors, which do not provide address mappings but instead provide pointers to subsequent levels of the table structure). Figure 3 As shown, in addition to the address mapping for translation (e.g., an indication of an intermediate address mapping for a stage 1 translation or a physical address mapping for a stage 2 translation), page descriptor 60 may also specify memory attribute information indicating the characteristics of the address space region corresponding to the page descriptor 60 and / or information indicating permissions for defining rules for controlling whether various types of memory access operations are allowed to access the address space region corresponding to the page descriptor 60. Figure 3 As shown, while some memory attribute information can be directly specified in page descriptor 60, page descriptor 60 can also specify a reference to an indirect table 62 that provides 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. An indirect table entry identifier directly encoded in page descriptor 60 indicates which entry in indirect table 62 specifies the attribute information for the associated address space region (page). A given entry in indirect table 62 can have a larger capacity to store additional attribute information than would be possible to store in page descriptor 60 itself. The use of 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, the 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 should be understood that when memory attribute information is mentioned below, this information may be specified directly or indirectly in the translation table entry 60 used to identify memory attribute information (indirect specification refers to the case where the translation table entry 60 contains an index value that identifies an entry of the indirect table 62 that provides the required memory attribute information).

[0153] In addition to supporting such Figure 2 In addition to the two-stage address translation mechanism shown, MMU 6 can also support address translation involving a single stage (directly from virtual address to physical address, using a method similar to...). Figure 2 The stage 1 and stage 2 transition tables 44 and 50 (a set of transition tables, possibly multi-level) show other transition mechanisms. In cases where multiple transition mechanisms are supported, which particular transition mechanism is used at a given time may depend on, for example, the processor's current operating state. For instance, the current operating mode, exception / privilege level, and / or other control information stored in register 14 can be used to determine the transition mechanism currently in use.

[0154] Refer again Figure 1Device 2 includes a tag checking circuit 34, which supports tag checking operations performed for memory access operations executed by 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 10 and a data access to tag checking circuit 32. Although Figure 1 An example is shown where the tag inspection circuit 34 and data access to the tag inspection circuit 32 are separate from the load / store unit 28 and the MMU 6; however, other examples may provide these components as part of the load / store unit 28 or the MMU 6. Similarly, although in Figure 1 In the example, the tag location address determination circuit 10 is shown as being within the MMU 6, but the tag location address determination circuit 10 may also be provided separately from the MMU 6.

[0155] Software 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. ® .

[0156] Some higher-level programming languages ​​(such as Java) are considered memory-safe languages ​​because they include runtime error detection checks to inspect for certain errors related to memory access. In contrast, memory-unsafe languages ​​(such as C and C++) do not include such runtime error checks. The continued prevalence of memory-unsafe languages ​​means that code compiled according to a given instruction set architecture may contain a large number of memory-related errors that could be easily exploited by attackers or other malicious parties. Such errors may include:

[0157] • Boundary violation, where the array index provided by the code exceeds the array's legal boundaries;

[0158] • Use-after-free error, which means accessing a memory location only after the memory location has been deallocated or freed;

[0159] • Use-after-return, where memory access to the address associated with variables used within the function (such as values ​​on the stack) is performed after the function has returned;

[0160] • Use-out-of-scope errors, where a variable is accessed outside the scope in which it is declared; and

[0161] • Use-before-initialisation error, where the memory address associated with a variable is accessed before the variable is initialized.

[0162] These are just some examples of memory-related errors that can lead to unpredictable behavior and potentially provide avenues for exploitation by attackers. Therefore, it may be desirable to provide architectural support within the instruction set architecture supported by a given processing device to aid in the runtime detection of certain categories of memory security errors.

[0163] One method for preventing certain types of memory use errors discussed above could be to provide allocation tags stored in the memory system that are associated with blocks of one or more memory locations. When a tag-checked memory access operation is requested based on a target address calculated from a given address operand (e.g., a register operand stored in a register in register 14), the memory access circuitry can compare the address tag associated with the given address operand with the allocation tag associated with a data item stored in the memory system at a location identified by the target address. The memory access circuitry 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 the memory access is allowed to proceed successfully or whether subsequent operations can proceed successfully, or it can be used to simply report (e.g., in an error log or by setting an indication in a register) while allowing the memory access to continue normally. The allocation tag may also be referred to as a "protection tag," a "memory coloring tag," or a "memory security check tag."

[0164] Such tag checking can be useful because, for example, software based on memory-insecure languages ​​(such as C or C++) can set allocation tags associated with blocks of data items to be accessed by the expected code to specific values ​​when initializing memory regions, and can associate the corresponding address tag values ​​with address pointer operands used to generate the target addresses for accessing those blocks. Different allocation tag values ​​can be assigned to adjacent memory regions intended for different purposes, such that if an address pointer intended for accessing one of those regions is accidentally set to a value that causes access to another region, an error can be detected based on tag mismatch. Therefore, if a memory usage error occurs, and for example, the use of an address pointer is out of range or beyond the initialized valid range, the allocation tag associated with the accessed data item may not match the address tag associated with the address operand used to access that data item, and then in this case, an indication of whether a match was detected can be used to trigger an error handling response or error reporting mechanism. The specific response taken may depend on the specific needs of the software being executed or on the specific microarchitecture implementation of the architecture. Therefore, even if a high-level language does not have a means to perform runtime error checking to prevent memory access errors, an ISA for compiling code can include architectural features for performing such checks.

[0165] Figure 4The concept of a tag checking operation performed by tag checking circuit 34 in response to a tag checking memory access is schematically illustrated. The address space used to refer to memory locations within the memory system can be logically divided into multiple blocks 70, each assigned a corresponding allocation tag 72. For example, the address space block corresponding to a tag 72 can be, for example, 16 bytes. As further described below, there can be multiple ways to associate a manageable block 70 with its corresponding tag 72, based on a virtualization tagging scheme (where address translation functionality of MMU 6 is used to identify separate physical addresses for data items in a given block 70 and their corresponding allocation tags 72), or based on a physical tagging scheme (where the same physical address is used to identify both data items 70 and their corresponding allocation tags 72, and the memory system is responsible for managing the storage of allocation tags 72 and providing mechanisms for retrieving data items and / or tags associated with a given physical address). Therefore, there is flexibility in implementing the association between data items 70 and their corresponding allocation tags 72 in multiple ways, but overall, data items in each block 70 of the memory address space can be associated with a corresponding allocation tag value 52. The specific value assigned to a given allocation tag for a given block 50 in the address space is arbitrary (e.g., selected by software) and can be controlled based on the execution of tag setting instructions supported in the instruction set architecture (ISA) supported by processor 2. Similarly, instructions for setting address tags for a given address pointer operand can be supported in the ISA.

[0166] Therefore, when a memory access requires tag checking, the address tag 80 (which is associated with the address operand 82 used to derive the target address of the data item to be accessed) is compared with the allocation tag 72 (which is associated with the data item block 70 containing the data item 84 corresponding to the target address). For example, in Figure 4 In the middle, the target address points to data item B1 (in Figure 4 (This is marked as 84). Therefore, the allocation tag B associated with the data item block B containing data item B1 is obtained from the memory system and compared with the address tag 60 associated with the target address 62. Figure 4As shown at the top, address tag 80 can be determined as a function of selected bits of the address operand used to compute the target address. Specifically, address tag 80 is derived from the portion of address bits in address operand 82 that are not used to indicate the target address for computed data item 84. For example, in some ISAs, the top portion of the address value's bits may always have a fixed value, such as sign extension (all 0s or all 1s), and thus the address operand can be tagged with address tag 80 by overwriting these unused bits with arbitrary tag values. For example, a specific address tag value may be chosen by the programmer or compiler. Address tag 80 and allocation tag 72 can be a relatively small number of bits (e.g., 4 bits), so they do not need to occupy too much space in memory and at the target address. Providing a 4-bit tag space (i.e., 16 possible tag values) is generally sufficient to detect many common types of memory access errors.

[0167] Therefore, when performing a tag-checked memory access, the tag-checking circuit 34 compares the address tag 80 obtained from the address operand with the allocation tag 72 obtained from the memory system and determines whether they match. The tag-checking circuit 34 generates a match indication indicating whether the address tag 80 and allocation tag 72 match. For example, this match indication could be a fault signal generated in the event of a mismatch between address tag 80 and allocation tag 72, an indication placed in a status register indicating the existence of a match, or an entry added to an error report to indicate the address for which an error was detected and / or the instruction address that triggered the error. The specific form of the generated indication of whether a match was detected between the allocation tag and the address tag may vary depending on the specific implementation.

[0168] In some cases, tag checking operations may include controlling whether memory access to data items associated with a target address is allowed based on whether a match is detected between the assignment tag and the address tag.

[0169] However, in other examples, tag-checking memory access may include 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 a separate read request to memory, separate from the request for the corresponding data item. Therefore, if the memory access to the data item is delayed until the allocation tag and address tag have been compared, the processing of the actual memory access may be delayed, and it may be desirable to perform a memory access to the data item before the allocation tag is available, and then check the allocation tag later when it becomes available.

[0170] In one example, the indication of whether a match was detected could be a signal representing a fault condition, generated when a mismatch is detected between the allocation tag and the address tag. For example, memory access circuitry could signal a memory fault similar to those generated in cases of access permission violations or access to an unmapped address, or it could indicate a different type of fault condition. The fault signal could trigger processing circuitry to execute an exception handling routine in response to the detected fault, and could prevent successful memory access (or, if the tag mismatch is not detected until some time after the memory access has been initiated, prevent program code from progressing beyond the point where the tag mismatch was detected).

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

[0172] Another option for reporting whether address labels and allocation labels match or not could be to log the information in an error log associated with the executed code segment, which tracks any allocation label errors detected throughout the code segment. For example, in response to a mismatched allocation label and address label, the instruction address triggering a mismatched target address or an instruction triggering a mismatched memory access could be logged in the error log, which could be stored, for example, in memory. In this case, instead of performing any specific action to prevent the code from operating, the error can simply be logged. The error log can then be made available to the software vendor to help them review errors in the code and identify areas of development for correcting errors in subsequent versions of the software.

[0173] Therefore, it should be understood that there are a range of ways in which a tag match / mismatch indication can be generated by memory access circuitry (and thus a range of possible error handling responses).

[0174] In some examples, each addressable data item may have its own assignment label (e.g., Figure 4 Each block 70 shown may include a single byte of memory.

[0175] However, in practice, setting a separate allocation tag for each addressable data item (e.g., each byte in the memory address space) may be too costly, and associating each allocation tag with a block of multiple bytes in the address space may be more efficient. In this case, a block 70 comprising several adjacent bytes in memory (each byte addressable individually by a different address corresponding to a data item within the block 70) can share the same allocation tag, which may be sufficient for detecting common forms of memory-related errors.

[0176] Address labels can be associated with target addresses in different ways. In some cases, address labels can be specified separately from the target address; for example, a separate register can be specified using a label-checked memory access instruction that triggers the label-checked memory access operation. However, in other examples (such as...) Figure 4 As shown), the address label can be determined as a function of one or more selected bits of the target address. That is, the address label can include information derived from a portion of the target address itself. Typically, while instruction set architectures can support addresses with a certain number of address bits (e.g., 64 bits), in practice, a given hardware device may not require so much memory capacity that it will use all possible addresses that can be represented using that number of address bits. For example, given current trends in device usage, there is no need to provide 2... 64 Each memory address is a separate addressable location. Therefore, some bits of a memory address may actually be unused and may always have the same value, or be set to 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 therefore be reused to represent an address tag or to derive the value of an address tag, avoiding the need to access a separate register to obtain the address tag, and also making it easier to track the correspondence between the address and its corresponding address tag (because the address tag can be transferred along with the address by definition whenever the address is manipulated or moved between registers).

[0177] In the example where a portion of the target address is used to determine the address tag, it's important to note that this address tag is different from the tag portion of the target address, which can be used by the cache to derive a cache tag for determining whether information associated with the target address is stored within the cache. Many caching schemes store the tag portion of the address of a cached data slice along with the data in the cache, so that when searching the cache for a given address, this address portion can be compared with the cache tag stored along with the cached data to determine if the cached data actually corresponds to the desired address. However, in this case, the tag portion of the address compared with the tag stored in the cache will be derived from a portion of the address portion that actually identifies the specific data item that needs to be accessed; that is, by definition, changing the cache tag portion of the address will cause the address to point to a different addressed location within the memory system and cause read / write operations to operate on different data items. In contrast, when address tag 80 is used for tag-checking memory operations, the memory access circuitry can select the location storing the desired data item independently of address tag 80. That is, even if address tag 80 within the address operands has different values, the location in memory referenced by the target address can still be the same. The choice of the location in memory to access for the required data item depends only on the portion of the target address other than address label 80. This allows the compiler the freedom to set the address label associated with a particular address to any value to match the corresponding allocation label value of the relevant data block already allocated to the memory system.

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

[0179] However, in other implementations, all memory accesses can be considered as tag-checked memory accesses. Therefore, in some cases, any memory access instruction can be considered to trigger the memory access circuitry to perform a tag-checked memory access operation as discussed above.

[0180] However, even if all memory access instructions are interpreted as tag-checked memory access instructions, there may still be other ways in which the instruction set architecture can selectively disable tag comparison for certain operations. For example, control parameters within the processor's control register can selectively disable tag comparison.

[0181] Furthermore, as explained below, memory attribute information, directly or indirectly encoded in the translation table entry associated with the target address, can specify whether the accessed memory region is a tagged memory region requiring 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 can depend on the memory attribute information set for the target address in the translation table entry accessed by MMU 6.

[0182] Another option is to interpret a value of the address label or allocation label as an "all-match" value, such that an "all-match" label value is considered to match any possible value of the relative label. This also effectively disables the effect of label comparison, so that no error is reported regardless of whether the address label matches the allocation label. Therefore, in some cases, the comparison in label checking can be to detect whether there is a mismatch between allocation label 72 and address label 80, but not all cases where the values ​​of allocation / address labels 72 and 80 are different need to be detected as mismatches that trigger an error handling response, because if one or both of allocation label 72 and address label 80 are "all-match" labels, no error handling response needs to be triggered.

[0183] Figure 5 , Figure 6 and Figure 7 Some example use cases are illustrated, showing how support for such tag checks can help capture memory safety usage errors, such as out-of-scope use or use after release errors. Figure 5 This illustrates the steps performed by software (e.g., an operating system) responsible for allocating memory regions for a specific purpose to set an allocation tag value associated with the allocated memory region. Figure 5 As shown in the left portion, there initially exists a free memory region that is not currently allocated for any particular purpose. This region is initially assigned an allocation tag value of 4 (in this example, each 16-byte data granule has a separate allocation tag value). After a memory allocation operation in which a portion of this free memory region 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 region to a different value of 6, which is different from the allocation tag value of 4 for the surrounding memory regions. When the memory allocation software later deals with the same region, it updates the allocation tag value of the deallocated region to a value different from the value before deallocation (tag = 6) (tag = 7). Figure 5The specific allocation tag values ​​shown are arbitrarily chosen (for example, the new allocation tag value 7 for a deallocated memory region is arbitrary and can be replaced by 2 or 3 or any other value other than 4 or 6 (these values ​​are the allocation tags for adjacent regions and the allocation tag for the deallocated region before deallocation). However, in general, the allocation software will be designed to ensure that the allocation tag value associated with a given memory region is updated when allocating or deallocating that memory, such that the allocation tag value changes when transitioning between free and allocated regions or when transitioning between allocated regions allocated for different purposes.

[0184] Figure 6 Examples have been provided based on Figure 5 In the case where the middle part sets the allocation tag value of the memory region (before deallocating the memory region allocated with allocation tag value 6), how can tag checking be used to detect out-of-bounds use of a pointer? A given 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 generating the software being executed intends to use this pointer to reference the data region 86 assigned the allocation tag value 6, so at allocation time, the pointer "ptr" has similarly been assigned the address tag value 6. Therefore, for the correct use of the pointer "ptr" within the boundary, the address calculated based on the pointer falls within the data region 86, the allocation tag 72 obtained from the memory system has the value 6, and the address tag 80 obtained from the address operand (pointer) used to calculate the target memory address also has the value 6, thus generating a tag matching indication without triggering any error response.

[0185] However, sometimes the same pointer "ptr" can be used out of bounds to generate a target address in another memory address region 88 that is different from the region 86 intended to be accessed using that pointer. 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 process. This 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-safe software, it is best for the software developer or compiler to ensure that the software includes one or more instructions to check for buffer overflows before pushing further data onto the buffer. However, some software developers may forget to include such safety checks in their software code, and thus, in cases where too many instances of code executing functions for pushing data onto buffers occur, the address pointer used to track the next point in the buffer where data should be inserted may exceed the boundary of the region 86 allocated to the buffer. This can introduce the risk of corrupting other data in memory regions outside of the region 86 allocated to the buffer (in this example, the region outside the buffer is a free region, so the error may not necessarily lead to incorrect functionality, but this region may also have been allocated to other data that could be corrupted due to the out-of-bounds use of the pointer "ptr"). This poses a risk because (although buffer overflows themselves may not always be a problem) it can be exploited by attackers who aim to disrupt the operation of a victim's software or cause a branch to malicious gadget code, giving the attacker access to information they would otherwise have access to. However, by supporting memory tagging, this out-of-bounds use of the pointer "ptr" can be detected using tag checking, since the address tag value 6 will not match the allocation tag value 4 of the address space region 92 accessed using the pointer. Therefore, an indication of tag mismatch can be generated and used to prevent memory access from taking place and / or an error report can be generated that can be returned to the software developer to help them patch vulnerabilities or potential errors in their code.

[0186] Similarly, Figure 7This illustrates that even when a pointer is used within its intended address boundaries, a timing error can still occur based on the point in time at which the pointer is used to control memory access to a given address space region. A given address pointer "ptr" might have been created for a limited period of time when data is stored in a given memory region 86, but after that memory region has been deallocated, the pointer might still be in memory and could be accidentally used to calculate the target address of another memory access, potentially compromising data now stored in the same memory region—data that should not be accessed using pointer "ptr". Since the allocation tag value is updated from 6 to 9 when deallocated to the designated data region 6, the use of a pointer generated before deallocation (which would be associated with address tag 6) can be detected based on the mismatch between address tag 6 and allocation tag 9, and again used to trigger an error report.

[0187] It should be understood that Figure 6 and Figure 7 Only a few of the types of memory usage errors that can be detected using such tag checks are shown, but in general, supporting the assignment of address tags to address pointers and storing allocation tags in memory associated with the corresponding data items can help capture memory security flaws, which can help software developers create more robust and secure program code.

[0188] Figure 8 The steps for a tag checking operation performed by tag checking circuit 34 are illustrated. At step 800, in response to a memory access instruction for tag checking, tag checking circuit 34 obtains address tag 80 from address operand 82, which is used to calculate the target address of the data item to be accessed in response to the memory access instruction for tag checking. Additionally, tag checking circuit 34 obtains allocation tag 72 from the memory system associated with the data item identified by the target address of the memory access instruction. At step 802, tag checking circuit 34 compares address tag 80 and allocation tag 72, and at step 804 detects whether a tag mismatch is detected. Generally, a tag mismatch can be detected when the address operand is not equal to the allocation tag. However, in some examples, a "full match" value can be supported, so if either the address operand or the allocation tag has a "full match" value, a tag match can be detected regardless of the value of the other tag. 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 full match value), then at step 806, it is not necessary to signal a tag mismatch error. If a label mismatch is detected, an error handling response is triggered at step 808. The error handling response may include signaling a fault and / or updating error log information.

[0189] To support the aforementioned tag checking, a mechanism is provided to support storing within the memory system an allocation tag 72 to be associated with a given data item stored in the memory system. Various different methods may exist to manage this association, using address translation functions provided by MMU 6 or using hardware within the memory system to identify the location where the allocation tag corresponding to the given data item is stored.

[0190] Figure 9 An example of using physical tags to associate allocation tags with their corresponding data items is shown. In this example, when locating the allocation tag associated with a given data item, the allocation tag is identified based on the same physical address used to identify the corresponding data item. Therefore, the address translation performed by MMU 6 does not require any special translation functions to generate the address of allocation tag 72. Instead, the address translation from virtual address to physical address to obtain the physical address of the data item is sufficient for any operation that requires the associated allocation tag 72 (e.g., a tag check associated with a memory access to check the tag of a data item, or a separate tag set or tag read instruction that writes to or reads allocation tag 72 without necessarily accessing the corresponding data item). Using this approach, the memory system supports a mechanism that identifies 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 in the memory system during tag access.

[0191] Memory systems can use various mechanisms to specify tag storage. For example... Figure 9As shown, one option is to implement separate physical memory units for storing data and tags, where the same physical address obtained during 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 assigned tag. Another option is to store the assigned tag value together with the corresponding data item in a common memory storage unit. For example, some memory storage units may include spare capacity for error correction codes associated with the stored data items. The error correction function may not always be in use, so the error correction code storage can be reused to store the assigned tag value. Another option is that within a given data physical memory unit used to store data items, a portion of that physical storage is partitioned and reserved for storing the assigned tag associated with the data item stored in that memory unit. The partitioned area can be fixed or variable. If a variable area is specified, some stored state information (e.g., a base address or table structure separate from the base address and translation table structure used by MMU 6) can be maintained in memory to identify which area of ​​the data storage device provides the tag associated with a particular data item. In the segmentation method, since the tag storage is part of the internal address space of the physical memory system (which can be addressed based on physical addresses), the physical storage location of the stored tags can also be mapped to a virtual address using the mapping information in translation tables 44 and 50. However, unlike the virtualized tagging method discussed below, in this case, the virtual address mapped to the tag storage will be translated into a physical address like any other data address; MMU 6 does not support tag-specific address translation separate from data address translation. If physical tags are used, the specific mechanism used by the memory system to maintain the association between data items and tags can be implementation-specific and may be invisible to the software executing on device 2.

[0192] Figure 10 and Figure 11An example of using virtualized tags to associate allocation tag 72 with its corresponding data item is illustrated. In these examples, the address translation function provided by MMU 6 is used to translate the data location virtual address (VA) identifying a given data item into separate physical addresses PA1, PA2 that identify the data item and its associated allocation tag, respectively. By supporting virtualized tag translation modes (where allocation tag 72 is assigned a different physical address than its corresponding data item (based on separate address translation mappings at at least one of stage 1 and stage 2 address translations)), this simplifies the implementation of physical memory significantly, as the memory system does not need to implement any special mechanisms for managing tag storage. From the memory system's perspective, the allocation tag appears to be a data item; therefore, for a memory access that requires tag checking of both a given data item and its associated tag value, two separate memory access requests can be issued to the memory system: one memory access request specifying the data location physical address PA1 that identifies the location of the stored data item, and another memory access request specifying the tag location physical address PA2 that identifies the location of the stored allocation tag. The MMU (Address Translation Unit) supports the following mechanisms: These mechanisms enable software to define translation table structures to control the translation of data location VA to individual data location physical addresses PA1 and tag location physical addresses PA2.

[0193] exist Figure 10 In the example, the use of virtual tags, such that the target address of a data item is mapped to separate addresses for the data item and the tag, is stage 1 address translation. In this example, two separate stage 1 address translation mappings are used to obtain the corresponding data location intermediate address IPA1 and tag location intermediate address IPA2 corresponding to the specified data item virtual address VA. Each of these intermediate addresses IPA1, IPA2 can then be further translated in stage 2 into the corresponding physical addresses PA1, PA2 for accessing the corresponding data stored in the memory system and allocating the tag. Figure 10 As shown by the dashed lines, one way to control the use of separate Stage 1 translation maps for data translation and tag translation is to, for tag translation, apply a modification to the data location VA to generate a modified VA that identifies the location of the assigned tag in the virtual address space, and then use this modified VA as input to the lookup translation table structure, such that separate entries of Stage 1 translation table 44 are used for tag address translation compared to the entries used for data address translation. Other examples may not apply this address modification, but instead choose a different set of translation tables 44 (based on different base registers) depending on whether the Stage 1 address translation is performed for data item access or tag access.

[0194] On the other hand, Figure 11In the example, the use of intermediate markers to map the address identifying the data item to separate addresses for the data item and the tag in the stage address translation is stage 2 address translation. In this example, stage 1 address translation translates the VA of the data item to the corresponding intermediate address IPA1 (where the same stage 1 address translation mapping is shared by both the data item and the tag), but stage 2 translation chooses separate stage 2 address translation mappings to generate separate physical addresses PA1 for the data item and PA2 for the tag. Similarly, as Figure 11 As shown by the dashed lines, for tag address translation, some examples may apply an address modification operation to determine the tag location intermediate address IPA2 within the intermediate address space based on the data location intermediate address IPA1, such that a separate entry in the stage 2 translation table 50 is used for tag address translation compared to using the same entries in stage 1 translation table 44 for data address translation. Other examples may not apply this address modification, but instead choose a different set of stage 2 translation tables 50 (based on different base registers) depending on whether the stage 2 address translation is performed for a data item access or a tag access.

[0195] like Figure 10 As shown (for the sake of brevity, this is not also included) Figure 11 As shown in the figure, but also applicable to intermediate tags), for an example where the number of bits in one of the allocation tags is less than the number of bits in an addressable memory location (e.g., one byte), two or more allocation tags can be stored at the same tag location physical address PA2, so a portion of the data location address VA or IPA1 can be used to select between tags stored at the same tag location physical address PA2.

[0196] Therefore, generally speaking, virtualized label translation modes can be supported, where, for a given stage of address translation mapping an address from a first address space to a second address space, the data location first address in the first address space is translated into separate data location second addresses and label location second addresses in the second address space. The data location first address 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 label depend on the separate data location second addresses and label location second addresses, respectively. For example, Figure 10 The example shown uses virtual tags. In this stage of address translation, which is stage 1 translation, the first address space is virtual address space 40, the second address space is intermediate address space 46, the first data location address is the data location virtual address, and the second data location address and the second tag location address are intermediate addresses. These intermediate addresses are further translated into their corresponding physical addresses in the second stage of address translation. For example... Figure 11In the example shown using intermediate tags, the first address space is intermediate address space 46, the second address space is physical address space 52, the data location first address is intermediate address IPA1 generated in stage 1 translation and corresponding to the data location virtual address, and the separate data location second address and tag location second address generated in stage 2 translation are physical addresses PA1 and PA2 used to identify the data and allocate the corresponding storage location of the tag in memory.

[0197] Some examples may support at least one virtualization label conversion mode, for example, based on Figure 10 The virtual tag pattern shown and / or Figure 11 The intermediate tag mode is shown. Some examples may support both virtual tags and intermediate tags, making it selectable, for example, based on a control state set by software, which mode is applied. The advantage of supporting at least one virtualized tag transition mode is that it eliminates the need for a physical memory implementation mechanism for managing the storage of allocated tags 72. This simplifies the memory system implementation.

[0198] Even if the memory system does support a mechanism for managing the storage of allocation tags 72, using address translation to identify the tag storage location for certain data items can help support more efficient use of available physical memory capacity. The software setting up the address translation table can more clearly know whether a particular data item block might require tag checking, thus avoiding setting translation table entries that map allocation tags to physical memory for tags corresponding to address regions of data items that are unlikely to need tag access. Therefore, unlike the physical memory system—which may conservatively assume that any data item might require physical storage for its corresponding tag, or may have a block of physical storage statically defined to reserve its allocation tags—the software managing the address translation mapping has greater 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 physical storage based on their corresponding valid translation table entries, and which allocation tags may only be nominally associated with their corresponding data items but not allocated physical memory at a given time (e.g., using paging mechanisms to move pages in / out of external storage, so that allocation tags are allocated physical memory only when actually needed, to more efficiently utilize the limited memory capacity of the physical memory system). Furthermore, the software can selectively map address addresses such that, during address translation at a given stage from a first address space to a second address space, if two or more data item blocks are to share the same allocation tag value, the translation entries accessed for tag address translation of two or more different data item blocks can map the corresponding tag location address to the same second address in the second address space. This means that less physical memory needs to be allocated for tag storage compared to a method where tags / data share the same physical address and the memory system cannot benefit from any hints provided by the software regarding whether tags of different physical data address blocks have the same allocation tag value (and therefore separate physical storage in memory is allocated for each different data item "particle" (where a "particle" is a data item block sharing a single allocation tag), since multiple data item blocks can share the same tag storage location in physical memory.

[0199] It can provide a virtualization-only label conversion mode (e.g., Figure 10 and Figure 11 (One or both of the virtual / intermediate marker modes shown) but not supported as Figure 9 The physical marker shown is for MMU 6. However, other examples may also support the use of, for example... Figure 9The options for physical tagging are shown. Supporting flexibility in which approach to use can be useful, as it simplifies software implementation where the memory system does indeed support a mechanism for locating the assigned tag associated with a given data item based on the same physical address used to identify both the data item and the tag. This simplifies software implementation by reducing the overhead of managing separate translation table mappings for data and tags. Therefore, for a given stage of address translation from a first address space to a second address space, MMU 6 can choose between a first tag translation mode and a second tag translation mode. In the first tag translation mode, any translation performed for a tag access simply reuses the same translation as the corresponding data item access. In the second tag translation mode, the translation performed for a tag access involves a separate tag address translation operation, separate from the data address translation operation, where the tag address translation operation and the data address translation operation use different translation table entries to provide the address mapping for a given stage of address translation. Figure 10 For example, stage 1 transformation uses the second label transformation pattern, and stage 2 transformation uses the first label transformation pattern. For Figure 11 For example, stage 1 transformation uses the first label transformation pattern, and stage 2 transformation uses the second label transformation pattern. For Figure 9 For example, both Stage 1 and Stage 2 transitions use the first tag transition mode. The first tag transition mode can be considered as transitioning a given input address based on a data location address transition operation, and the second tag transition mode can be considered as transitioning a given input address based on a tag location address transition operation. The selection between the first and second tag transition modes can be based on control information set by software, such as configuration values ​​in a control register.

[0200] When virtualized label translation mode is supported, the label positioning address translation operation for obtaining the physical address PA2 of the assigned label requires a separate translation table entry, compared to the data positioning address translation operation used to obtain the physical address PA1 of the corresponding data item. Utilizing Figure 10 The virtual tagging method, in stages 1 and 2, can use tag conversion table entries created for converting modified VAs to IPA2 and IPA2 to PA2, which are separate from the entries used for converting VAs to IPA1 and IPA1 to PA1. Utilizing Figure 11The intermediate tagging method shown in Stage 2 allows the use of a separate translation table entry to convert IPA2 to PA2 for tag access. This separate translation table entry is distinct from the entry used to convert IPA1 to PA1 for data access. Therefore, performing tag location address translation may introduce additional risks of failures that would not occur with non-tag-checked data access. This is because if the operating system or hypervisor has not configured appropriate translation table entries for tag location address translation, or if the translation table entry accessed in tag location address translation specifies a permission that the memory access operation is not satisfied with, a memory failure may occur, leading to processing interruption. To reduce performance costs, it may be desirable to perform accesses to memory regions that do not require tag checking without incurring the increased risk of failures associated with performing tag location address translation.

[0201] To address this issue, the translation table can define attribute information, either directly or indirectly, within the attribute / license information encoded in the translation table entry 60 for the address space region used to provide a given data item. This attribute information indicates whether the region is a tagged region (for which access to the region should be considered a tagged memory access requiring tag checking) or an untagged region (for which tag checking is not required). In some examples, a special attribute type can indicate whether the region is tagged or untagged. However, the tagged / untagged status can also be inferred from one or more other attribute types. For example, the 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 being partially executed and subsequently restarted, and / or reordered compared to the order in which memory access operations were requested, whereas normal memory types are not subject to any of these restrictions). Furthermore, the attribute information can indicate cacheability attribute information, which indicates whether data from the corresponding address space region should be cached once accessed from main memory. For example, cacheability attribute information can indicate whether a region is a write-back cacheable region (for which the cache is allowed to hold dirty data that has been updated but not yet written back to memory from a backing store), a write-through cacheable region (for which any update to cached data is immediately propagated to the backing store in memory), or a non-cacheable region (for which data should not be cached in any cache). In some examples, the marking status of an address space region can be determined when the region's attribute information indicates that the region is a write-back cacheable ordinary memory region. Any region with attribute information indicating that it is not a normal write-back cacheable region can be considered unmarked.

[0202] Therefore, based on attribute information associated with the address space page containing the accessed data item, MMU 6 can determine whether tag-location address translation needs to be performed on the architecture to obtain the tag-location physical address of the associated assigned tag. If the memory access instruction targets an untagged region of memory, tag-location address translation is not performed on the architecture. For example, either tag-location address translation is not performed at all, or it is performed but any architectural effects of the translation are suppressed—the system's architectural state remains the same as if no translation were performed. For example, if the translation is suppressed on the architecture (but not necessarily in practice), a fault may not be triggered based on the translation, architecturally visible performance counters (if provided) may not be updated based on the translation, and memory access may not be triggered based on the address obtained through tag-location address translation.

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

[0204] At step 1200, a tag-check memory access instruction specifying a target data address is detected. The tag-check memory access instruction can be any instruction requesting 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 for the data item identified by the target data address, the instruction causes the tag-check circuit 34 to perform a tag check between the address tag associated with the address operand used to complete the target data address and the allocation tag associated with the target data item stored in the memory system. In some examples, a dedicated class of tag-check memory access instructions, separate from non-tag-check class memory access instructions, can be provided, such that... Figure 12 The steps can be performed on tag-checked instructions rather than on non-tag-checked memory access instructions. In other examples, instruction encoding may not distinguish between tag-checked and non-tag-checked memory access instructions, and all data item access memory access instructions can, in principle, act as tag-checked memory access instructions; however, whether tag checking is actually performed may depend on memory attribute information, as described below. Furthermore, in some cases, whether a given memory access instruction is a tag-checked memory access instruction may depend on mode indicators or other tag checking enable / disable control values ​​that can be used to control whether tag checking is enabled or disabled.

[0205] At step 1200, in response to a memory access instruction for tag checking, MMU 6 obtains memory region attribute information specified by the translation table entry associated with the target data address. This attribute information can be obtained by performing a table traversal operation via table traversal circuit 12 to trigger a memory access operation for traversing stage 1 translation table structure 44 and / or stage 2 translation table structure 50 (following any trace of pointers between the multi-level tables in translation table structures 44, 50) and locating the page descriptor 60 corresponding to the target data address. Alternatively, if the attribute information corresponding to the target data address is already cached in TLB 8, the memory region attributes specified by the translation table entry associated with the target data address can be obtained from TLB 8 instead of performing a table traversal operation.

[0206] At step 1202, MMU 6 determines which memory region type the memory region attribute associated with the target data address specifies. If the target data address is in a non-tag memory region (e.g., any region other than a normal write-back cacheable region), then at step 1204, MMU 6 determines that tag-location address translation is not required on the architecture. Therefore, either tag-location address translation is not performed at all, or, if it is performed speculatively, a failure will be detected even if tag-location address translation is performed on the architecture (e.g., in cases where tag-location address translation is performed on the architecture). Figure 10 and Figure 11 In cases where no valid address translation entries are defined for the mapping "Modified VA->IPA2" or "IPA2->PA2" shown in the virtualization translation mode, error detection may occur, and memory failures will not be triggered based on tag-based address translations. Therefore, by suppressing tag-based address translation failures when accessing untagged memory regions, this reduces the overhead for software developers because when the virtualization translation mode is in operation, it is not necessary to configure translation table entries for the addresses of the allocation tags corresponding to each data item address. The software only needs to configure allocation tag mapping translation table entries for those data addresses that actually require tag checking. For accesses to untagged memory regions, at step 1206, MMU 6 or tag checking circuit 34 determines that tag checking is not required.

[0207] If the target data address is determined to be in a tag memory region (e.g., a normal write-back cache region), then at step 1208, MMU 6 determines whether virtualization tagging is currently enabled (e.g., Figure 10 and Figure 11 (One of the virtual and intermediate tagging methods shown). As follows about Figure 18 and Figure 19Further discussion suggests that determining whether a virtualization tagging mode is active can be done using the Tag Transition Control Information (VTE) and IPMTE stored in the control register.

[0208] If virtualization tagging is enabled and the access is to a tag memory region, then at step 1210, the MMU6 performs a tag location address translation operation on the architecture to obtain the translated tag location physical address PA2, which identifies the location of the allocated tag corresponding to the data item identified by the target data address specified by the memory access instruction checked by the tag. The steps for performing the tag location address translation are as follows. Figures 14 to 17 and Figure 24 The example is described in more detail. If any fault condition is detected during the tag-location address translation operation, a memory fault is signaled, which may cause an interruption of the current processing and cause processor 2 to switch to executing instructions from an exception handler that can investigate the fault and determine how to continue (e.g., triggering the operating system or hypervisor responsible for the stage address translation where the fault occurred to configure translation table entries for the required address mapping (if such mapping has not been provided previously)).

[0209] Assuming no memory fault is detected during the tag location address translation operation, at step 1212, the load / store unit 28 issues a memory access request to the memory system specifying the tag location physical address PA2 obtained by MMU 6 during the tag location address translation operation. This tag access memory access request specifying PA2 requests access to the allocated tag, separate from the data access memory access request issued to the memory system requesting access to the corresponding data item at the specified physical address PA1. At step 1214, when the memory system returns the data word corresponding to the tag location physical address PA2, the load / store unit 28 or the tag checking circuit 34, based on tag selection information determined from the target data location address identifying the desired target data item, selects the allocated tag among those included in the returned data word (e.g., in...). Figure 10 In the example shown, a selection is made between two assigned labels. For example, label selection information could be referenced below. Figure 22 and Figure 23 Interpreted nibble selection information. At step 1216, the tag checking circuit 34 uses the allocation tag selected at step 1214 and the address tag 80 associated with the address operand of the memory access instruction (e.g., address tag 80 can be extracted from the higher bits of the address operand, such as...). Figure 4 (As shown) to execute Figure 8 Tag checking operation.

[0210] On the other hand, if the memory access is for a data item in a tagged region of memory, but virtualization tagging is currently disabled, then at step 1218, tag-based address translation is not performed on the architecture, because in this case, tag translation is based on... Figure 9 The physical tagging mechanism shown allows the allocation tag 72 associated with the target data item to be located based on the same physical address PA1 as the physical address of the data item itself. Both the allocation tag and the data item are associated with the same data location physical address PA1. At step 1220, if no data access has been issued yet, a memory access request specifying the data location physical address is issued 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, at step 1222, a tag check (e.g., ...) is performed using the obtained allocation tag and the address tag associated with the address operation of the memory access instruction. Figure 8 middle).

[0211] Figure 13 This example illustrates the steps for performing a tag location address translation operation in response to a tag access instruction used to access one or more allocation tags corresponding to a specified data address. The tag access instruction may also trigger access to the corresponding data item (e.g., ...). Figure 12 In the example, a tag-checked memory access instruction can be a tag read / write instruction requesting read / write access to the allocation tag of a data item block corresponding to a specified data address without accessing the corresponding data item. In this example, the address translation for a given stage from a first address space to a second address space (hereinafter referred to as stage n translation) includes a selection between a first tag translation mode and a second tag translation mode. When using a one-stage address translation mechanism, stage n translation can be a single-stage address translation used in the mechanism (where the first address space is a virtual address space 40, the second address space is a physical address space 52, and the single-stage translation table maps addresses directly from virtual address space 40 to physical address space 52). When using a two-stage address translation mechanism, stage n translation can be a stage 1 translation (where the first address space is a virtual address space 40, the second address space is an intermediate address space 46, and the address mapping for the translation is determined based on stage 1 translation table 44) or a stage 2 translation (where the first address space is an intermediate address space 46, the second address space is a physical address space 52, and the address mapping for the translation is determined based on stage 2 translation table 50).

[0212] At step 1300, MMU 6 determines to perform tag location address translation to obtain the tag location physical address corresponding to the data address specified by the address operand of the tag access instruction. The data address may be specified as a virtual address in virtual address space 40.

[0213] At step 1302, the data location first address in the first address spaces 40 and 46 is determined based on the data address specified by the tag access instruction. If the stage n transition is a transition in a single-stage transition mechanism or a stage 1 transition in a two-stage transition mechanism, the data location first address can simply be the data address specified by the instruction. If the stage n transition is a stage 2 transition in a two-stage transition mechanism, the data location first address can be an intermediate address obtained by transitioning the data address VA in the stage 1 transition (e.g., ...). Figure 11 IPA1 in the middle).

[0214] At step 1304, MMU 6 determines which tag translation mode is the selected tag 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 tag translation mode may be based on tag translation control information stored in control register 14, which is set by software to operate at at least a given privilege level (e.g., operating system-level privilege in the case of a stage n translation being a single-stage translation or a stage 1 translation in a two-stage mechanism), or hypervisor-level privilege in the case of a stage n translation being a stage 2 translation.

[0215] If MMU 6 determines that a first label translation mode (where the translation mode disables virtualization tags for stage n translation) has been selected, then at step 1306, MMU 6 obtains a second data location address that identifies the location of both the data item corresponding to the data address and its associated allocation tag within a second address space. For example, the first data location address obtained at step 1302 can be used to look up TLB 8 and / or translation tables 44, 50 to obtain address mapping information for translating the first data location address into the second data location address. In this case, both data translation and label translation will be controlled based on the same translation table entries that provide the address mapping from the first data location address (e.g., VA or IPA1) to the second data location address (e.g., IPA1 or PA1). At step 1308, MMU 6 determines the label location physical address based on the second data location address.

[0216] If MMU 6 determines that a second label translation mode (where the translation mode enables virtualization tags for stage n translation) has been selected, then at step 1310, MMU 6 obtains a label positioning second address (e.g., IPA2 or PA2) that identifies the location of the assigned label in the second address space, a location separate from the location of the data item identified by the data positioning second address (e.g., IPA1 or PA1). A separate translation table entry identifies the mapping to the label positioning second address, compared to the entry used to obtain the address mapping for the data positioning second address. Two examples of how such separate translation table entries can be located are referenced below. Figures 14 to 17 Explanation. In step 1312, MMU6 determines the tag location physical address based on the tag location second address determined in step 1310.

[0217] At both steps 1308 and 1312, if the stage n transition is a transition in a single-stage transition mechanism or a stage 2 transition in a two-stage transition mechanism, the tag location physical address can simply be equal to the data location second address determined at step 1306 or 1310, since the data location second address is already a physical address in the physical address space. If the stage n transition is a stage 1 transition in a two-stage transition mechanism, the data location second address (also used as the tag location second address) can be further converted to the tag location physical address, for example, based on a further stage 2 transition. If a first tag transition mode is selected for a stage 1 transition in a two-stage address transition mechanism, then at step 1308, the stage 2 transition performed to obtain the tag location physical address can use either the first tag transition mode or the second tag transition mode, depending on any mode selection configuration value specified for the stage 2 transition. If a second tag transition mode is used for a stage 1 transition in a two-stage transition, then at step 1312, the stage 2 transition can be performed based on the first tag transition mode (to prevent unpredictable results due to using the second tag transition mode for both stage 1 and stage 2 transitions).

[0218] It should be understood that Figure 13 The steps shown may not be necessary every time a tag access instruction is executed. While the translation of any required stages of the current translation mechanism may be fully performed on the first access to a given address space region where relevant information is not cached in TLB 8, subsequent accesses to the same address space region can utilize information cached in TLB 8 from previous accesses to avoid needing to perform the full translation process 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 physical address (this information has been previously cached based on...). Figure 13The process is defined in the code to avoid having to consider which tag transition mode is selected each time. Therefore, although MMU 6 can have support for executing tag access instructions... Figure 13 The configuration shown illustrates the operation, but it is not always necessary to use this configuration for every tag access instruction. For example, the control information used to select which tag transition mode to use may be checked during page table traversal, but may not be needed when the address accessed by the tag is hit in TLB 8.

[0219] Therefore, if the second label translation mode is selected for the address translation of a given stage, different translation table entries can be used to identify the second addresses in the translated second address space that correspond to the data items and labels, respectively. Figures 14 to 17 Two example techniques are shown for identifying different transformation table entries used to identify the mappings for obtaining the second address for data location and the second address for tag location.

[0220] like Figure 14 As shown, one option is to provide different translation table base address registers to store the base addresses of the translation tables used for data access address translation and tag access 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 one for tag 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 at a given stage can be responsible for storing the required translation table entries for each different translation table structure into memory and setting the translation table base address register to point to the corresponding translation table structure. From the hardware perspective of MMU 6, the translation process can be the same for both data access and tag access, the difference being that the selection between the first and second translation table base address registers depends on whether the current translation is for data access or tag allocation.

[0221] Therefore, as Figure 14 As shown, for a stage n translation from a first address space 90 (virtual or intermediate address space) to a second address space 92 (intermediate or physical address space), given data in the first address space 90 is located at a first address 94. For the data location address translation operation, the corresponding translation entry 98 is selected 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 in the second address space 92 is located at a second address 104. Although for the sake of simplicity, Figure 14The diagram shows the mapping where the selected translation table entry 98 is directly assigned to the second data location address 104. However, it should 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 first data location address 94 can actually assign a table pointer that identifies another translation table, and the second data location address 104 can be obtained from entries of the translation table obtained after one or more steps of traversing such table pointers.

[0222] On the other hand, for the tag-location address translation operation, the data location first 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 the second translation table base address register, which is separate from the first translation table base address register. Based on the access to the selected tag-address-mapping translation table entry 102 from the stage n tag translation table structure, the corresponding tag-location second address 106 in the second address space 92 is determined (again, although...). Figure 14 The diagram shows a single-level table 100 for label translation, but it should be understood that some examples may traverse two or more levels of translation tables before obtaining the mapping to the second address 106 of the label location.

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

[0224] Figure 15 Examples based on Figure 14 The example steps for performing tag conversion in response to a tag access instruction. Steps 1500 to 1504 are... Figure 13 Steps 1300 to 1304 are the same.

[0225] If the first tag translation mode is the selected translation mode for stage n translation, then at step 1506, MMU 6 obtains the stage n translation table entry 98 corresponding to the data location first address 94 from the data translation table structure 96 identified by the data translation table base address TTBR_data. At step 1508, MMU 6 uses the address mapping information from the stage n translation table entry obtained at step 1506 to translate the data location first address 94 of the first address space 90 to the data location second address 104 of the second address space 92. Step 1510 for obtaining the tag location physical address is related to... Figure 13 The same as step 1308.

[0226] If the second tag translation mode is the selected translation mode for stage n translation, then at step 1512, MMU 6 obtains the stage n translation table entry 102 corresponding to the data location first address 94 from the tag translation table structure 100 identified by the tag translation table base address TTBR_tag. At step 1514, MMU 6 uses the address mapping information from the stage n translation table entry obtained at step 1512 to translate the data location first address 94 of the first address space 90 into the tag location second address 106 of the second address space 92. Step 1516 for obtaining the tag location physical address is related to... Figure 13 The steps 1312 are the same.

[0227] Figure 16 A second example is illustrated for locating different translation table entries for address translations applied to the same stages of data access translation and tag access translation, respectively. In this example, the same translation table structure 112 (accessed via the base address TTBR shared between data access and tag access) is used to provide address mapping for both data location address translation and tag location address translation. For data location address translation of a given stage (stage n) of address translation from a first address space 90 to a 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 the original text for brevity... Figure 16 As shown, however, the information in the accessed data mapping transformation table entry 116 selected based on the data location first address 110 can be a table pointer used to traverse one or more additional table levels before locating the mapping information of the specified data location second address 120.

[0228] On the other hand, for tag location address translation, before looking up the common translation table structure 112 shared with the data location address translation, the tag location address determination circuit 10 applies a transformation function to the data location first address 110 to obtain the tag location first address 108. It should be noted that this transformation is within the same (first) address space 90 (unlike staged address translation from one address space to another). An example of the transformation function will be provided later. Figure 22 and Figure 23 The transformed tag location first address 108 is used to look up TLB 8 or as input to the page table traversal process to traverse the stage n translation table structure 112, such that the transformed tag location second address 118 depends on the tag 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. It should be noted that although... Figure 16 The different label mapping entries 114 and data mapping entries 116 in the first-level translation table, which are looked up based on the label location first address 108 and the data location first address 110 respectively, are separate. However, in the case where the stage n translation table structure 112 is implemented as a multi-level structure (where each level table is looked up based on different bit portions from the input addresses 108, 110), in some cases, the same entries in the first-level translation table can be used for both label translation and data translation, and the entries in the subsequent levels of the translation table are selected differently for label translation and data translation, so as to ultimately provide different translated second addresses 118, 120 for assigning labels and data items respectively.

[0229] Figure 17 Examples based on Figure 16 The example steps for performing tag conversion in response to a tag access instruction. Steps 1700 to 1704 are... Figure 13 Steps 1300 to 1304 are the same.

[0230] If the first tag translation mode is the selected translation mode for stage n translation, then at step 1706, MMU6 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 to the data location second address 120 of the second address space 92. Step 1708 for obtaining the tag location physical address based on the data location second address is related to... Figure 13 The same as step 1308.

[0231] If the second tag translation mode is the selected translation mode for stage n translation, then at step 1710, the tag positioning address determination circuit 10 obtains the tag positioning first address 108 corresponding to the data positioning first address 110 of the first address space 90. For example, the transformation from the data positioning first address 110 to the tag positioning first address 108 can be based on the tag storage region base address, which applies an offset selected based on the data positioning first address 110 to define the location of the tag storage address region within the first address space 90. At step 1712, the MMU 6 uses address mapping information from the stage n translation table entry 114 selected from the stage n translation table structure 112 based on the tag positioning first address 108 to convert the tag positioning first address 108 of the first address space 90 to the data positioning second address 118 of the second address space 92. Step 1714 for obtaining the tag positioning physical address based on the tag positioning second address is related to... Figure 13 The steps 1312 are the same.

[0232] Figure 18 An example of a subset of control register states stored in register 14 is illustrated. This subset of control register states is related to controlling the tag address location translation operation performed by MMU 6 and the data access to tag check performed by data access to tag check circuitry 32. Register 14 includes a set of control registers separate from the general-purpose registers used to provide general-purpose operands for instructions. This set of control registers defines architectural states with specifically defined meanings within 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 influence how processor 2 processes instructions.

[0233] For example, execution circuitry 16 may support instruction processing for multiple exception levels associated with different privilege levels. For instance, supported exception levels may include exception levels EL0 through EL3, where EL0 is the lowest privilege and EL3 is the highest privilege. Exception level EL0 is used for application-level program code, exception level EL1 for operating system-level program code, exception level EL2 for management program-level program code, and exception level EL3 for security oversight code performing certain security management operations. It should be understood that this is only one example of a possible privilege scheme, and other examples may have different ways of specifying different privilege levels available in different operating states, but subsequent examples are described with reference to this particular scheme.

[0234] exist Figure 18Among the register names shown, those with the suffix _ELy (where y = 1, 2, or 3) indicate that the lowest privileged exception level allowed to update the architectural state in that register is exception level ELy. Therefore, an attempt to write to the register from an exception level with a lower privilege than ELy will result in a signaling failure (e.g., a register with the suffix _EL2 can be written to from EL2 or EL3, but not from EL1). Registers shown with the suffix _ELx are banked registers. For these banked registers, multiple versions of the register corresponding to different exception levels are available (e.g., one version _EL2 is associated with the hypervisor-level exception level EL2, while another version _EL1 is associated with the operating system-level exception level).

[0235] Therefore, in this example, the following set of control registers is provided, which specifies the following control status information items:

[0236] SCTLR2_ELx (The system control registers are split into separate versions providing 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), and their specifications are:

[0237] • VTE: An example of a first-stage label translation mode indicator used to specify whether virtual tags should be enabled or disabled (second label translation mode is used for stage 1 address translation). For example, a VTE can be encoded as follows:

[0238] ○0: Virtual tags are disabled;

[0239] ○1: Virtual tags are enabled.

[0240] (This encoding can help with backward compatibility with legacy code, which can assume that reserved bits in the SCTLR2 register, which has been reused to provide the VTE indicator, will have a value of 0.)

[0241] • nDGA: Data Access to Tag Check Enable Indicator, used to specify whether data access to tag check is enabled (described further below). For example, nDGA can be encoded as follows:

[0242] ○0: Data access to tag check enabled

[0243] ○1: Data access to tag check disabled

[0244] (Implementing nDGA with negative encoding, where the check is disabled when nDGA is 1) can help with backward compatibility with legacy code, which can assume that reserved bits in register SCTLR2, which has been reused to provide the nDGA indicator, will have a value of 0. Therefore, unless the software that knows the data access to tag check has explicitly chosen to disable it by setting nDGA to 1, it is considered safer to have the data access to tag check enabled.

[0245] TCR2_ELx (The translation control register, which is split to provide separate versions associated with exception levels EL1, EL2, and EL3 (selected among them according to the current exception level)), specifies multiple tag table base address information entries VTB, VTB0, VTB1, and VGB used to define the base addresses of tag regions in the address space. These multiple tag table base address information entries are used for the translation from data location first address 110 to tag location first address 108, such as... Figure 16 As shown. The VGB entry is only available in the TCR2_EL2 version associated with EL2, and not for EL1 or EL3. Which entry in the tag table base address information is used for a given translation operation depends on which translation mechanism is being used and which stage of address translation is being performed in a given stage where the second tag translation mode has been enabled:

[0246] • For stage 2 transitions, if intermediate tags (using the second tag transition mode for stage 2 transitions) are enabled, the tag table base address is determined from VGB in register TCR2_EL2;

[0247] • For support of a single convertible address region (see below for more description of convertible address regions) Figure 20 In the phase 1 transition mechanism, if virtual tags (using the second tag transition mode for phase 1 transitions) are enabled, the tag table base address is determined from the VTB in register TCR2_ELx, where ELx is the current exception level; and

[0248] • For support of two translatable address regions (see also the discussion below) Figure 20 In the phase 1 transition of the transition mechanism, if virtual tags are enabled, the tag table base address is determined from VTB0 or ​​VTB1 in register TCR2_ELx, where ELx is the current exception level. VTB0 is used when the most significant bit of the first address of the data location is 0 (i.e., the address is in transition region 0), and VTB1 is used when the most significant bit of the first address of the data location is 1 (i.e., the address is in transition region 1).

[0249] Regardless of which tag table base address information item VTB, VTB0, VTB1, or VGB is used, the tag table base address can be encoded such that the tag table base address information only specifies the higher bits of the aligned base address (so that the least significant bit that is implicitly set to 0 for the aligned base address can be omitted from the stored register state).

[0250] HCR2_EL2 (Alternatively, VTCR_EL2): A register used to store hypervisor control information (or virtualization information set by the hypervisor to control address translation). HCR2_EL2 or VTCR_EL2 specifies the Second Stage Tag Translation Control Indicator (IPMTE), which indicates whether intermediate tags (using the second tag translation mode for stage 2 translations) are enabled or disabled. The IPMTE has the following encoding:

[0251] ○0: Intermediate markers are disabled;

[0252] ○1: Middle markers enabled.

[0253] (Similarly, this encoding can help with backward compatibility, as legacy code can be assumed to be reused to provide that reserved bits for IPMTE control can have a value of 0).

[0254] TCR1_ELx (Split into separate versions of the translation control registers for EL1, EL2, and EL3) — Another register that provides translation control information associated with the exception level ELx. TCR1_ELx specifies information defining the size of each translatable address region:

[0255] •T0SZ: Defines the size of a single convertible address region in a single-region translation mechanism or the size of convertible address region 0 in a two-region translation mechanism;

[0256] •T1SZ: Defines the size of the second convertible address region 1 in the two-region convertible region.

[0257] For example, T0SZ and T1SZ can be specified with a value x, such that the size of the corresponding convertible address region is 2. (64–x) byte.

[0258] TTBR : Multiple Translation Table Base Address Registers (TTBRs) are used to provide the base address of the translation table structure. For data access, multiple translation table base address registers can be specified in the TTBR, including, for example:

[0259] -TTBR0_ELx (for separate versions of EL1, EL2, and EL3 respectively): The base address of the translation table to be used for data access in a single-region translation mechanism or for data access in the convertible region 0 of a dual-region translation mechanism;

[0260] -TTBR1_ELx (separate versions for EL1 and EL2 respectively): The base address of the translation table to be used for data access in the convertible region 1 of the dual-region translation mechanism.

[0261] For example, Figure 14 TTBR_data and Figure 16 The TTBR in the context can be an address specified in either TTBR0_ELx or TTBR1_ELx, chosen based on: (i) the current exception level, and (ii) whether a single-convertible region transfer mechanism or a dual-convertible region transfer mechanism is in operation. Figure 18 Other control states (not shown) can specify which transition mechanism is the current mechanism. For label transitions, if using... Figure 16 The method shown uses the same translation table base address as the one used for data translation. However, if using... Figure 14 The method shown is as follows: Figure 18 As shown by the dashed lines, the TTBR may also include multiple additional TTBRs to provide additional base addresses TTBR_tags for the tag translation table structure 100 corresponding to the data translation table structure 96 referenced by the corresponding TTBR used for data access. Therefore, in this case, each TTBR may have two versions: one for data access and one for tags.

[0262] It should be understood that the specific layout of the provided control registers and the control states within those registers can vary significantly from one ISA to another. Therefore, the specific allocation of control state entries to specific registers, or the characteristic specifying whether a given group of control states is distributed across a single register or across separate registers, is not particularly important and can be implemented in other ways. Similarly, providing separate versions of the same registers associated with different exception levels is not required, and other examples may provide a single version for each architectural state entry (where the value of the state is switched by software when switching between one exception level and another). However, separate state entries for different exception levels can be useful for reducing software overhead when acquiring and returning from exceptions.

[0263] However, in order to control operations related to virtualization tag support, it may be useful to provide the following in general:

[0264] - Label translation control information (e.g., first-stage label translation mode indicator VTE and second-stage label translation mode indicator IPMTE) is used to control whether the address translation in a given stage is performed using the first label translation mode or the second label translation mode to perform label location address translation;

[0265] - Data access to tag inspection enable information (e.g., nDGA), which controls whether data access to tag inspection is enabled or disabled;

[0266] - Information used to define the location and size of the allocation tag storage region in the first address space 90, which is relevant to, for example Figure 16 The example shown, in which tag translation involves applying address transformation to data location first address 110 to generate tag location first address 108, is useful and used to determine in data access to tag checking whether data access has specified an address in the tag storage region of the first address space; and / or

[0267] - An example where label transformation uses a separate set of transformation tables from the transformation tables used for data transformation (such as...) Figure 14 As shown in the diagram, one or more additional base addresses for those translation table structures will be used for tag translation.

[0268] This information can be related to Figure 18 Different formats are provided as shown, but for illustrative purposes, please refer to the following descriptions. Figure 18 The specific indicator shown.

[0269] Figure 19 An example is provided for controlling whether to perform a tag address translation operation (corresponding to the previously mentioned second tag translation mode) or a data address translation operation (corresponding to the first tag translation mode) to obtain the tag location second address when a translation operation is to be performed in a two-stage address translation mechanism to obtain the address of the allocated tag to be accessed by the tag access instruction. Figure 19 This determination is shown for both stage 1 address translation and stage 2 address translation.

[0270] At step 1900, MMU 6 determines which type of instruction to execute to perform tag location address translation. For example, the tag access instruction being executed could be:

[0271] - A tag-checked memory access instruction that specifies the target data address that identifies a given data item and requests a read / write memory access to the given data item itself, and also requests (if the target data address corresponds to a tag memory region, as referenced) Figure 12 The discussed method uses corresponding allocation tags stored in the memory system and address tags associated with the address operands of the instruction to perform tag checking;

[0272] - (Non-bulk) Tag read / write instructions specify the target data address of a block (a single tag particle or data items corresponding to multiple tag particles) that identifies one or more data items of a specific size, but do not require access to the data items themselves. Instead, they request a read / write operation to the location where the allocation tags corresponding to those data items are stored. Such instructions can be used to allocate or deallocate memory regions (such as...) Figure 5 The tag value is set when (as shown). Non-batch tag read / write commands indirectly specify the address of the tag to be read or written by specifying the address of the corresponding data item. Figure 16 In the example, for instance, a non-bulk tag read / write instruction may specify the virtual address corresponding to the data location first address 110 in the first address space 90 as its target data address, but may cause a memory access to be performed on the physical address corresponding to the tag location second address 118 instead of the physical address corresponding to the data location second address 120.

[0273] - Batch tag read / write commands are a special type of tag read / write command that directly specifies the address of the tag itself, rather than indirectly specifying the address of the corresponding data item. For example, see [reference]. Figure 16 For example, bulk tag read / write instructions can specify the virtual address corresponding to the tag positioning first address 108 as its target address (e.g., if...). Figure 16 The address translation stage shown is stage 1. Therefore, the address operand of the bulk tag read / write instruction will position the tag at the first address 108, specified as the virtual address, or if... Figure 16 The stage shown is stage 2, where the tag location first address 108 is the result of a stage 1 translation of the virtual address specified by the instruction. The tag location first address 108 is translated as if it were a data address, then read / write access is made to the physical address corresponding to the tag location second address 118 translated based on tag mapping entry 114 in stage n. Providing such bulk tag read / write instructions (which directly specify the tag address rather than indirectly via a data address) could be useful to simplify the management of the hypervisor for the stage 1 translation table of the guest operating system.

[0274] If the current instruction requiring tag location address translation is an instruction that specifies the tag's location by specifying a data address (e.g., a memory access instruction for tag checking, or a non-bulk tag read / write instruction), then in Figure 19At step 1902, MMU 6 determines whether the Stage 1 Tag Translation Mode Indicator (VTE) corresponding to the current translation mechanism indicates that virtual tagging is enabled for Stage 1 address translation (e.g., if multiple separate versions of the VTE for different exception levels are supported, the VTE can be read from the relevant version of the register SCTLR2_ELx associated with the current exception level ELx). If virtual tagging is enabled for Stage 1 translation for the current translation mechanism, then at step 1904, MMU 6 applies a tag address translation operation for the Stage 1 translation of the data address specified by the tag access instruction (e.g., according to...). Figure 13 , Figure 15 or Figure 17 The second tag conversion mode shown). At step 1906, then according to the data address conversion operation (e.g., according to...). Figure 13 , Figure 15 or Figure 17 The first label translation mode shown executes stage 2 translation. The combination of steps 1904 and 1906 means that the overall two-stage address translation is as follows: Figure 10 The virtual tagging method shown is performed as described above, where the Phase 1 translation is a translation that maps virtual data addresses to separate data addresses and tag addresses in the intermediate address space. These separate data addresses and tag addresses can then be further translated into separate physical addresses in the Phase 2 translation.

[0275] If it is determined that the first-stage tag translation mode indicator indicates that virtual tags are disabled for stage 1 translation (No at step 1902), or the instruction executed to cause tag access is a bulk tag read / write instruction specifying a tag address (instead of a data address), then at step 1908, a data address translation operation is applied for stage 1 address translation (i.e., Figure 13 , Figure 15 or Figure 17 The first tag translation mode shown is used, therefore virtual tags are disabled for stage 1. At step 1910, MMU 6 determines whether the second-stage tag translation mode indicator IPMTE, corresponding to the current translation mechanism, stored in control register HCR2_EL2 or VTCR_EL2, indicates that intermediate tags are enabled. If so, at step 1912, MMU 6 applies tag address translation operations when performing stage 2 translation from intermediate address space to physical address space. Figure 13 , Figure 15 or Figure 17 (as shown in the second tag conversion mode), therefore, as Figure 11The application shown uses intermediate tags, where Phase 1 transitions both data access and tag access from the virtual address space to the intermediate address space. However, a given intermediate address IPA1 that identifies the location of data in the intermediate address space is mapped to a tag location physical PA2 that identifies the location of the tag assigned to the tag, separate from the physical address PA1 that identifies the corresponding data item.

[0276] On the other hand, if the second-stage tag conversion mode indicator checked at step 1910 indicates that the intermediate tag is disabled at stage 2, then at step 1906, the data address translation operation (first tag conversion mode) is also applied to stage 2, and 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 tag conversion mode), and therefore a physical tagging method (such as...) will be used. Figure 9 The physical tagging method shown in the figure uses the same physical address to identify both the data and its associated allocation tag, leaving the memory system to locate the tag's storage location based on the physical address of the data.

[0277] As mentioned above Figure 16As indicated, some specific implementations of the tag location address translation operation (second tag translation mode) may include the following steps: The tag location address determination circuit 10 determines a tag location first address 108 identifying the location of the corresponding assigned tag in the first address space 90 based on a data location first address 110 that identifies the location of a given data item in the first address space 90, and then applies address translation at a given stage to translate the tag location first address 108 into a 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, another base register can be provided in the ISA's control register to store the base address used to access the data-to-tag address mapping table. This approach provides greater flexibility in specifying the location for storing tags within the first address space 90, but may increase the software overhead in setting the data-to-tag address mapping as well as the hardware overhead, resulting in additional latency when accessing the data-to-tag address mapping table. Another approach could be for each data location first address to have a one-to-one fixed mapping to the corresponding tag location first address (where the fixed mapping function constrains the mapping, such as each tag location first address having a certain offset from the corresponding data location first address). However, if the software is unable to change the mapping between the data location first address 110 and the tag location first address 108, this could unacceptably restrict the placement of data items within the first address space 90, thus creating a greater burden when adjusting address space regions for other purposes.

[0278] Figures 20 to 23 An example is provided for performing a tag location address determination operation, which strikes a balance between the flexibility of changing the address allocated in the first address space 90 for storing the allocated tag in software and performing a simpler and more efficient operation in hardware.

[0279] like Figure 20 As shown, a given translation mechanism can restrict valid data addresses to one of a finite number of translatable address regions. Figure 20 An example with a single translatable address region is shown ( Figure 20 (left-hand side) and an example with two convertible address regions ( Figure 20 (The right-hand side). Attempts to access data using addresses in non-translatable address regions (outside of any translatable address regions) may signal a memory failure. This approach can be useful because, although address operands in a 64-bit instruction set architecture can theoretically address 2... 64While there are several different address space bytes, current implementation requirements do not necessitate that much addressable memory capacity. Therefore, a smaller number of bits may be sufficient to support the required number of addressable locations. For example, the size of the convertible region could be limited to 2^36 bytes of the address space. 48 2 53 or 2 56 Bytes, just some arbitrary examples. This has several advantages by leaving some non-translatable regions (regions that do not support specifying any valid address within them). First, this means that the software setting up the address translation mapping does not need to provide any valid address mappings corresponding to the non-translatable regions, which reduces the burden of maintaining the translation table structure. Furthermore, having some unused bits in the higher bits of larger (e.g., 64-bit) address operands leaves some space for encoding other information in the address operand, such as... Figure 4 The address label shown is 80.

[0280] like Figure 20 As shown in the example on the left, a translation mechanism using a single translatable region 200 is used for the first address space 90, which can cover an area extending from address 0 to address 2. t -1 of 2 t The address space of bytes, where t is the convertible region size determined from the region size indicator value T0SZ in the register TCR1_ELx as described above (again, there may be more than one version of the T0SZ parameter corresponding to different exception levels, where the specific region size used for the current conversion mechanism depends on the current exception level).

[0281] To accommodate the tag location addresses used to locate allocation tags within the first address space, a tag table address region 202 is defined within the convertible address region 200. The size of the tag table address region 202 scales proportionally to the size of the convertible region 200, depending on a comparison between the size of the allocation tag and the size of the corresponding data block associated with that allocation tag. Generally, if 2 n If byte data items share one or more allocation tags stored in a single byte in the address space, then the tag table address area is half the size of the convertible region 200. n For example, if one allocation tag is assigned to each 16-byte data block and two 4-bit allocation tags fit into one byte of the address space, then 32 bytes of data share one byte of allocation tags, so n=5. This means that the size of the tag table address region 202 will be 1 / 32 the size of the translation region 200. To support efficient tag address determination operations, the simplest approach is to use a naturally aligned address boundary that identifies the beginning of the tag table address region, spaced at intervals equal to the size of the tag table address region (i.e., 2 * 1 / 3 ... (t-n)The interval, of which 2 t It is the size of the convertible address region, and 2 n (This is the ratio between the tag table address region size and the convertible address region size) and is aligned with the boundary. This means that tag table address region 202 can exist within convertible region 200 for a maximum of 2... n With different alignment positions, the location of tag table address region 202 can be represented by n-bit tag table base address values ​​VTB and VGB, such as Figure 18 As shown. In Figure 22 In the example, n=5. By using aligned tag table base addresses, the operation of combining base addresses with offsets does not require addition, but can be simply performed by concatenating the base addresses and offsets, which is much faster and consumes less power for the hardware than addition.

[0282] like Figure 20 As shown in the example on the right, for a translation mechanism using two translatable address regions 206 and 204, there exists a size of 2 t0 The lower convertible region (region 0) is 206, where t0 is the region size of convertible region 0, as defined by the region size indicator value T0SZ in register TCR1_ELx selected based on the current exception level ELx. Convertible region 0 (206) extends from address 0 to address 2. t0 -1, and in an address with 64 bits [63:0], for valid addresses in convertible region 206, bits [63:t0] are constrained to all 0s. There also exists a size of 2... t1 The convertible region (region 1) is 204, where t1 is the region size of convertible region 1, as defined by the region size indicator value T1SZ in register TCR1_ELx selected based on the current exception level ELx. Convertible region 1 (204) is located at address 2. 64 -2 t1 Extending to address 2 64 -1, and in an address with 64 bits [63:0], bits [63:t1] are constrained to all 1s for valid addresses in the convertible region 206. This makes it possible to access the address from address 2... t0 Extending to address 2 64 -2 t1The large non-convertible address region of -1 is left free as encoding space for other purposes, including supporting the definition of address labels 80 with values ​​other than all 0s or all 1s in the higher bits [63:t0] or [63:t1], which are not used to distinguish valid addresses in one of the convertible address regions 206, 204. The convertible region sizes t0, t1 can be different from each other—for example, the upper convertible region 204 can be smaller or larger than the lower convertible region 206. Support for two convertible regions can help isolate data in the kernel region of the address space used by the operating system (which can use the upper convertible region 204) from data in the user region of the address space used by application code (which can use the lower convertible region 206), because this makes it less likely that an address pointer calculated by user code will accidentally point to a location in the kernel region of address space 204.

[0283] When two convertible address regions 204 and 206 are supported, each region can have its own corresponding tag table address regions 208 and 210, which are designated to store the allocation tags for the corresponding data items in the convertible address regions 204 and 206. In the method using a single convertible region, the ratio between the size of a given convertible region 204 and 206 and the size of the corresponding tag table address regions 208 and 210 can be fixed, depending on the size of the allocation tags and the number of bytes of data sharing a single allocation tag. Therefore, the size of the tag table address regions 208 and 210 scales proportionally with the size of the corresponding convertible address regions 204 and 206 as defined by T0SZ or T1SZ. The location of the tag table address regions 208 and 210 within a given convertible address region 204 and 206 depends on the corresponding tag table base address information VTB1 (for convertible region 1, 204) or VTB0 (for convertible region 0, 206) stored in the register TCR2_ELx of the current exception level ELx. The tag table base addresses VTB0 and VTB1 are defined independently for the two convertible regions 204 and 206. Therefore, the relative positioning of the tag table address regions within the convertible regions can be different for the two convertible regions 204 and 206.

[0284] Figure 21 An example is illustrated of the tag location address determination circuit 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 operates on a given data location first address 110, which is equal to or depends on a virtual address specified by the tag access instruction (e.g., already obtained in an earlier stage of address translation applied to that virtual address).

[0285] At step 2100, based on the execution of the tag access instruction, it is determined that tag access is required. In response, at step 2102, MMU 6 determines whether the virtualized tag translation mode (e.g., the second tag translation mode described above) is currently enabled (e.g., based on the control state VTE or IPMTE associated with the address translation of the current stage of the current translation mechanism). If the virtualized tag translation mode is currently disabled for the address translation of the current stage, it is not necessary to map the data location address to the tag location address within the first address space. Therefore, at step 2110, the address of the tag within the second address space 92 is executed based on the translated data location first address 110. If the virtualized tag translation is enabled for the address translation of the current stage, at step 2104, MMU 6 determines whether the data location first address 110 is a valid address within the range of any translatable address regions 200, 204, 206 supported in the current translation mechanism. If not, a fault is signaled at step 2106 to prevent unpredictable results caused by triggering tag access corresponding to an untranslatable address. If the data location first address 110 is in the convertible address regions 200, 204, 206, then at step 2108, the tag location first address 108 is determined by applying an offset determined based on a predetermined portion of the data location first address to the tag table base address represented by the tag table base address information VTB, VTB0, VTB1, VGB. The tag table base address is determined based on VTB for single convertible region stage 1 translation, based on VGB for stage 2 translation, based on VTB0 for dual convertible region stage 1 translation where the data location address is in convertible region 0 (206), and based on VTB1 for dual convertible region stage 1 translation where the data location address is in convertible region 1 (204). Furthermore, at step 2108, the tag location address determination circuit 10 identifies nibble selection information based on one or more bits of the data location first address 110, which are lower than (but contiguous with) the portion used to derive the offset. This nibble selection information can be used to select between two or more allocation tags within the same byte of the address space.

[0286] Figure 22 This example illustrates the tag location address determination operation at step 2108 for a single-region conversion mechanism (used for stage 1 or stage 2 conversion). Here, 2 t The configurable conversion region size is defined by T0SZ, and this example assumes that the tag 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. Therefore, this example assumes that the ratio between the conversion region size and the tag table region size is 32 (2). 5 For ease of explanation, Figure 22 This is shown as the virtual address applied as the first address 110 for data positioning, but the same operation can be performed for stage 2 translation, where the first address 110 for data positioning will be the intermediate address, except that a different tag table base address value VGB is used instead of VTB (and in some examples, different size parameter definitions). Figure 22 Size of the convertible address region 2 t Apart from the above, the tag location address determination operation can be the same as in stage 1.

[0287] like Figure 22 As shown, for a size of 2 t A single convertible region, the data location first address 110 can be considered to include meaningful address bits [t-1:0] equal to a given address value, and higher bits [55:t] constrained to 0 for a valid address (this example assumes that there are no meaningful bits above bit

[55] , because bit

[56] and higher bits can be reserved for other purposes, such as storing address label 80).

[0288] like Figure 22 As shown in the section marked 110', for the purpose of generating the tag location first address 108, the same address 110 can be interpreted as containing a tag index value at bit [t-1:5], which represents an offset relative to the tag table base address (this offset indicates which specific address within the tag table address region 202 should be the tag location first address 108 for that specific access). The offset corresponds to the portion of the address's identifier address 110 that falls into among multiple different tag particles, where a tag particle is a block of address space for which all addresses in the block share the same allocation tag 72 stored in the memory system.

[0289] Therefore, when generating the corresponding tag location first address 108, bits [t-6:0] are set based on the tag index value of bits [t-1:5] from the data location first address 110. In effect, an arithmetic right shift is performed (5 bits in this example), although shift logic is not required in practice because 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 equal to the 5-bit table base address identifier value VTB (for phase 1) or VGB (for phase 2). Therefore, by defining the base address as... t The address boundaries are naturally aligned, which eliminates any need to add an offset (“tag index”) to the base address when calculating the tag location first address 108. The higher bits [55:t] remain all 0 in the tag location first address 108, ensuring that the tag table is entirely within the translatable address region 200.

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

[0291] Figure 23 This illustrates a similar operation to a stage 1 translation performed in a translation mechanism with two translatable address regions 204 and 206. The principle is the same as... Figure 22 The same applies in the previous example, where the tag positioning first address 108 is determined as an offset relative to the base address, where this offset is determined based on bits [t-1:5] of the data positioning first address 110. However, in Figure 23 In this context, the convertible region size t and the tag table base address (“table base[s]”) differ depending on whether the data location first address 110 is in the upper convertible address region 204 or the lower convertible address region 206. If the data location first address 110 has the most significant bit equal to s=0

[55] , then address 110 is in the lower convertible address region 206, the convertible region size t=t0 is determined according to the control state T0SZ, and the tag table base address (the value to be specified in bits [t0-1:t0-5] of the tag location first address 108) is determined according to VTB0. If the data location first address 110 has the most significant bit equal to s=1

[55] , then address 110 is in the upper convertible address region 204, the convertible region size t=t1 is determined according to the control state T1SZ, and the tag table base address (the value to be specified in bits [t1-1:t1-5] of the tag location first address 108) is determined according to VTB1. In addition to considering different region sizes and tag table base addresses based on whether the higher bit

[55] is 0 or 1, tag positioning first address 108 and nibble selection information 220 are used in conjunction with... Figure 22 A similar method was used to determine this.

[0292] Although Figure 22 and Figure 23The examples are based on a fixed ratio of 1 / 32 between the size of tag table address regions 202, 208, and 210 and the size of the corresponding convertible address regions 200, 204, and 206, and therefore a fixed 5-bit size for the tag table base address value injected at bits [t-1:t-5] of the tag positioning first address 108. However, other examples may support variable-allocation tag sizes or variable-size data item particles sharing an allocation tag, in which case the tag... Figure 22 and Figure 23 The bit positions of the table base address and the boundary of the tag table index shown can vary.

[0293] In the example supporting tag location address determination for both Stage 1 and Stage 2 translations, the same hardware can be shared between the two stages of address translation because, apart from taking different values ​​for the convertible region size t and the table base address "table base", the mapping function is the same regardless of which stage of address translation the tag location address determination is applied to. Therefore, the tag location address determination circuit 10 can be shared between a variety of different translation mechanisms.

[0294] Figure 24 This is a flowchart illustrating a specific example of the steps used to implement tag address translation when supporting a variable tag translation mode (enabling / disabling virtualization tags in both the first-stage and second-stage address translation). It should be understood that... Figure 24 It is a specific implementation of some of the features described more generally above, and therefore there are other ways to achieve similar functionality.

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

[0296] At step 2402, MMU 6 determines whether stage 1 address translation is currently enabled. There may be some address translation mechanisms in which stage 1 translation can be disabled and only stage 2 is used to perform translations to convert intermediate addresses specified by operands using tag access instructions to physical addresses (as noted below, there may also be mechanisms in which stage 2 translation is disabled, such that either only stage 1 is used, or for certain most secure code operating at a hypervisor exception level or higher, the code is allowed to directly specify physical addresses without any staged address translation). For example, control status (restricted to be able to be updated by software with hypervisor-level privileges or higher) can be used to indicate whether stage 1 translation and / or stage 2 translation is currently enabled.

[0297] If it is determined that Phase 1 address translation is enabled, then at step 2404, MMU 6 determines whether a virtual tag (referred to as VMTE for brevity) is enabled for Phase 1 translation (e.g., this can be determined based on the Phase 1 tag translation control indicator VTE described above). Furthermore, MMU 6 determines whether the current tag access instruction is a bulk tag read / write instruction. If the virtual tag is currently disabled or the current tag access instruction is a bulk tag read / write instruction, then no special tag address translation operation different from the data address translation operation used for Phase 1 translation is required. Instead, at step 2406, a data address translation operation is applied to Phase 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 for locating the intermediate address corresponding to the data item to be allocated.

[0298] In addition to obtaining the intermediate address for data location, 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 memory attribute information provides an indication of whether the memory region associated with the first address for data location is 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 in a normal write-back cache region of memory. In some examples, an alternative option for memory regions can be supported to treat the region as a “canonical tagged” region, which is a region where, although no explicit storage tag is assigned for the data item in the address space, in the dual-convertible region translation mechanism, it can be assumed that for access to an address in lower convertible region 206, all bits of the allocation tag 72 are set to 0, and for access to an address in upper convertible region 204, all bits of the allocation tag are set to 1 to perform tag checking. This canonical tag can help match the expected value of the higher address bits in the addresses that are “canonically” set for lower convertible region 206 / upper convertible region 204, respectively. In some examples, the canonical tag option can be a separate attribute type, distinct from tagged and untagged regions of memory. However, in other examples, the attribute information itself may simply distinguish tagged and untagged regions, where a control value stored in the control register indicates whether, in the current operating mode, an untagged memory region should be considered truly "untagged" (with no tag value at all) or "canonically tagged" (with all bits of the implicit allocation tag set to correspond to the most significant bit of the destination address). If the Phase 1 transition is currently disabled at step 2402, no Phase 1 memory attribute information is available, and therefore tag access can be handled by default as if the Phase 1 memory attribute information specified a tagged memory region.

[0299] If the Phase 1 transition is disabled at step 2402, steps 2404 and 2406 can be omitted, and the method proceeds directly to step 2408.

[0300] If a Phase 1 transition is disabled, or if a Phase 1 transition is performed at step 2406 for a bulk tag read / write instruction or another tag access instruction for a virtual tag that is disabled, then at step 2408, the MMU 6 determines whether a Phase 2 transition is enabled.

[0301] If the Phase 2 transition is enabled, at step 2430, MMU 6 determines whether the memory region type determined from Phase 1 is a tag region (based on Phase 1 memory attribute information, or based on the default determination of the “tag” region type if the Phase 1 transition is disabled), and whether intermediate tags are enabled for the Phase 2 transition (e.g., this can be determined based on the aforementioned Phase 2 Tag Transition Control Indicator IPMTE).

[0302] If the accessed memory region is not a tagged region or intermediate tagged memory is disabled, then at step 2412, MMU 6 performs a Stage 2 address translation from the target intermediate address (the target address of the tag access instruction itself if Stage 1 translation is disabled, or the address obtained through Stage 1 translation at 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 the virtualization tagging method (VMTE or IPMTE is enabled), therefore... Figure 9 The physical labeling method shown.

[0303] If the Phase 2 transition is disabled for the current transition mechanism, steps 2430 and 2412 are omitted.

[0304] At steps 2414 and 2416, different results are possible depending on the type of memory region being accessed. If the accessed memory region is a canonical address region (No at step 214, Yes at step 2416), then at step 2418, the MMU 6 returns the canonical tag value (based on the allocation tag bit being implicitly set to all 0s when the access is to an address in the lower convertible address region 206, and implicitly set to all 1s when the access is to an address in the upper convertible address region 204), 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 untagged (No at both steps 2414 and 2416), tag access can be effectively not performed because at step 2420, any read request for the allocation tag returns the default value 0 (read zero - RAZ), and any write request for the allocation tag is ignored (write ignore - WI) without generating any faults. However, if the access is to an address identified as a marked region (e.g., based on memory attributes associated with the first data location address), then at step 2422, a request is sent to the memory system specifying the physical address of the data location obtained from phase 1 and / or phase 2 (or, if both phase 1 and phase 2 are disabled, based on the physical address specified by the tag access instruction itself), and requesting the return of the allocation tag corresponding to that address. Assuming no error occurs in the tag access request, then at step 2424, the memory system returns a "physical tag" based on the tag specified by the memory system according to the reference above. Figure 9 The physical tagging method explained uses an implementation-specific mechanism for location. If an error occurs in the tag access request for the specified data location physical address (e.g., the memory system cannot locate the allocation tag corresponding to that physical address), a fault is signaled at step 2426.

[0305] If, at step 2430, it is determined that the target address of the tag access instruction corresponds to the tag memory region and intermediate tagging is enabled using the previously described IPMTE control, then at step 2432, the reference... Figures 16 to 17 and Figures 20 to 23 The described tag location address determination operation transforms the data location intermediate address obtained in stage 1 conversion 2406 (or directly specified by the tag access instruction if stage 1 conversion is disabled) into the corresponding tag location intermediate address, and then converts the tag location intermediate address into the tag location physical address by performing stage 2 address conversion at step 2434.

[0306] At step 2436, additional checks are performed using Stage 2 memory attribute information directly or indirectly defined by the relevant Stage 2 translation table entries used to provide address mapping in the Stage 2 translation performed at step 2434. Since the tag-positioning intermediate address has been modified relative to the corresponding data-positioning intermediate address, it may be associated with different Stage 2 memory attributes compared to the corresponding data-positioning intermediate address. Therefore, additional checks are performed to determine whether the tag-positioning intermediate address corresponds to a "normal" address region to avoid potential side effects from requesting allocation tag access to a device-type memory region. Thus, if the Stage 2 attribute of the tag-positioning intermediate address specifies that the address is in a normal region of memory, at step 2438, a memory request specifying the tag-positioning physical address is sent to the memory system to request read / write access to the corresponding allocation tag. These allocation tags are implemented as virtualized tags because the physical memory system does not need to know that allocation tags are supported (based on...). Figure 11 (The intermediate marker shown). If the memory attribute of stage 2 indicates that the intermediate address of the tag location corresponds to the memory region of the device type, then at step 2440, no tag access memory system request is sent to the memory system to avoid side effects on the device memory region, and at step 2440, if the tag access is a read operation, the tag access operation returns an assigned tag value of 0 (read is zero, RAZ), and if the tag access is a write operation, the tag access operation is ignored (write is ignored, WI).

[0307] Returning to step 2404, if it is determined that Virtual Tag Equipment (VMTE) is enabled for Phase 1 translation, then at step 2440, the tag location address determination operation is applied to the data location virtual address designated as the target address of the tag access instruction to obtain the corresponding tag location virtual address, which is translated in the Phase 1 translation at step 2442. If Phase 2 translation is enabled (yes at step 2444), the tag location intermediate address generated by Phase 1 translation is further translated into a tag location physical address through the Phase 2 translation performed at step 2446. If Phase 2 translation is disabled (no at step 2444), step 2446 is omitted, and the result of Phase 1 translation is already the tag location physical address. Regardless of the approach, at step 2448, any Stage 2 memory region attributes obtained during the Stage 2 transition are checked in a manner similar to the check described at step 2436. If the Stage 2 attribute indicates that the tag positioning intermediate address is in the device memory region (no at step 2448), the tag read / write request is processed as RAZ / WI. If the tag positioning intermediate address is in the normal memory region (yes at step 2448), a memory system request specifying the tag positioning physical address obtained at steps 2442 or 2446 is issued to the memory system to request a read / write operation on the allocation tag associated with the physical address (if the Stage 2 transition is disabled at step 2444, step 2450 is performed similarly, as if the Stage 2 permission had indicated a normal address region). Therefore, if step 2450 is performed, the allocation tag is implemented based on... Figure 10 The virtualized tag shown is assigned a separate address in the virtual address space, separate from the virtual address of the corresponding data item.

[0308] like Figure 24As indicated in the notes regarding read permission checks, whether a tag read operation requires any read permission checks for the case where the tag access instruction is a tag-checked memory access instruction varies depending on whether the virtualization flag is enabled for either Phase 1 or Phase 2 transitions. If a physical tagging approach is used (and therefore it is determined at both steps 2404 and 2430 that the virtualization flag is disabled), then no specific read permission checks are required for tag reads, because it can be assumed that any violation of read permission will be detected when a corresponding access is made to a data item that shares the same physical address as the corresponding assigned tag. If the intermediate tagging method is used (yes at step 2430), no specific additional read permission check is performed for tag access at the stage 1 transition because this transition is common to the corresponding stage 1 transition performed for access to the corresponding data item. However, a further read permission check is performed for stage 2 transition at step 2434 to check whether the stage 2 memory permission directly or indirectly indicated by the stage 2 transition table entry corresponding to the tag positioning intermediate address obtained at step 2432 indicates the existence of permission to read the tag at the corresponding intermediate address (because this stage 2 transition table entry may be different from the stage 2 transition table entry corresponding to the data positioning intermediate address, so there may be permission to read the data item instead of the corresponding tag). Similarly, if the virtual tagging method is used (yes at step 2404), for tag-checked memory access instructions, the tag read at step 2442 is based on the virtual address corresponding to the tag positioning ( Figure 10 The Stage 1 read permission information obtained directly or indirectly from the Stage 1 translation table entry corresponding to the modified VA is used to perform a read permission check, and at step 2446, the intermediate address is located based on the tag ( Figure 10 The Stage 2 read permission check is performed by directly or indirectly specifying the Stage 2 attribute in the Stage 2 transition table entry corresponding to IPA2. If any of the additional read permission check instructions performed in steps 2434, 2442, and 2446 for tag read access does not provide read permission for the tag, a fault is signaled.

[0309] On the other hand, for a tag read / write instruction (where there will be no corresponding data item access), each of the address translation steps 2406, 2412, 2434, 2442, and 2446 may include a corresponding check for read / write permissions from the corresponding translation table entry used for translation, to check whether there is a permission to read or write the tag, and if the tag access request violates the read / write permission, a fault may be signaled.

[0310] Figures 25 to 28 It provides an overview of the different options that support data transformation and label transformation.

[0311] Figure 25 An example of using physical tags is shown, where both data access and tag access use the same translation mapping in both phase 1 and phase 2 of the two-stage address translation to obtain the physical address of both the data item and its corresponding assigned tag within physical address space 52. This approach 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.

[0312] Figure 26 An example is shown where the first-stage label transition control information (VTE) indicates that virtual tags are disabled, and the second-stage label transition control information (IPMTE) indicates that intermediate tags are enabled. This corresponds to... Figure 11 The intermediate labeling method is shown. In this case, for tag or data access based on an instruction specifying a given data virtual address VA, the stage 1 translation is the same for both tag access and data access, and the data virtual address VA is translated into the same data location intermediate address IPA for both tag access and data access. However, for data access, the stage 2 translation maps the data location intermediate address to the data location physical address, while for tag access, the tag location address determination circuit 10 transforms the data location intermediate address into the tag location intermediate address, and then the MMU 6 performs the stage 2 translation from the tag location intermediate address to a tag location physical address that is separate from the data location physical address.

[0313] Figure 27 An example is shown where the first-stage tag transition control information (VTE) indicates that virtual tags are enabled and the second-stage tag transition control information (IPMTE) indicates that intermediate tags are disabled. In this case, for data access or tag access triggered by bulk tag read / write instructions (btags), stages 1 and 2 transition to match... Figure 25The same process is used to translate the data address or the 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 (because the virtual address of the btag instruction will be within the tag table address areas 202, 208, 210, rather than the remainder of the convertible address areas 200, 204, 206 as for data access). However, from the MMU 6's address translation perspective, the translation of the btag instruction uses the same translation process as for data access (although it is expected to apply to different input addresses). On the other hand, for non-bulk tag read / write instructions and tag reads performed for tag checks in memory access instructions for tag checks, before the stage 1 address translation, the tag location address determination circuit 10 transforms the data location virtual address specified by the instruction into the tag location virtual address, and then performs stage 1 and stage 2 address translations to translate the tag location virtual address IPA2 into the tag location physical address PA2 (nbtag PA).

[0314] Figure 28 This example illustrates a scenario where the first-stage label transition control information (VTE) indicates that virtual tags are enabled, and the second-stage label transition control information (IPMTE) indicates that intermediate tags are enabled. In this case, the transitions used for data access and non-batch label access are... Figure 27 The same applies (because even if the IPMTE indicates that intermediate flags are enabled, if the second address translation mode has already been enabled for the first stage of address translation, the second stage of address translation still uses the first address translation mode—see also...). Figure 19 (Steps 1902 to 1906). However, for the btag directive, it is treated by default as if virtual tags were disabled for stage 1 transitions. Therefore, if the IPMTE indicates that intermediate tags are enabled, the transition of the btag directive is as follows: Figure 26 Instead Figure 27 Execution as shown. Therefore, Figure 28 Corresponding to from Figure 27 Features for data access and non-batch tag access, and Figure 26 The functionality for accessing btags.

[0315] like Figures 26 to 28 As shown, when virtualization tagging is enabled in Phase 1 or Phase 2, memory access instructions (other than bulk or non-bulk tag read / write instructions) can specify a virtual address as the target address intended to define the location of a given data item to be accessed by the memory access instruction. This virtual address actually corresponds to the virtual address or intermediate address specified in tag table address areas 202, 208, and 210 for storing allocated tags. This is in Figures 26 to 28The data is represented as "data2" and corresponds to the data access tag operation.

[0316] This data access tag operation will refer to Figure 29 Further details are provided. As shown in the figure, the address space region is designated as the allocation tag memory address region 240 (which may correspond to tag table address regions 202, 208, 210). The address space can 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 allocation tag memory address region 240. Data Z 244 (i.e., the data item) is also stored within the address space but outside the allocation tag memory address region 240. Tag Z 242 corresponds to the allocation tag associated with data Z and is used in tag checks performed when data access to data Z 242 is requested.

[0317] Load or store operations (LDR / STR) can be requested for tag inspection, and using the techniques described above, the target data address of the address operands 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. For example... Figure 29 As shown, the target data address corresponds to the location of stored data Z 244 in the address space, and the target tag address corresponds to the location of stored tag Z 242 in the address space. Tag checking can be performed on a load or store operation using tag Z 242 and the address tag derived from the address operand of the tag-checked load or store operation. See the example of the tag checking operation for reference. Figure 4 describe.

[0318] Alternatively, in contrast to the load or store operation of tag inspection, a tag access instruction (LDG(M) / STG(M, where LDG and STG represent non-bulk tag read and write instructions, respectively, and LDGM and STGM represent bulk tag read and write instructions, respectively)) can be requested. In this case, there will be no data access to data Z 244. Instead, the target tag address will be derived from the target data address of the tag access instruction, and this target tag address can be used to access tag Z 242.

[0319] However, individually, the load or store operation LDR / STR can specify an address operand corresponding to a data address in the tag region. As shown, the load or store operation can specify an address operand corresponding to the data address of tag Z 242 stored in the tag memory address region 240. This address operand of the load or store operation might originally be intended to define the location of a given data item in the address space to be accessed by the load or store instruction. That is, the load or store operation could be a memory access operation intended to access a data item located in the address space rather than an allocation tag. However, since the allocation tag is stored in a separate region of virtual / intermediate physical address space (i.e., the tag allocation memory address region 240), the load or store operation may unintentionally (or intentionally, if used as part of a potential exploit by an attacker) instead specify a virtual address or intermediate address in the tag allocation memory address region 240. This is known as a data access to tag operation.

[0320] By providing architectural support to deny read or write access to the data value (i.e., tag Z 242) stored at the memory address in the allocated tag memory address region 240 in response to a determination of a data memory access (i.e., data access to tag operation) request, specifying a target address corresponding to the memory address in the allocated tag memory address region, unintentional or intentional access to the allocated tag can be prevented using data memory access requests (i.e., load or store).

[0321] Refer again Figure 1 The device 2 includes a data access to tag inspection circuit 32 for performing data access to tag inspection, such as... Figure 30 and Figure 31 As shown. Data access to tag checks will refer to... Figure 30 To explain in more detail.

[0322] At step 3000, a data memory access request for the specified target address is executed. The data memory access request can be, for example, a load or store request (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 previously described special tag read / write instructions LDG, STG, LDGM, STGM). See reference... Figure 29 As explained, a data memory access request can be a data access to tag memory access operation, that is, a data memory access request can be a load or store operation that specifies an address operand corresponding to an address in a memory region designated as a storage allocation tag.

[0323] At step 3002, 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 allocation tags. This determination is based on memory address region definition information defining the allocation tag memory address region designated for storing allocation tags. Figure 29 As shown, the tag memory address region can be allocated in an address space other than the physical address space (such as a virtual address space or an intermediate physical address space).

[0324] 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 examples, the memory address region definition configuration information includes at least one of the following: information indicating the tag table base address; and information indicating the table size. In some examples, the tag table base address indicates the location within the address space of the tag table region designated for storing allocated tags, and may correspond to the tag table regions discussed above. For example, the memory address region definition information may be previously provided regarding... Figure 18 The description of the tag table base address information is VTB, VTB0, VTB1, or VGB.

[0325] At 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 storing allocation tags, then read or write access to the data value stored at the memory address in the allocation tag memory address region is denied.

[0326] Denying read or write access may include triggering a fault, such as generating a fault signal indicating that the 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 examples, when a read access is requested, instead of reading the data value, zero is returned. Denying write access may include ignoring the write access request, i.e., not performing the requested write access.

[0327] At 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 examples, permitting read or write access may include performing a read or write access to the data value. In other examples, permitting read or write access includes not rejecting a read or write access performed by the data access to tag checking circuitry. However, in these examples, a read or write access may not be performed for one or more other reasons. That is, in some examples, the fact that the tag access to data checking circuitry has not yet rejected a read or write access does not necessarily mean that a read or write access is actually performed (e.g., the read / write access may fail other kinds of permission checks applied by MMU 6).

[0328] Now refer to Figure 31 This describes another example of data access to a tag check. At step 3100, the data storage access request specifies the target address. Step 3100 may correspond to... Figure 30 Step 3000. At 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 may correspond to... Figure 30 Step 3002.

[0329] At step 3104, it is determined whether the data access to tag check enable information indicates that data access to tag check is enabled for data storage access requests. The data access to tag check enable information can identify whether check for privileged data storage access requests is enabled.

[0330] In some examples, the data access to tag check enable information is used to identify whether the data access to tag check for non-privileged data storage access requests is enabled, independently of checking whether privileged data storage access requests are enabled.

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

[0332] This can prevent instructions executed with insufficient privileges from updating data access to tag check enable information. For example, non-privileged code might not be able to update data access to tag check enable information, while privileged code might be able to do so.

[0333] Tag access to data inspection enabled information may include fields in control registers. For example, refer to Figure 18System control registers (such as SCTLR2_ELx) can specify the Data Access to Tag Check Enable Indicator (nDGA) to indicate whether Data Access to Tag Check is enabled. Separate read and write controls can be supported to specify whether Data Access to Tag Check is enabled for read operations and separately for write operations. For example, system control registers (such as SCTLR2_ELx) can specify the Read Data Access to Tag Check Enable Indicator (nDGAR) and the Write Data Access to Tag Check Enable Indicator (nDGAW). Therefore, in some examples, the Read Data Access to Tag Check Enable Indicator and the Write Data Access to Tag Check Enable Indicator may be stored in the same control register. In other examples, the Read Data Access to Tag Check Enable Indicator may be stored in a different control register than the one storing the Write Data Access to Tag Check Enable Indicator.

[0334] In some examples, separate privileged and non-privileged data memory access controls can be supported to specify whether data access to tag checks are enabled for privileged data memory accesses, and separately for non-privileged data memory accesses. For example, different registers, such as different separate versions of the system control register (like SCTLR2_ELx discussed above), can specify different privileged / non-privileged versions of the data access to tag check enable indicator nDGA. In some examples, the privileged data memory access data access to tag check enable indicator and the non-privileged data memory access data access to tag check enable indicator can be stored in the same control register.

[0335] Therefore, in some specific implementations, in order to determine whether the Data Access to Tag Check Enable information indicates that Data Access to Tag Check is enabled for data memory access requests, the system control register can be checked to determine whether the Data Access to Tag Check Enable Indicator (such as nDGA, nDGAR, nDGAW) specifies whether Data Access to Tag Check is enabled for data memory access requests.

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

[0337] Data access tag check enable information can also be specified in a translation table entry corresponding to the target address of the data storage 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 for generating an intermediate address in stage 1 or a physical address in stage 2 can also specify data access tag check enable information.

[0338] At step 3106, it is determined whether the tag location address determination circuit is operating in virtualized tagging mode. As discussed herein, tag location address determination circuitry may be provided to determine, when operating in virtualized tagging mode, a tag location address identifying the location of the allocated tag corresponding to the given data item in a first address space other than the physical address space, based on a data location address identifying the location of the given data item in a first address space other than the physical address space.

[0339] When the tag location address determination circuit operates in virtualized tag mode, as referenced Figure 29The load or store operation discussed may unintentionally specify address operands corresponding to data addresses in the region designated for storing allocation tags. Therefore, enabling data access to tag checks when operating in virtualization tag mode can help prevent unintentional data access to allocation tags.

[0340] At step 3108, it is determined whether the data memory access request is triggered by an instruction other than at least one type of data access instruction that is permitted to access the allocation tag in the allocation tag memory address region. In some examples, a certain type of data access instruction may be permitted to access the allocation tag in the allocation tag memory address region. For example, bulk tag or non-bulk tag read or write instructions (described above), or (regarding...) Figure 29 The (described) tag setting instructions can be a category of data access instructions that allow access to the allocated tag in the allocated tag memory address region.

[0341] At 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.

[0342] At step 3112, read or write access to the data value stored at the memory address in the allocated tag memory address region can be denied. This step may correspond to... Figure 30 Step 3004 in the process. Step 3112 may be performed in response to the determination that the combination of step 3102 with any one or more of steps 3104, 3106, 3108, and 3110 is satisfied (i.e., affirmatively determined). It should be understood that any of steps 3104, 3106, and 3108 may be omitted, or the order may be changed without altering the function. For example, although in Figure 31 The diagram shows that each step leads to the next step, but all steps 3102 to 3110 can be performed simultaneously, and the result is used in step 3112 to determine whether to deny read access or write access.

[0343] In some examples, step 3112 can be performed independently of the determination in step 3104. For example, for non-privileged data memory access, read or write access can be denied at step 3112, regardless of whether the data access to tag check enable information determined at step 3104 indicates that data access to tag check is enabled for the data memory access request.

[0344] In step 3114, read or write access to the data value stored at the memory address in the allocated tag memory address region is permitted. This step may correspond to... Figure 30Step 3006 in the example. In some examples, if any of steps 3102 through 3110 (or the steps actually used in a given specific implementation) produces a "no" result, then step 3114 may be performed.

[0345] Figure 32 An example of data address translation, including data access to tag inspection, is illustrated. At step 3200, a data access instruction is executed.

[0346] At step 3202, it is determined whether stage 1 address translation is enabled prior to the translation. 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.

[0347] If Stage 1 address translation is enabled, then at step 3204, it is determined whether a virtual tag (represented as VMTE) is enabled. If Stage 1 address translation is disabled, the method proceeds directly to step 3214.

[0348] If it is determined that virtual tagging is enabled, then at step 3206, it is determined whether data access to tag checking is enabled (indicated by "Tag access checking enabled?"). This can be determined based on the determination that data access to tag checking is enabled for data access, as referenced in [reference missing]. Figure 30 and Figure 31 The subject of discussion.

[0349] If it is determined that data access to tag checking is enabled, then at step 3208, it is determined whether the data access corresponds to an access to a memory region designated for storing the allocation tag. For example, it may be determined whether the data access specifies a target address corresponding to a memory address in the allocation tag memory address region.

[0350] If it is determined that the data access corresponds to an access to a memory region designated for storing allocation tags, then at step 3210, a data access fault is indicated. This may include triggering a fault indication.

[0351] If the virtual tag is disabled at step 3204, the data access to tag check is disabled at step 3206, and / or the data access does not specify a target address corresponding to the memory address in the allocated tag memory address region, the method proceeds to step 3212. If a data access failure is flagged at step 3210, the process proceeds to step 3212.

[0352] At step 3212, a data address translation operation is applied to the phase 1 translation to translate the virtual address designated as the target address of the data access operation into the corresponding intermediate data address in the intermediate address space. Step 3212 may correspond to Figure 24 Step 2406.

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

[0354] At 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).

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

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

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

[0358] Computer-readable code may include a mixture of code representations for manufacturing apparatus, such as one or more of RTL representations, netlist representations, or other computer-readable definitions used in the semiconductor design and manufacturing process for manufacturing apparatus embodying the present invention. Alternatively or additionally, the concept may be defined in a combination of computer-readable definitions used in the semiconductor design and manufacturing process for manufacturing apparatus and computer-readable code defining instructions that will be executed by the defined apparatus once manufactured.

[0359] Such computer-readable code can be contained in any known transient computer-readable medium (such as wired or wireless transmission of code over a network) or non-transient computer-readable medium such as semiconductors, disks, or optical discs. Integrated circuits made using computer-readable code may include components such as one or more of the following: a central processing unit, a graphics processing unit, a neural processing unit, a digital signal processor, or other components that embody the concept independently or collectively.

[0360] Figure 33Examples of emulator implementations that can be used are illustrated. While the previously described embodiments implement the invention in terms of means and methods for operating specific processing hardware supporting the technologies involved, it is also possible to provide an instruction execution environment according to the embodiments described herein, which is implemented using a computer program. Such computer programs are generally referred to as emulators, in part because they provide a software-based implementation of a hardware architecture. Types of emulator computer programs include simulators, virtual machines, models, and binary converters, including dynamic binary converters. Typically, the emulator implementation can run on a host processor 3306, which optionally runs a host operating system 3304, thereby supporting the emulator program 3302. In some arrangements, multiple emulation layers may exist 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 were required to provide emulator implementations that execute at a reasonable speed, but such approaches may be reasonable in certain situations, such as when it is desirable to run code native to another processor for compatibility or reuse reasons. For example, the emulator implementation may provide additional functionality to the instruction execution environment that is not supported by the host processor hardware, or provide an instruction execution environment that is typically associated with a different hardware architecture. An overview of the simulation is given in the following literature: “Some Efficient Architecture Simulation Techniques”, Robert Bedichek, Winter 1990 USENIX Conference, pp. 53-63.

[0361] With respect to embodiments previously described with reference to specific hardware constructions or features, equivalent functionality may be provided in simulated embodiments by suitable software constructions or features. For example, specific circuitry may be implemented as computer program logic in simulated embodiments. Similarly, memory hardware such as registers or caches may be implemented as software data structures in simulated embodiments. Where one or more of the hardware elements referenced in the previously described embodiments are present in an arrangement on host hardware (e.g., host processor 3306), some simulated embodiments may utilize the host hardware where appropriate.

[0362] The simulator 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 target code 3300 (which may include applications, operating systems, and management programs). This program interface is identical to the interface of the hardware architecture modeled by the simulator program 3302. Therefore, the simulator program 3302 can be used to execute the program instructions of the target code 3300 from within the instruction execution environment, enabling a host computer 3306, which does not actually possess the hardware features of the device 2 discussed above, to emulate these features.

[0363] Therefore, the simulator program 3302 may have instruction decoding program logic 3314, which simulates instruction decoding and processing in a manner equivalent to the functions provided by the instruction decoding circuit 4 and execution circuit 16 described above. The instruction decoding program logic 3314 decodes the instructions of the target code 3300 and maps these instructions to the corresponding instruction sets in the local instruction set of the host device 3306. The memory management (address translation) program logic 3308, the tag checking program logic 3312, and the data access to tag checking program logic 3318 simulate the functions of the previously described MMU 6, tag checking circuit 34, and data access to tag checking circuit 32, including address translation, tag checking, and support for virtual / intermediate tags. The host memory mapping program logic 3310 maps register access and memory access operations requested by the target code to accesses to corresponding data structures maintained on the host hardware of the host device 3306, such as by 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 a simulated physical address space, which the target software 3300 interprets as corresponding to physical locations in the memory system. However, host memory mapping logic 3110 further maps the simulated physical addresses obtained by memory management logic 3308 based on translation tables defined for target code 3300 to host virtual addresses used to access host memory in host processing device 3306. These host virtual addresses themselves can be translated into host physical addresses using standard address translation mechanisms supported by the host (the translation from host virtual address to host physical address is outside the scope controlled by simulator program 3302).

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

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

[0366] While exemplary embodiments of the invention have been described in detail herein with reference to the accompanying drawings, it should be understood that the invention is not limited to those precise embodiments, and 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.

Claims

1. An apparatus, the apparatus comprising: A tag checking circuit is configured to perform a tag checking in response to a memory access instruction for tag checking, the memory access instruction for tag checking specifying an address operand for defining a target data address corresponding to a target data item having an associated allocation tag stored in the memory system, the tag checking including triggering an error handling response in response to detecting a tag mismatch between the associated allocation tag for the target data address obtained from the memory system and an address tag associated with the address operand; and A memory management circuit, configured to control access to the target data address based on memory attribute information associated with the target data address, the memory attribute information indicating whether the target data address is in a non-tagged memory region where the tag check is not required; wherein: The memory management circuitry is configured to determine, at least based on whether memory attribute information associated with the target data address of the memory access instruction checked with the tag indicates that the target data address is in the untagged memory region, whether to perform a tag location address translation operation on the architecture to obtain a tag location physical address for locating the associated assigned tag in the physical address space, the tag location physical address being separate from the data location physical address for locating the target data item in the physical address space.

2. The apparatus of claim 1, wherein the memory management circuitry is configured to suppress the tag location address translation operation on the architecture in response to detecting that the target data address is in the untagged memory region.

3. The apparatus of any one of claims 1 and 2, wherein the memory management circuitry is configured to suppress the execution of the tag location address translation operation on the architecture in response to detecting that at least one tag translation mode indicator indicates that a virtualization tag translation mode is disabled, the virtualization tag translation mode comprising the following mode: wherein the target data item is mapped to the data location physical 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 physical address based on tag translation address mapping information corresponding to the target data address, the tag translation address mapping information being separate from the data translation address mapping information.

4. The apparatus of claim 3, wherein when the virtualization tag conversion mode is disabled, the memory management circuitry is configured to map both the target data item and the associated allocation tag to the data location physical address.

5. The apparatus according to any of the preceding claims, wherein, In response to detecting that the memory attribute information indicates that the target data address is in the tag memory region, the memory management circuitry is configured to determine, based on whether at least one additional condition is met, whether to perform the tag location address translation operation for translating the tag location first address on the architecture.

6. The apparatus of claim 5, wherein the additional condition is satisfied depending on at least one label conversion mode indicator indicating that a virtualization label conversion mode is enabled, the virtualization label conversion mode comprising the following mode: wherein the target data item is mapped to the data location physical address based on data conversion address mapping information corresponding to the target data address, and the associated allocation label is mapped to the label location physical address based on label conversion address mapping information corresponding to the target data address, the label conversion address mapping information being separate from the data conversion address mapping information.

7. The apparatus according to any of the preceding claims, wherein, When the tag location address translation operation is to be suppressed architecturally, the memory management circuitry is configured to prevent signaling of any faults based on the tag location address translation operation.

8. The apparatus according to any of the preceding claims, wherein, When the tag location address translation operation is to be suppressed at the architectural level, the memory management circuitry is configured to suppress the tag location address translation operation from being actually executed.

9. The apparatus according to any one of claims 1 to 7, wherein, When the tag location address translation operation is to be suppressed at the architecture level, the memory management circuitry is configured to allow the tag location address translation operation to be performed, but to prevent changes in the architecture state caused by the tag location address translation operation.

10. The apparatus according to any preceding claim, wherein the memory management circuitry is configured to infer whether the target data address is in the untagged memory region based on one or more memory attribute indicators of the memory attribute information, the one or more memory attribute indicators being used to indicate one or more memory region attributes unrelated to the execution of the tag check.

11. The apparatus according to any preceding claim, wherein the memory management circuitry is configured to determine the target data address in the unmarked memory region in response to detecting that the target data address is in a region other than a normal write-back cacheable memory region.

12. The apparatus according to any preceding claim, wherein the memory management circuitry is configured to determine whether to perform the tag location address translation operation on the architecture based on memory attribute information derived from at least one translation table entry accessed in a data location address translation operation for translating the target data address to the data location physical address.

13. The apparatus according to any of the preceding claims, wherein, For a given stage of address translation, the memory management circuitry can perform the tag-location address translation operation based on address mapping information from tag-translation table entries, which are different from the data translation table entries that provide address mapping information for the address translation of the given stage in the data translation address translation operation used to convert the target data address to the data location physical address.

14. The apparatus of claim 13, wherein the address translation of the given stage includes a first stage of address translation for translating from a virtual address space to an intermediate address space.

15. The apparatus of any one of claims 13 and 14, wherein the address translation of the given stage includes a second stage of address translation for translating from an intermediate address space to a physical address space.

16. A computer-readable code for manufacturing an apparatus according to any of the preceding claims.

17. A method, the method comprising: A memory access instruction in response to a tag check specifies an address operand for defining a target data address corresponding to a target data item having an associated allocation tag stored in the memory system, determining whether the target data address is in a non-tagged memory region that will not require tag checking based on memory attribute information associated with the target data address, the tag check including triggering an error handling response in response to detecting a tag mismatch between the associated allocation tag for the target data address obtained from the memory system and the address tag associated with the address operand; as well as At least based on whether the memory attribute information associated with the target data address of the memory access instruction checked with the tag indicates that the target data address is in the untagged memory region, it is determined whether to perform a tag location address translation operation on the architecture to obtain a tag location physical address for locating the associated allocated tag in the physical address space, the tag location physical address being separate from the data location physical address for locating the target data item in the physical address space.

18. A computer program for controlling a host data processing device to provide an instruction execution environment for executing target program code, the computer program comprising: Tag checking procedure logic, the tag checking procedure logic being used to perform tag checking in response to a tag checking memory access instruction, the tag checking memory access instruction specifying an address operand for defining a target data address corresponding to a target data item having an associated allocation tag stored in an analog memory system, the tag checking including triggering an error handling response in response to detecting a tag mismatch between the associated allocation tag for the target data address obtained from the analog memory system and an address tag associated with the address operand; and A memory management program logic, configured to control access to the target data address based on memory attribute information associated with the target data address, wherein the memory attribute information indicates whether the target data address is in a non-tagged memory region where the tag check is not required; wherein: The memory management logic is configured to determine, at least based on whether the memory attribute information associated with the target data address of the memory access instruction checked with the tag indicates that the target data address is in the untagged memory region, whether to perform a tag-location address translation operation on the architecture to obtain a tag-location simulated physical address for locating the associated assigned tag in the simulated physical address space, the tag-location physical address being different from the data-location physical address for locating the target data item in the simulated physical address space.

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

Images