A property that is read as X for a page of memory address space.

Abstract

The processing circuit (4) performs data processing in response to the instructions. The memory management circuit 28 controls access to the memory based on page table information that can associate a given page of the memory address space with a property read as X that indicates that a read to an address within the given page of the memory address space should be treated as returning a specified value X. In response to a read request issued to read a read target value for a read target block of the memory address space, and determining that at least a portion of the read target block corresponds to a page associated with the property read as X, the memory management circuit (28) controls to return the specified value X to the processing circuit (4) as at least a portion of the read target value. This allows large regions of the memory address space to be treated as storing the specified value without having to commit physical memory for those regions.

Description

[Technical field]

[0001] The present application relates to the field of data processing.

[0002] Memory management circuitry may be provided within a processing system to control access to the memory address space based on page table information for each page of the memory address space. For example, the page table information may specify access permissions, address translation mappings, and other attributes associated with a given page.

[0003] At least some embodiments include an apparatus, comprising: processing circuitry for performing data processing in response to instructions; a memory management circuit for controlling access to the memory based on page table information capable of associating a given page of the memory address space with a property, read as X, that indicates that a read to an address within the given page of the memory address space should be treated as returning a specified value X; An apparatus is provided, wherein, in response to a read request issued by the processing circuit to read a read target value for a read target block of a memory address space, determining that at least a portion of the read target block corresponds to a page associated with a property read as X, the memory management circuit is configured to control returning a specified value X to the processing circuit as at least a portion of the read target value.

[0004] At least some embodiments include a method, comprising: performing data processing in response to the instructions; controlling access to memory based on page table information capable of associating a given page of the memory address space with a property, read as X, that indicates that a read to an address within the given page of the memory address space should be treated as returning a specified value X; The method provides for, in response to a read request issued by a processing circuit to read a read target value for a read target block of a memory address space, returning a specified value X to the processing circuit as at least a portion of the read target value in response to determining that at least a portion of the read target block corresponds to a page associated with a property read as X.

[0005] At least some embodiments provide a computer program for controlling a host data processing apparatus to provide an instruction execution environment for executing target code, the computer program comprising: instruction decode program logic for decoding instructions of the target code in response to the instructions of the target code for controlling a host data processing apparatus to perform data processing; and memory management program logic for controlling access to the simulated memory address space based on page table information capable of associating a given page of the simulated memory address space with a property, read as X, that indicates that a read to an address within the given page of the simulated memory address space should be treated as returning a specified value X; A computer program product is provided, wherein, in response to a read request to read a read target value for a read target block of a simulated memory address space and determining that at least a portion of the read target block corresponds to a page associated with a property read as X, the computer program product is configured to control the memory manager program logic to return a specified value X as at least a portion of the read target value.

[0006] The computer program may be stored in a computer readable storage medium. The storage medium may be transitory or non-transitory. [Brief description of the drawings]

[0007] Further aspects, features, and advantages of the present technique will become apparent from the following description of examples, read in conjunction with the accompanying drawings. [Figure 1] 1 illustrates an example of a data processing device. [Diagram 2] 3 illustrates the processing of read and write requests to memory. [Diagram 3] Illustrates the processing of read and write requests to a region of memory address space specified by page table information as being associated with a property read as X. [Figure 4] FIG. 11 is a flow diagram illustrating the processing of a read request. [Diagram 5] FIG. 11 is a flow diagram illustrating the processing of a write request. [Figure 6] 1 illustrates the use of a permission indirection table to support a larger number of permission types than can be directly encoded in the page table information. [Figure 7] 1 illustrates the use of a further indirection table that is used to specify a specified value X to be returned for a read into a memory address region having a property read as X. [Figure 8] Indicates an address-dependent variation of the property read as X. [Figure 9] Shows tag check operation. [Figure 10] 1 shows an embodiment of a simulator.

[0008] The apparatus has a processing circuit for performing data processing in response to the instructions, and a memory management circuit for controlling access to the memory based on page table information having an encoding capable of associating a given page of the memory address space with a property read as X indicating that a read to an address within the given page of the memory address space should be treated as returning a specified value X. In response to a read request issued by the processing circuit to read a read target value for a read target block of the memory address space, and determining that at least a portion of the read target block corresponds to a page associated with the property read as X, the memory management circuit controls to return the specified value X to the processing circuit as at least a portion of the read target value. This allows relatively large regions of the memory address space to be treated as storing the specified value X without having to commit physical memory for those regions of the memory address space.

[0009] An alternative approach to reduce the amount of physical memory used for a region of memory address space known to have a specified value X may be to allocate a single page of physical memory to store the specified value X, and use page table information to map each virtual address of the corresponding region of memory address space to the same physical page. With this approach, no special access permissions or attribute types need to be supported at the architecture level to support the ability to use a smaller amount of physical memory to represent a larger region of virtual memory set to the specified value X, since software can provide this behavior using the address translation mapping fields of the page table information. However, this approach has several drawbacks. First, at least one page-sized block of physical memory must still be allocated to physically store the data having the specified value X, even though that physical memory may be mapped to several different virtual pages. In implementations with larger page sizes (e.g., page sizes larger than 4kB) or where page tables at higher levels of the hierarchy support the ability to define block descriptors that define the same set of attributes for memory regions larger than the size of the region corresponding to one page mapped at the last level of the hierarchy, this approach may still require a relatively large amount of physical memory to be committed to represent the specified value X (e.g., a block descriptor may cover several MB or GB of memory). Reserving physical storage to store the specified value X (which may often be a default value such as 0 that is of no interest to the software) reduces the percentage of available physical memory implemented in the hardware that is available to store more useful data that is not known to have the specified value X. When less physical storage is available for meaningful data, other data may need to be paged out to external storage, which impacts performance for accesses that require that data.Also, for reads to data having a specified value X, those reads may still incur relatively long latencies because they must access the data from the cache or from the underlying physical memory storage.

[0010] In contrast, in the technique described below, a page of the memory address space can be associated with a property read as X by page table information, which means that a read to an address within that page should be treated as returning the specified value X. This means that when a read request is issued by the processing circuit to read a read target value for a read target block of the memory address space, and the memory management circuit determines (based on the target address of the read request) that at least a portion of the read target block corresponds to a page associated with the property read as X, the memory management circuit can be controlled to return the specified value X to the processing circuit as at least a portion of the read target value. This eliminates the need to commit physical memory for the region of the memory address space to which the specified value X is assigned, since the memory management circuit can simply identify the specified value from the page table information. This therefore allows for better utilization of the remaining physical memory storage implemented within the system, most of which can be used for other data that does not have the specified value X, improving performance of other data that would otherwise have to be sent to external storage. This technique may also improve performance of reading the specified value X itself, since the memory management circuitry can typically look up page table information sooner than accessing a cache or memory to read data stored in physical memory, and therefore return the value X at an earlier stage in processing.

[0011] For at least one variant of the read as X property supported by the memory management circuitry, in response to determining that all of the read target blocks correspond to pages associated with the read as X property, the memory management circuitry is configured to suppress issuing cache access requests or memory access requests to read the read target value from the cache or memory. Thus, use of the read as X property can avoid the need for the value X to be read from the cache or memory (instead, the value X can be generated within the memory management circuitry based on the detected read as X property represented in the page table information). By eliminating the latency of cache access, this speeds up processing of read requests and also frees up cache capacity for other data.

[0012] In this variation, the read target block specified by the read request may straddle a page boundary between one page that has the property of being read as X and another page that does not have the property of being read as X. In this case, only a portion of the read target value returned to the processing circuit may specify the specified value X, and the other portion may be read from the cache or memory as with a normal read access request. In practice, accesses that cross page boundaries typically require two separate cache lookups because they may also cross cache line boundaries, and thus the accesses can be effectively treated as two separate accesses, one to a portion in a first page and the other to a portion in a second page. Thus, one of these accesses, corresponding to a page of the memory address space that cannot be read as X, may trigger a cache lookup to access memory as normal, while the other one of the accesses, corresponding to a page that is read as X, may suppress the cache lookup and return the specified value X as the value returned for that portion of the read target block. In practice, given that it is common to use address alignment of memory accesses to reduce the likelihood of an access crossing a page boundary, and also that the page size may be relatively large compared to the size of the read target block so that the likelihood of crossing a page boundary for a given access is low, scenarios in which a read access only partially corresponds to the page read as X may be relatively rare.

[0013] The read as X property may be useful for a wide range of scenarios in which relatively large blocks of memory address space need to be set as storing a particular value. For example, when regions of virtual address space are first initialized, it may be desirable to clear the previous contents of those regions to ensure that intervening reads return a known value (e.g., 0) before any writes to those regions are performed, independent of data previously stored for those virtual addresses. Thus, newly initialized regions of virtual address space may be assigned the read as X property until the first write operation to those regions is encountered. For example, a copy-on-write technique may be used by software in which, upon first allocation, an attribute of a newly initialized page may be set to indicate that it is read as X, such that the first write to that page triggers a fault that may cause an exception handler to allocate a new block of physical memory, map that physical memory to a virtual page using the address translation mapping in the page table information, and then clear the read as X property to subsequently treat the virtual page as normal memory. By providing an architecture that supports the property read as X, this copy-on-write approach desired by the software may be supported with higher utilization of physical storage and may improve performance compared to the alternative of controlling the copy-on-write by using address translation mapping to map to a single page of committed physical memory to store the specified value X as described above.

[0014] Of course, this copy-on-write approach is just one example, and there may be many other cases in which software finds it useful to be able to indicate that a region of virtual address space is to be treated as having a specified value X, without committing any physical memory storage.

[0015] Another example where the property read as X may be useful is in a system that supports a tag checking circuit that performs a tag checking operation to determine whether an address tag associated with a target address of a memory access request corresponds to an allocation tag associated with a memory system location corresponding to the target address. The tag checking circuit triggers a tag error handling response in response to the tag checking operation detecting a mismatch between the address tag and the allocation tag. As described in more detail below, such a tag checking operation may be useful to provide architectural support for detecting certain memory usage errors that may cause security vulnerabilities that may be exploited by an attacker wishing to cause software to access a region of memory that the software should not be able to access. When a region of memory address space is initially allocated, a corresponding allocation tag may be assigned, and a pointer intended to be used to reference that region of memory address space may be assigned the corresponding address tag. When the pointer is subsequently used to generate an address for accessing memory, the tag checking circuit (at least when in tag checking mode) may compare the address tag of the target address of the memory access request with the allocation tag associated with the addressed memory system location, and may then trigger a tag error handling response in response to any detected mismatch. The tag error handling response can be a course of action such as triggering a fault, logging the error in an error log or other storage location.

[0016] In systems that support tag checking operations, the allocation tag for a block of memory may itself be accessed by a read access to a particular block of memory address space, and thus the allocation tag itself may consume physical storage. A particular tag value may be so common that it may be common for relatively large regions of memory address space that are larger than a page in size to be configured by software as having the same tag value. For example, software may choose to set a particular value of the allocation tag for a region of memory address space in which there is a greater security requirement, and then leave the allocation tag for any other region of memory as having a particular default tag value (e.g., 0). By prioritizing the use of non-default tag values ​​for the allocation tags of regions with greater security requirements, this reduces the chance that a memory access that is not intended to access one of these regions will, by chance, have an address tag that matches the allocation tag of the addressed memory system location. This means that it may be relatively common that software may want to configure the allocation tags for relatively large regions of memory such that they all have the same tag value (e.g., 0). Thus, in the absence of support for a property read as X, a relatively large amount of physical memory storage may be used just to store default allocation tag values ​​for memory regions with no specific security requirements. By associating a property read as X with pages of memory address space intended to hold allocation tag values ​​having a specified value X, this can greatly improve the efficiency of utilization of available physical memory storage in systems that support memory tagging.

[0017] Thus, in response to the memory management circuitry determining, for a tag read request to obtain a given allocation tag to be checked in a tag check operation, that a page corresponding to the given allocation tag is associated with a property read as X, the memory management circuitry is configured to control to return the specified value X as the given allocation tag, and the tag check circuitry is configured to perform the tag check operation using the specified value X for the given allocation tag. Thus, the tag check operation may be performed using the specified value X provided by the memory management circuitry without having to access a cache or physical memory storage to obtain the specified value X, which may improve performance and utilization of available physical memory.

[0018] In systems that support memory tagging, the property read as X may be specified for both pages of memory address space used to store data and for pages of memory address space used to store allocation tags. Thus, the mechanism read as X need not be a data-specific or tag-specific property, but may be a general architectural mechanism available for use for any information associated with a page of memory address space.

[0019] In some embodiments, in response to determining that for at least one variant of the property read as X, the read target block corresponds to a page associated with the property read as X, the memory management circuitry controls to return the specified value X to the processing circuitry as part of the read target value, allowing a cache access request or a memory access request to be issued to read another portion of the read target value from the cache or memory. In this case, the specified value X is returned only for a portion of the read target value, and the other portion is returned from the cache or memory as in a normal memory access. This may be useful to allow the data actually stored in the physical memory to be expanded into a wider form with additional bits implied based on the property read as X that do not need to be stored in the physical memory. For example, for systems that support memory tagging, the specified value X returned for a portion of the read value may indicate an allocation tag that is implicitly defined in association with the corresponding data stored in the physical memory, such that the allocation tags for memory regions to which the default allocation tag value is assigned may be implicitly determined based on the property read as X without requiring physical memory to be committed to store those tags.

[0020] Any data value or pattern of bits can be assigned as a specified value X to a page that has the property read as X.

[0021] For example, for at least one variant of a property read as X, the specified value X is 0. Treating pages having a property read as X as containing 0 may be particularly useful because there may be a greater number of software use cases in which large regions of memory are treated as storing 0 than for other non-zero values. For example, the copy-on-write and memory tagging use cases described above are both more likely to allocate 0 to pages read as X than other non-zero values.

[0022] However, it is also possible to implement at least one variant of the property read as X with a specified value X having a non-zero value. For example, for at least one variant of the property read as X, the specified value X is a value with all bits set to 1. For example, in a memory tagging implementation, an allocation tag value with all bits set to 1 (which may, for example, represent an "all match" tag value indicating that the tag is to be treated as matching any address tag value) may be reserved for special purposes. Thus, X=111111... may also be a good candidate for allocation in a large region of memory address space, so as to justify architectural support for encoding of page table information representing that a read into a page should be treated as returning all bits equal to 1.

[0023] Also, the specified value X may be a mixture of bit values ​​of 0 and 1. The specified value X may be thought of as a single value that spans the entire page, or X may be thought of as having a smaller number of bits that are repeated many times to fill the memory range corresponding to the page that has the property read as X.

[0024] It will be appreciated that there is a trade-off between the number of different options supported in an architecture for defining a specified value X and the amount of encoding space required to represent these different options in page table information or other configuration information. Some implementations may support a read-as-X encoding that corresponds to a single variant of the specified value X (e.g., X=0). In other embodiments, the memory management circuitry is configured to support two or more variants of the read-as-X property that correspond to different values ​​for the specified value X, enabling the use of the read-as-X behavior for a range of different values ​​that are allocated to a region of virtual memory without consuming physical memory.

[0025] In one embodiment, the memory management circuitry supports address-dependent variants of the property read as X, where for address-dependent variants, when a given page is associated with the address-dependent variant of the property read as X, the specified value X depends on the address of the given page, such that the memory management circuitry can select different values ​​when returning the specified value X as the read target value for different pages of the memory address space associated with the same encoding of the property read as X. For example, the specified value X may be selected depending on at least one bit of the address. For example, some architectures may use one or more most significant bits of the address (excluding any upper address bits not used to select a memory location) to indicate whether an access is being made from a user address space or a kernel address space, and it may be useful to return different values ​​as the specified value X for the property read as X depending on whether a user or kernel access is requested. This technique avoids the need to consume two different encodings of page table information to support this behavior, since a property read as a single type of X can serve both purposes, with additional information for selecting which value to return for a given value X coming from the address itself rather than from the page table information.

[0026] A variety of different behaviors can be implemented for writes to a page designated as having the property read as X. One option is for a write to a page read as X to trigger signaling of a fault, which may be useful to support the copy-on-write technique described above; the fault can cause an exception handler to run and allocate some physical memory for the page being written to before removing the read-as-X property for that page.

[0027] Alternatively, write requests to a page read as X can simply be ignored without disrupting processing on the processing circuitry by generating a fault. In this case, to implement the copy-on-write behavior, the software can also set the access permissions for the page read as X to indicate that no write access is allowed, thereby generating a fault on the first write to the page, allowing dynamic allocation of physical memory if actually needed to store any data other than the specified value.

[0028] Another option is that a write to a page designated as read as X may be interpreted as requesting that at least a portion of the write value (the value designated by the write request to be written to a write target block of the address space) be transferred to a predetermined system location. For example, the predetermined system location may be a location other than random access memory storage. For example, the predetermined system location may be one of: a trace buffer for storing diagnostic trace information, another processor other than the processor with the processing circuitry that issued the write request, and a peripheral device (input / output device). Use of the read as X property for a virtually addressed page of the address space may be a faster way of identifying a target location to be transferred along with the write data compared to translating the virtual address to a physical address, issuing a normal write request to the memory system specifying that physical address, and then using a physical address mapping component in the memory system to determine that the address corresponds to a predetermined system location and transferring the write data to that location. Thus, the read as X property may be useful in system locations where it is not necessary to read data from the predetermined system location, but an accelerated means of writing data to the predetermined system location is desired. Example use cases may include the following: A trace buffer to which diagnostic information can be sent for subsequent analysis to investigate behavior and performance problems that arise when a particular software program is executed on a processor. The instrumented software code may include a write memory access at a particular point in the code that specifies trace information to be written to the trace buffer; when the address of that memory access is mapped to a page that is read as X, this can cause the trace information to be transferred to the trace buffer more quickly than using the normal access mechanism. Accelerated access to input / output buffers of a network or other communications interface. Access to shared components that may require more information than the standard memory system bus interface can provide (e.g. access to DMA where it may be advantageous to pass information about the current execution context, or access to embedded tightly coupled multi-CPU systems operating in producer-consumer mode where page table attributes may be used to indicate, for example, that a particular hardware FIFO (first-in, first-out buffer) is to be used).

[0029] It will be appreciated that processing system designers may find other uses for such write behavior to a memory page read as X in the memory address space.

[0030] Thus, for a write request issued by the processing circuitry to write a write value to a write target block of the memory address space, in response to determining that at least a portion of the write target block corresponds to a page associated with a property read as X, the memory management circuitry is configured to process the write request in accordance with a write behavior read as X. The write behavior read as X includes one of triggering signaling of a fault, ignoring the write request, and forwarding at least a portion of the write value to a predetermined system location (e.g., a trace buffer, another processor, or a peripheral device).

[0031] In some implementations of instruction set architectures, a single type of write read as X behavior (e.g., failing to write to memory read as X) may be implemented and it may not be possible for software to select different write read as X behaviors.

[0032] In other embodiments, the memory management circuitry may support two or more variants of the read as X property corresponding to different read as X write behaviors. In this case, the particular read as X write behavior used for a particular write request may depend on software configurable control information, which may be specified in the page table information itself or separately in a control register or other configurable storage element. For example, the read as X write behavior may be specified on a per-page basis within the page table information or within other information referenced from the page table information for a particular page, or may be a global setting set for the entire device, for example using a control register indicating information (e.g., a write mode read as X specifying a value) that allows the read as X write behavior to be determined.

[0033] The read-as-X property of a given page of an address space may be encoded in different ways. In one embodiment, the memory management circuitry determines that a given page has the read-as-X property when a field of a page table entry corresponding to the given page has an encoding that indicates the read-as-X property. Thus, in this case, the page table entry encoding may directly specify whether a given page has the read-as-X property.

[0034] Another approach may be for the memory management circuitry to determine that a given page has a property read as X when the page table entry corresponding to the given page specifies an indirection table entry selection value that indicates a selected entry of the indirection table, and the selected entry of the indirection table has an encoding that identifies the property read as X. This may be useful when there is insufficient spare encoding space in the page table entry format to be able to encode all types of memory attributes / permissions available for selection by the programmer. Because the indirection table does not need to contain an entry for each page, there may be more space than is practical in the page table entry itself to represent a wider set of options for the property selected for a given page (the total number of indirection table entries may be less than the total number of property types selectable for a single indirection table entry, such that an indirection table entry that selects a value in a page table entry has fewer bits than the number of bits in one indirection table entry). Thus, in some embodiments, the property read as X may be encoded in the referenced entry of the indirection table rather than being encoded directly in the page table information.

[0035] The indirection table may be a structure stored in memory, or may be a hardware structure implemented, for example, using control registers accessed by system register instructions.

[0036] In an approach that supports an indirection table, the memory management circuitry may support at least two different encodings for selected entries of the indirection table that correspond to different variants of a property read as X. For example, the different variants of a property read as X may correspond to different values ​​for a specified value X, different read-as-X write behaviors, or may be distinguished by other access permissions or attributes that are indicated in combination with the property read as X.

[0037] In one approach, the memory management circuit may determine the specified value X for a given page based on an encoding of a further entry in a further indirection table, the further entry being indicated by an encoding of a selected entry of the indirection table. This recognizes that the number of different values ​​that software may want to specify for the specified value X may be much larger than the number of different property variants or behaviors (distinguished by characteristics other than the value of the specified value X) defined for a property read as X, and thus defining an indirection table to define the attribute / behavior variants read as X (other than the specified value X) and a further indirection table to define the specified value X may be more efficient than a single table having an encoding to represent each desired combination of property / behavior / specified value for a property read as X.

[0038] To support normal memory accesses to pages not designated as memory read as X, a given page table entry corresponding to a given page of the memory address space may specify an address mapping field that is used to perform address translation when the given page is not associated with the read as X property. The address mapping field may often be the largest field of a page table entry, occupying a significant portion of the overall number of bits of the page table entry.

[0039] However, when a page is associated with the property read as X, no address translation is required since no physical memory has been allocated to that page, and therefore the address mapping field may not be used.

[0040] In some embodiments, to avoid having to use up additional encoding space to encode other information for a page associated with a property read as X, the memory management circuitry may use the address mapping field of a given page table entry for purposes other than address translation. Thus, for a page read as X, a larger amount of encoding space may be available in the page table entry than would otherwise be possible for normal memory. For example, a specified value X may be indicated using the address mapping field. It is also possible to use the address mapping field to indicate other variations of the property read as X, such as different read as X write behaviors, or other attributes combined with the property read as X. By reusing the address mapping field to encode such information, the need to extend the page table entry format or to use other structures, such as indirection tables, to encode this information is reduced.

[0041] Other implementations may prefer not to use the address mapping field to encode information about a property read as X that is understood by the memory management circuitry to have a prescribed architecturally defined meaning. Instead, the address mapping field of the page table entry associated with a property read as X may be left free for software to use for any software-defined purposes not prescribed by the instruction set architecture supported by the processing circuit.

[0042] Specific embodiments will now be described with reference to the figures, with the understanding that the claims are not limited to these specific embodiments.

[0043] 1 illustrates diagrammatically an example of a data processing apparatus 2. The data processing apparatus has a processing pipeline 4 (e.g., an example of a processing circuit that may form part of a CPU (Central Processing Unit)). The processing circuit 4 is for executing instructions defined in an instruction set architecture (ISA) to perform data processing operations represented by the instructions. The processing pipeline 4 includes several pipeline stages. In this example, the pipeline stages include a fetch stage 6 for fetching instructions from an instruction cache 8, a decode stage 10 for decoding the fetched program instructions to generate micro-operations (decoded instructions) that are processed by the remaining stages of the pipeline, an issue stage 12 for checking whether operands required for the micro-operation are available in a register file 14 and for issuing a micro-operation for execution once the operands required for a given micro-operation are available, an execute stage 16 for executing the data processing operation corresponding to the micro-operation by processing the operands read from the register file 14 to generate a result value, and a writeback stage 18 for writing back the results of the processing to the register file 14. It will be appreciated that this is merely one example of a possible pipeline architecture and other systems may have additional stages or different configurations of stages. For example, an out-of-order processor may include a register renaming stage to map architectural registers specified by a program instruction or micro-operation to physical register specifiers that identify physical registers in register file 14. In some embodiments, there may be a one-to-one relationship between ISA-defined program instructions decoded by decode stage 10 and corresponding micro-operations processed by the execute stage.There may also be a one-to-many or many-to-one relationship between program instructions and micro-operations; for example, a single program instruction may be split into two or more micro-operations, or two or more program instructions may be fused together and processed as a single micro-operation.

[0044] The execution stage 16 includes several processing units for performing different classes of processing operations. For example, the execution units may include a scalar arithmetic / logic unit (ALU) 20 for performing arithmetic or logical operations on scalar operands read from the registers 14, a floating point unit 22 for performing operations on floating point values, a branch unit 24 for evaluating the results of branch operations and adjusting a program counter representing the current execution point accordingly, and a load / store unit 26 for performing load / store operations to access data in the memory systems 8, 30, 32, 34.

[0045] A memory management unit (MMU) 28 is provided to control memory access permission checks and to perform address translation between a virtual address specified by the load / store unit 26 based on the operands of a data access instruction and a physical address that identifies a storage location of the data in the memory system. The MMU has a translation lookaside buffer (TLB) 29 for caching address translation data from page tables stored in the memory system, whose page table entries define the address translation mappings and may also specify access permissions that govern whether a given process executing on the pipeline is allowed to read, write, or execute instructions from a given memory region. Although the MMU 28 is shown as being associated with the load / store unit 26, the MMU 28 may also be looked up upon instruction fetches triggered by the fetch stage 6 (alternatively, a separate instruction-side MMU may be implemented to handle instruction fetches apart from the data-side MMU used by the load / store unit 26 for data accesses, in which case both MMUs may cache information from a shared set of page tables in the TLB 29).

[0046] In this example, the memory system includes a level 1 data cache 30, a level 1 instruction cache 8, a shared level 2 cache 32, and a main system memory 34. It will be appreciated that this is only one example of a possible memory hierarchy and other arrangements of caches may be provided. The particular types of processing units 20-26 shown in the execution stage 16 are only one example and other implementations may have different sets of processing units or may include multiple instances of the same type of processing unit such that multiple micro-operations of the same type can be processed in parallel.

[0047] The apparatus 2 may also include multiple system components that may be accessible to the processing circuit 4 by issuing memory access requests that specify addresses mapped to those system components. For example, the system components may include a trace buffer 42 used to record diagnostic information that may be accessible to an external device via an I / O (input / output) port 44. The external device may use the diagnostic (trace) information to perform diagnostic analysis of the software running on the processing circuit 4, for example, to identify performance problems with the software. The diagnostic information may indicate, for example, the program flow of the sequence of instructions executed in the software, data accesses made by the software, and information about the internal state of the processor when executing the software. Trace hardware may be provided to automatically record trace information in response to monitoring the software execution and the processor state. Alternatively, if the software is implemented with trace generation instructions, the software itself may execute instructions (e.g., write access requests that specify addresses mapped to the trace buffer 42) to write software-defined trace data to the trace buffer 42.

[0048] Another example of a system component may be an additional processor 46 (e.g., another CPU), not explicitly shown in Figure 1, but which may include components 4, 8, 14, 28, 30, 32 similar to those shown for the first processor in Figure 1. Inter-processor communication may be implemented using read / write memory access requests managed by the MMU 28. The memory system may include a coherent interconnect for maintaining coherency between the caches of the respective processors using any known coherency protocol.

[0049] The system also includes a number of peripheral (input / output) devices 48. For example, peripherals 48 may include hardware accelerators designed to accelerate specific processing functions, network controllers, display controllers, user input devices, or any external (off-chip) devices that communicate with System 2 via input / output ports. Again, interaction with peripherals and I / O devices is performed by issuing read / write memory accesses that specify addresses mapped to these components.

[0050] Device 2 may also include tag checking circuitry 250, which is described in more detail below with respect to FIG.

[0051] It will be understood that FIG. 1 is only a simplified representation of some components of a possible processor pipeline implementation, and that the processor may include many other elements that are not shown for the sake of simplicity.

[0052] FIG. 2 illustrates the processing of read and write requests to pages of an address space treated as “normal” memory. The “normal” memory type may be used for pages intended to be used for normal random access data or instruction storage. When a read request is received, the MMU 28 looks up the virtual address specified by the read request in its TLB 29. If the TLB 29 already contains page table information for the virtual address, it uses the attributes and address translation mapping information provided by the page table information to control the translation of the virtual address to a physical address, checks the access permissions to determine whether the read request can be granted (a fault is signaled if the read request is not granted), and controls how to service the read request based on the attributes (e.g., the attributes may specify whether the data for the page is cacheable). If the TLB 29 does not already contain the necessary page table information for the virtual address, a page table walk operation is performed to obtain the necessary page table information from a page table structure stored in the memory system before proceeding to check the access permissions and perform the address translation. Thus, for a read access where the attributes in the page table information specify a "normal" memory type, if the access permissions are satisfied, the virtual address of the read access is translated to a physical address and then a read memory access request specifying that physical address is sent to the memory system. If the memory access request hits in one of the caches 30, 32, the data at the specified physical address may be read from the cache and returned to the processing circuitry 4. If the request misses in the caches 30, 32, an access is made to main memory 34 and the read target value is returned to the processing circuitry 4, for example, by writing the value to register 14.

[0053] For a write request, the TLB 29 lookup and (if necessary) page table walk are the same as for a read request. Based on attributes defined in the page table information for the virtual address of the write request, the MMU 28 determines whether the write request is permitted, and if permitted, a write memory access request is generated specifying a translated physical address obtained based on the target virtual address and the address mapping information specified in the page table information. The write request requests that a write data value provided by the processing circuitry 4 (e.g., based on an operand read from the register 14) be written to a corresponding location in the caches 30, 32 and / or main memory 34.

[0054] For various reasons, it may be useful for software to be able to control that relatively large regions of virtual address space are assigned predefined values, such as filled with zeros. Many operating systems implement mechanisms (in software) to provide copy-on-write zero-filled memory. Typically, this is done by setting up address translation mappings for the zero-filled regions of virtual addresses to map all of these regions into a single range of physical memory where zeros are stored. Thus, the amount of physical memory that needs to be committed can be reduced to the region (e.g., page or block) covered by a single page table entry of the page table information. However, when page sizes larger than 4kB are supported or larger regions of memory (e.g., sizes on the order of MB or GB) are covered within a single page table entry at higher levels of the page table hierarchy using block descriptors, reserving this amount of physical memory simply to store zeros becomes expensive.

[0055] FIG. 3 illustrates a new memory type that may be supported by the MMU 28, called “read as X” memory. The page table information used by the MMU 28 associates a given page of the virtual address space with a property read as X, and indicates that a read to that page will return the specified value X. The value of X may be implied from the property read as X itself or from other information defined by the page table information, and thus does not require a cache or memory access to identify the numerical value of X. Thus, in a read request when the MMU 28 identifies from the corresponding page table information for the read target virtual address that the read target block of data sought to be read by the read request falls within a page associated with the property read as X, the MMU 28 does not need to translate the virtual address to a physical address and may suppress any access to the cache 30, 32 or memory 34 that would otherwise be issued to obtain the value of the read data. Note that even if cache / memory accesses may be suppressed to obtain the data value of X, cache / memory accesses may still be required if a page table walk is required to obtain the page table information associated with the read target virtual address. The MMU 28 may generate a specified value X using its internal circuit logic and return this value to the processing circuit 4 as a result of the read operation. The specified value X may be, for example, 0, or a non-zero value such as a value with all bits set to 1, or another binary value expected to be used frequently enough to justify dedicated encoding in the page table information or other information referenced by the page table information. If the specified value X has fewer bits than the size of the read block of data, then the specified value X may be repeated to fill the returned read block of data.

[0056] Thus, unlike the software-implemented copy-on-write mechanism described above (which may be implemented using existing architectural mechanisms for supporting address translation and access control using read / write access permissions), the property read as X is a new architectural property defined in the page table information supported by the MMU 28. Although this may require some additional encoding space in the page table information, it has several advantages over software-implemented copy-on-write mechanisms for filling large regions of memory with a predefined value. First, since there is no cache or physical memory access to obtain the specified value X, this means that no physical memory needs to be committed at all for the region allocated with the specified value X, and therefore no large block of physical memory needs to be consumed to actually store the specified value X, even if a relatively large page / block size is used. This means that the available physical storage implemented within the processing system can be utilized more efficiently, since more storage is available to store other data with more meaningful values ​​other than the specified value X. This reduces the amount of meaningful data that must be exported to external (off-chip) storage, improving performance of code that requires the other data. Also, read requests that target a page having a property read as X can be processed faster because no cache or memory access is needed to obtain the specified value X, thus improving performance.

[0057] When a write request is issued whose page table information specifies an address associated with a property read as X, several different read as X write behaviors are possible. Figure 3 illustrates several options. The first option is to signal a failure when a write request is issued that targets a page with a property read as X. This may be useful to support copy-on-write, as in the case of a first write to a virtual page filled with zeros, where the failure may cause the operating system to allocate some physical memory for that virtual page and then process the write after the virtual page is mapped to that physical memory. Another option is to simply ignore the write operation and not write the data to any physical memory. This may be chosen to reduce the likelihood of a failure if the read as X property is used for purposes other than copy-on-write and a failure is not necessary, but there should be architecturally specified techniques for handling writes to memory read as X (such writes may be expected to be rare when software has specified memory as being read as X). A third option is that the write data of a write request may be transferred to a predetermined system location, such as the trace buffer 42, another processor 46, or a peripheral device 48. The transfer of data to such a system location may be performed using a read or write memory access to a virtual address (not having the property of being read as X) that would otherwise translate to a physical address identified by the memory bus infrastructure as corresponding to that system location. However, in a normal access, such a transfer requires an address translation to the corresponding physical address, and then a memory access request specifying the physical address to be sent to the memory system, such that a mapping component implemented within the memory system can identify, based on the target physical address, the system location that is the destination for the write data.In contrast, by using the read as X property, the fact that the write data should be forwarded to a predetermined system location may be identified by MMU 28 from the page table information (either directly or by using an indirection table referenced by the page table information), and thus the delay of forwarding a memory access request to the memory system and waiting for the mapping component to identify the target location of the data may be reduced because MMU 28 can specify the destination directly without invoking its mapping component. Thus, a read as X write behavior that forwards data to a predetermined system location may provide accelerated access to a system component, such as a trace buffer 42 (used to record diagnostic information about the execution of software on the processing system), another processor 46, or a peripheral device (such as a DMA controller, a network controller, or a hardware accelerator).

[0058] 4 is a flow diagram illustrating the processing of a read request. At step 100, a read request is issued by processing circuitry 4 requesting that a read target value be read from a memory system location associated with a read target block of memory address space. The read request may specify a read target address, which identifies the read target block, and optionally a size parameter.

[0059] In step 102, the MMU 28 performs a lookup of the read target address in the TLB 29 to find page table information for the target page corresponding to the read target block. If the TLB 29 does not already store the requested page table information, a page table walk operation may be performed to traverse the page table structures stored in memory to obtain the requested page table information. If valid page table information is not defined in the page table structure for the requested target page, a fault may be signaled and the method of FIG. 4 may be stopped.

[0060] In step 104, the MMU 28 determines, based on the obtained page table information, whether the read target block corresponds to a page associated with the property to be read as X. If not, in step 106, the MMU 28 determines whether the access permissions specified in the page table information for the target page are met, and if there is a violation of the access permissions, in step 108, a fault is signaled. If the access permissions specified in the page table information are met, in step 110, the MMU 28 performs an address translation based on the address mapping information specified in the page table information to obtain a target physical address corresponding to the virtual address specified as the read target address. In some states of the processing circuit 4, the address mapping from virtual addresses to physical addresses may depend on two stages of page table structures: a stage 1 page table structure that defines the mapping from virtual addresses to intermediate addresses based on mapping information set under the control of an operating system executing on the processing circuit 4, and a stage 2 page table structure that defines the mapping from intermediate addresses to physical addresses based on mapping information set under the control of a hypervisor executing on the processing circuit 4. In other operating states of the processing circuit 4, the translation may be a single-stage direct translation of the virtual address to a physical address. Any known address translation technique may be used to perform the address translation.

[0061] In step 112, the MMU 28 returns the translated physical address to the load / store unit 26 of the processing circuitry 4, which issues a cache access request to request that at least a portion of the read target value be returned from the level 1 cache 30. If the request misses in the level 1 cache, a further request may be sent to the level 2 cache 32 or to the main memory 34. In some cases, for example if the page table information indicates a non-cacheable page, the cache access may be bypassed, in which case the request may target the memory 34 directly. The read target value is obtained from one of the storage structures 30, 32, 34 of the memory system and returned to the processing circuitry 4 to store the value, for example in a register 14, from where it may be used as an operand of a subsequent instruction processed by the processing circuitry 4.

[0062] On the other hand, if, at step 104, it is determined that the read target block corresponds to a page associated with the property being read as X, then, at step 114, the MMU 28 again determines whether any access permissions specified in the page table information are satisfied by the read request, and if not, a fault is signaled at step 116. If the access permissions are determined to be satisfied, then, at step 118, a cache or memory access request (which would normally be issued to request that the read target data be returned to processing circuitry 4) is suppressed, and instead, at step 120, the specified value X is returned to processing circuitry 4 as a value corresponding to at least a portion of the read target block. Again, the returned data value may be stored in registers 14 of the processing circuitry. The specified value X is inferred from the page table information or other information referenced by the page table information, and thus no cache or memory access is required to determine the specified value X.

[0063] In rare cases, a read target block may cross a page boundary between one page marked as having the property to be read as X and another page that does not have the property to be read as X. In this case, the portions of the read access to the pages that are read as X and the pages that are not read as X may effectively be treated as two separate accesses that require separate lookups of page table information in step 102 and trigger separate processing of steps 106-112 for the pages that are not read as X and steps 114-120 for the pages that are read as X, respectively. Thus, in this case, only a portion of the read target value requested by the read request is generated by MMU 28 as the specified value X, and the other portion that corresponds to the pages that are not read as X is retrieved from the memory system in step 112. Thus, it is not mandatory to return the entire read target value of the read request as the specified value X, because the read request may only partially target the pages that are read as X.

[0064] 5 is a flow diagram illustrating the processing of a write request. In step 140, a write request is issued by processing circuitry 4 requesting the writing of a write value to a memory system location associated with a write target block of the memory address space. For a read request, in step 142, MMU 28 looks up the write target address specified by the write request in TLB 29 to find page table information for a target page corresponding to the write target block of the address. Again, if TLB 29 does not already have the necessary information, a page table walk may be performed to access a page table structure in memory. In step 144, MMU 28 determines based on the obtained page table information whether the write target block of the address corresponds to a page associated with the property read as X.

[0065] If the target page associated with the write target block is not the page to be read as X, then in step 146 the access permissions specified by the corresponding page table information are checked and if an access violation is identified a fault is signaled in step 148. If the access permissions specified for the page targeted by the write request are satisfied, then in step 150 the MMU 28 performs address translation similar to step 110 of Figure 4 to obtain the target physical address for the write access. In step 152 a cache or memory access request is issued by load / store unit 26 to request the writing of the write value specified by the write request to a memory system location (in cache 30, 32 or memory 34) associated with the target physical address.

[0066] If, in step 144, it is determined that the write target block corresponds to a page associated with the property read as X, then, in step 154, MMU 28 again checks any access permissions that need to be satisfied for access to the target page, and if any access permissions are not satisfied, in step 156 a fault is signaled.

[0067] If it is determined that for a write access to the page read as X, some other access permissions necessary for the write to be permitted are satisfied, there are several options for servicing the write request to the page read as X of the address space. In the first option, a fault is signaled in step 158. In the second option, in 160, the write request is simply ignored without issuing a write request to cache or memory, but no fault is signaled, and thus processing is allowed to continue uninterrupted by the processing circuitry 4. In the third option, in step 162, the write value specified by the write request is forwarded to a predetermined system location, such as the trace buffer 42, other processors 46, or peripherals 48. Some implementations may support only one of the options shown in steps 158, 160, and 162. Other implementations may support two or more of these options, and which option is taken for a particular write request may depend on software-programmable control information (e.g., the ability to program this control information may be restricted to software above a certain privilege level, such as operating system or hypervisor software). For example, the control information may be the page table information itself, which may directly specify which read-as-X write behavior should occur in response to a write request to a page read as X, or the control information may be an indirect table referenced by the page table information that provides more information on how to handle a write request to a page read as X. Alternatively, the control information that controls which read-as-X write behavior should be used may be independent of the page table information and may not be referenced directly or indirectly by the page table information (e.g., the control information may be global information used to control the read-as-X write behavior of all pages, rather than page-specific information specific to individual pages).For example, a control register may indicate a mode status value read as X that indicates the write behavior to be used in the current operating mode, which may apply globally to any page in the address space associated with the property read as X.

[0068] Page table information can encode the read-as-X property in a number of different ways. In some cases, a page table entry for a given page of an address space can directly specify a memory attribute or permission type value that identifies the page as having the read-as-X property. For example, one or more bit field encodings of a permission or attribute field of a page table entry may be assigned to indicate the read-as-X property, with other encodings of that field identifying other types of permissions or attributes.

[0069] Alternatively, an indirection table can be used to define information about the read as X property, as shown in Figure 6. This can be useful when the page table format does not have enough spare coding space to add support for a desired number of variants of the read as X property. This can be particularly useful when there are two or more variants of the read as X property that are desired to be supported, such as variants of read as X that correspond to different values ​​of a specified value X or different read as X write behaviors, as described above.

[0070] As shown in Figure 6, a page table structure 200 may associate a virtual address with a translated address (which in this example is a physical address, although in a stage 1 translation of a two-stage translation process, the translated address may instead be an intermediate address), and one or more access permission or attribute fields. Although the virtual address is explicitly shown in the table structure of Figure 6 for ease of explanation, it will be understood that in practice the virtual address may be used to index the structure and thus need not be explicitly stored in the table structure itself.

[0071] In this embodiment, the permission field references a set of permission indirect registers 202 implemented as control registers of the MMU 28. The permission indirect registers are programmable by software instructions executing at or above a certain privilege level, and represent an indirection table that selects from a variety of supported permission types. By using the permission indirect registers, a larger number of permission types can be supported than can be indicated by a limited number of bits in the permission field of the page table entry itself. For example, a bit permission field may select from one of four permission indirect entries in the permission indirect registers 202, but each entry of the permission indirect registers 202 may select from five or more different options for the corresponding permission type. Of course, the number of permission indirect entries may be greater or less than four.

[0072] This can allow support for a range of different permission types for a given page, such as: · Read only: Read access is permitted, write or instruction fetch access is prohibited. · No Access: All access to the page is forbidden. Read / Execute Access: Read and instruction fetch access is permitted, write access is prohibited. Read as 0: A variant of the property where the specified value is read as X, which is 0 (e.g., this variant may use a write-fault write behavior, as shown in step 158 of FIG. 5). · Read / Write: Read and write access is permitted, instruction fetch access is prohibited. · Read as 0 write ignore: A variation of read as 0 where the write ignore operation of step 160 of FIG. 5 is used when a write is requested to a page that is read as X. Write to trace buffer read as 0: A variation of read as 0 where the read as X write behavior used is option 3 of FIG. 5 and the predetermined system location is the trace buffer 42. Read as X dependent on address: A variation of the read as X property where the value of X depends on the address of the read request, as further described in FIG. 8 below.

[0073] It will be appreciated that these are only some example encodings that may be possible, and that many other permission types may also be used. In general, software may select the value to write to the permission indirect register to select a particular subset of the available permission types supported in the ISA for selection by the page table entry, reducing the number of bits required in the page table entry itself to less than the number of bits required to encode a selection from the full range of supported permission types. Although FIG. 6 illustrates the indirect register 202 as specifying the options available for selection of the permission field of a page table entry, other implementations may apply the indirection table approach to an attribute field. The property read as X may be considered a memory attribute rather than a permission, and thus may be encoded directly or indirectly in the attribute field instead of the permission field, as shown in the embodiment of FIG. 6.

[0074] 7 illustrates the use of a further indirection to specify a particular value X to be returned for a read to a page of memory that is read as X. Again, the page table structure 200 defines which permission type should be selected for a given page using an indirection table 202 specified in a control register of the MMU 28, and the page table entry specifies in its permission field an entry identifier that specifies one of the entries of the indirection table 202. For at least some encodings of the indirection table entries, the value of the indirection table entry may be interpreted as a further reference to an entry of a further indirection table 204 stored in a control register. This may be useful to support a wider range of possible values ​​for the specified value X of a page read as X, where the initial indirection table may specify whether the page is a page read as X or a page that cannot be read as X, and may specify other properties of the page read as X properties such as the write behavior of the page read as X or the type of system component that is transferred along with the write data of the page read as X, but for at least some encodings specified as indicating a page of memory read as X, the encoding may be interpreted as a reference to a further indirection table 204 where the referenced entry specifies a particular value to be returned in four reads to the page of memory read as X. This approach allows a wide range of numerical values ​​to be specified for read as X accesses without requiring the permission field in the main page table to be expanded to a sufficient number of bits to indicate the specified value. This is beneficial because the indirection table 202 and further indirection table 204 may be specified once globally for all pages, whereas the page table entry 200 is provided per page, and therefore extending the size of the permission or attribute field of the page table structure to specify any data value as a specified value X that is returned for a page that is read as X would significantly increase the size of the page table structure.

[0075] While FIG. 7 illustrates an approach that uses a further indirection table 204 to specify a selection from several different values ​​for a specified value X, in other approaches the selection of a particular value of X may be combined with other information in the indirection table 202 such that a further indirection table 204 is not required.

[0076] FIG. 8 illustrates in more detail an example behavior for the "read as address dependent value X" variant of the property read as X shown in FIG. 6. In this case, for two pages that have identical encodings of the property read as X, but that are in different ranges of the address space, different values ​​of the specified value X may be returned for read accesses to those pages. For example, one or more bits of the read target address (e.g., the most significant part of the address, excluding the high-order bits that are not used to select the memory access location in memory) may be used to select which value should be returned as the specified value X. This may be useful because some instruction set architectures use different ranges of the address space for different purposes, such as using addresses in the lower part of the address space (high-order bits equal to 0) for user data and user program code, and addresses in the upper part of the address space (high-order bits equal to 1) for kernel (operating system) data and kernel program code. In some use cases, it may be desirable that the default value returned as the specified value X for accesses to memory read as X should be different for user-level accesses and kernel-level accesses. For example, as described further with respect to Figure 9 below, if a read as X approach is used to handle allocation tags in a system that supports memory tagging, it may be useful to assign different tag values ​​to read as X pages used by user accesses and kernel accesses respectively, such that user accesses to kernel data would result in a tag mismatch. By providing an address-dependent variation of the read as X property, this avoids the need for two separate permission / attribute type encodings to be allocated for different values ​​of X to be used in different ranges of the address space, saving encoding space in the page table information or indirection table that can free up at least one other encoding of the page table entry or indirection table entry for other purposes.Although FIG. 8 shows an example where the address space is split in two, and thus two different ranges of addresses corresponding to different values ​​of the specified value X, it will be appreciated that other approaches can use more than two bits of the target address to select which value to use for the specified value X, in which case the address space can be effectively split into more than two regions corresponding to different values ​​of X for the page to be read as X.

[0077] Also, it is not necessary to use the most significant bit of the address to select the value of X. In embodiments that use one or more bits in lower bit positions of the address to select the value of X, this has the effect of several alternating regions of address space alternating in the value of X, which may be useful, for example, to rotate allocation tag values ​​to reduce the amount of physical storage and explicit tag write operations required to set the allocation tag values ​​for a given range of memory to alternating values ​​for each block.

[0078] The property read as X may be particularly useful for systems that support memory tagging, to allow allocation tags with certain tag values ​​to be represented without having to commit physical memory to store those tags. FIG. 9 illustrates the concept of memory tagging, which may be used to address the problem that some high-level programming languages, such as C and C++, are considered memory unsafe in that they do not include run-time error detection checks to check for certain errors related to memory accesses. The persistent prevalence of use of memory-unsafe languages ​​means that in code compiled according to a given instruction set architecture, there may be a large number of memory-related errors that may be vulnerable to exploitation by attackers or other malicious actors. Such errors may include: An index of an array supplied by the code is outside the legal bounds of the array, a bounds violation; Use-after-free errors, where a memory location is accessed after it has already been deallocated or freed, A memory access to an address associated with a variable used within a function (such as a value on the stack) occurs after the function has already returned; use after the return; Out-of-scope errors, where a variable is accessed outside the scope in which it is declared, A use-before-initialization error, where the memory address associated with a variable is accessed before the variable is initialized.

[0079] These are just a few examples of memory-related errors that can cause unpredictable behavior and potentially provide avenues for attackers to exploit. Thus, it may be desirable to provide architectural support within the instruction set architecture supported by a given processing device to aid in the run-time detection of certain classes of memory errors.

[0080] One approach to protect against certain memory usage errors of the type described above may be to provide allocation tags stored in the memory system in association with one or more blocks of memory locations. When a tag-protected memory access operation is requested based on a target address that identifies a particular addressed location in the memory system, a tag check circuit may compare an address tag associated with the target address with an allocation tag stored in the memory system in association with the block of one or more memory locations that includes the addressed location identified by the target address. The tag check circuit may generate an indication of whether a match is found between the allocation tag and the address tag. This indication may be used to control whether the memory access is allowed to succeed, or whether a subsequent operation can succeed, or may simply be reported while allowing the memory access to continue normally.

[0081] This may be useful, for example, because a compiler compiling code based on a memory-unsafe language such as C or C++ may generate instructions that, when initializing regions of memory, can set allocation tags of blocks of memory that the code expects to access to particular values ​​and associate matching address tag values ​​with pointers used to provide target addresses pointing to those blocks. If a memory usage error occurs, for example if an address pointer is used out of scope or extends outside the bounds of an initialized scope, the allocation tag associated with the addressed location may not match the address tag associated with the target address, and an indication of whether a match was found may be used to trigger some error handling response or error reporting mechanism. The particular response taken may depend on the particular needs of the software being executed, or the particular micro-architectural implementation of the architecture. Thus, even if a high-level language does not have a means to implement run-time error checks to protect against memory access errors, the ISA used for the compiled code may include architectural features to implement such checks.

[0082] Thus, as shown in FIG. 9, when tag checking mode is supported, a physical address space 244 used to reference memory locations in the memory system can be logically divided into several blocks 245, each containing a certain number of addressable locations 246. For simplicity, in the example of FIG. 9, each block 245 contains four memory locations 246, although other block sizes may be used as well. Each block 245 is associated with a corresponding allocation tag 240. The allocation tags associated with a certain number of blocks 245 may be collected together and stored either in different architecturally accessible memory locations in the physical address space, or in additional storage locations provided in the memory system that are not architecturally accessible (not mapped to the same physical address space). The specific mapping of which tag storage locations correspond to each block 245 may be hardwired or programmable.

[0083] Thus, when a tag-protected memory access is required (e.g., certain memory access instruction opcodes can be assigned to indicate tag-protected memory accesses, or any memory access issued when operating in tag-checking mode can be considered tag-protected), the address tag 246 (associated with the target address 247 that identifies the addressed location to be accessed) is compared to the allocation tag 240 associated with the block of memory locations 245 that contains the addressed location. For example, in FIG. 9, the target address 247 points to a certain location B1 in memory. Thus, the allocation tag B associated with the block of locations B that contains location B1 is compared by tag check circuitry 250 to the address tag 246 associated with the target address 247. As shown in FIG. 1, the tag check circuitry 250 can be considered part of the processing circuitry 4, or the tag check circuitry 250 can be implemented as part of the memory system (not shown in FIG. 1). As shown at the top of FIG. 9, the address tag 246 can be determined as a function of selected bits of the target address 247 itself. In particular, the address tag may be determined from bits in a portion of the target address that are not used to indicate the particular memory location to be selected as the addressed location 44 (the selection of the target location B1 does not depend on these bits). For example, in some architectures, the upper portion of the bits of the target address may always have a certain fixed value, such as sign extension (all 0's or all 1's), and thus are meaningless, and these upper bits are not used to select the memory location to access. Thus, an address may be tagged with an address tag 246 by overwriting these unused bits with an arbitrary tag value. The particular address tag value may be selected, for example, by the programmer or the compiler.The address tag 246 and allocation tag 240 can be a relatively small number of bits, for example 4 bits, and therefore do not need to occupy much space in memory storage and in the target address. A tag space of 4 bits, i.e., providing 16 possible values ​​for the tag, can often be sufficient to detect many common types of memory access errors.

[0084] Thus, when a tag-protected memory access is performed, the tag check circuit 250 compares the address tag 246 associated with the target address to the allocation tag 240 associated with the block of memory locations 245 that contains the addressed location B1 to determine whether they match. The tag check circuit 250 generates a match indication indicating whether the address tag 246 and the allocation tag 240 match. For example, this match indication may be a fault signal that is generated if there is a mismatch between the address tag 246 and the allocation tag 250 and triggers an exception handler to address the cause of the fault. The match indication may also be an indication placed in a status register indicating whether there was a match, or an entry added to an error report to indicate the address where the error was detected and / or the instruction address of the instruction that triggered the error. While some implementations may prevent a memory access that causes a tag check error from succeeding, other approaches may allow the memory access to proceed despite the tag check error, but record the error in an error log, which may be made available to the software provider of the code to assist the provider in eliminating the error in subsequent versions of the software. It will therefore be appreciated that there are a variety of ways in which a tag match / mismatch indication may be generated by tag checking circuitry 250.

[0085] It should be noted that in embodiments where a portion of the target address 247 is used to determine the address tag 246, this address tag is different from the tag portion of the target address that the cache 30, 32 may use to determine whether information from the addressed location identified by the target address is stored in the cache. Many cache schemes may store the tag portion of the address of the cached data in parallel with the data in the cache, such that when the cache is searched for a given address, a portion of the address may be compared to the tag stored in parallel with the cached data to determine whether the cached data actually corresponds to the requested address. However, in this case, the tag portion of the address that is compared to the tag in the cache is the portion of the address that actually identifies the particular addressed location for which data is requested, i.e., changing the cache tag portion of the address will of course result in the address pointing to a different addressed location in the memory system. In contrast, when address tags are used for tag-protected memory operations, the memory access circuitry may select the addressed location for which data access is requested independently of the address tag. That is, even if address tag 246 has a different value, the addressed location B1 referenced by the target address may still be the same, since the selection of addressed location B1 depends only on other portions of target address 247, and is independent of the portions used for address tag 246. This gives the compiler the freedom to set the address tag associated with a particular address to any value to match the corresponding allocation tag value assigned to the associated block of data in the memory system.

[0086] The tag checking circuitry 250 may be located in different parts of the system 2. In some instances, the tag checking circuitry may be located within a processing element (e.g., a CPU) as shown in Figure 1. Other embodiments may locate the tag checking circuitry closer to the memory storage 16 that stores the accessed data and tags.

[0087] In systems that support memory tagging, to define an allocation tag 240 for a range of address space that is desired to be protected using memory tagging, this may require a relatively large amount of physical memory storage to be committed for storage of the allocation tag (in the absence of support for the read-as-X property). However, it is recognized that in practice a reasonable portion of the allocation tags may be set to a specified value, such as 0, and thus this may waste a relatively large portion of the available physical storage. By using the read-as-X property for pages allocated to store allocation tags with a specified value X, this reduces the amount of physical memory that must be committed to store the tag values, and therefore uses the available physical storage more efficiently. Thus, when a tag-protected access is requested, the address of the corresponding allocation tag may be derived by the MMU 28 from the target address of the data being read / written according to a mapping scheme implemented by the MMU 28 (e.g., either a hardwired mapping of data location addresses to tag location addresses or a programmable mapping based on a software programmable tag mapping table), and if the address required for the tag access is determined as a mapping to a page read as X based on page table information, the MMU 28 may generate the specified value X without accessing the cache 30, 32 or memory 34 and return the specified value X of the requested allocation tag to the tag check circuit 250, which may compare the specified value X with the address tag 246 of the corresponding address to determine whether a tag check error has occurred. The read as X property is not limited to use for tag accesses, as it may also arise for data accesses.

[0088] To support memory tagging, it may be useful to provide a variant of the read as X property where the property indicates that a read access should partially return the value read from the cache 30, 32 or memory 34, and for other parts return an implicitly defined specified value X implied from the read as X property, such as 0. This may be useful to allow an allocation tag for a region of memory to be returned along with the corresponding data in a read access, without the allocation tag itself having to be stored in physical memory when the allocation tag has a value X associated with the read as X property. Thus, reading as X may allow X to replace several bits in a single (possibly cache line sized) read access. For example, a cache line may (nominally) be thought of as storing multiple data bytes and a single MTE-like "tag" byte, but the tag byte may not need to be physically stored if it can be implied using the read as X property. For example, a physical memory corresponding to a 4KB page with a property read as X may physically store 256 sets of 128-bit data values, but the corresponding virtual page can actually be thought of as mapping to 256 sets of 132-bit values, each 132-bit value containing 128 bits of normally accessed data and a 4-bit tag returned as X, whose value is implicitly determined based on the property read as X. Thus, a cache line sized read to an address within that page will return not only the 128 bits of physically stored data, but also a 132-bit value that includes the tag. This makes it possible to define tags for regions of virtual memory without committing any physical storage.

[0089] Several variations of the property read as X are described above, and it will be understood that any particular system implementation may support any one or more of these variations.

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

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

[0092] Simulator program 310 may be stored on a computer-readable storage medium (which may be a non-transitory medium) and provides a program interface (an instruction execution environment) to target code 300 (which may include applications, an operating system, and a hypervisor) that is the same as the interface of the hardware architecture being modeled by simulator program 310. Thus, program instructions of target code 300 may be executed from within the instruction execution environment using simulator program 310, such that a host computer 330 that does not actually have the hardware features of device 2 described above (e.g., memory management circuitry 28 that supports the use of the property read as X as described above) may emulate these features.

[0093] Thus, the simulator program 310 may have instruction decode program logic 312 for decoding instructions of the target code 300 and mapping them to corresponding instructions in the native instruction set of the host device 330. The register emulate program logic 314 maps register accesses requested by the target code to accesses to corresponding data structures maintained on the host hardware of the host device 330, such as by accessing data in registers or memory of the host device 330. The memory manager program logic 316 implements address translation, page table walks, and access permission checks to simulate accesses to the simulated address space by the target code 300 in a manner corresponding to the MMU 28 as described in the hardware implementation embodiment above. The memory address space simulate program logic 318 is provided for mapping simulated physical addresses obtained by the memory manager program logic 316 based on address translation using page table information maintained by the software of the target program code 300 to host virtual addresses used to access the host memory of the host processor 330. These host virtual addresses can themselves be translated to host physical addresses using standard address translation mechanisms supported by the host (the translation of host virtual addresses to host physical addresses is outside the scope of control by simulator program 310).

[0094] If the memory manager program logic 316 identifies that for a read access by the target program code 300 to a given read target block of the simulated address space, the given read target block corresponds to a page identified as having the property of being read as X using the page table information set by the target program code 300 (not the page table information used by the host for host address translation), the memory manager program logic 316 controls to return the specified value X to the target program code 300 without having to translate the simulated virtual address of the read target block to a simulated physical address or to invoke the memory address space simulator program logic 318 to map the simulated physical address to the host storage of the host processor 330. Instead, the value X may be generated by the program code of the simulator program 310 itself based on the identification of the property of being read as X and made available for subsequent processing by the target program code 300. This emulates the behavior that the target program code 300 would be expected to observe if it were executed on the hardware device 2 of FIG. 1.

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

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

Claims

1. 1. An apparatus comprising: processing circuitry for performing data processing in response to instructions; a memory management circuit for controlling access to memory based on page table information capable of associating a given page of a memory address space with a property, read as X, that indicates that a read to an address within the given page of the memory address space should be treated as returning a specified value X; Equipped with and in response to a read request issued by the processing circuit to read a read target value for a read target block of the memory address space and determining that at least a portion of the read target block corresponds to a page associated with the property read as X, the memory management circuit is configured to control the memory management circuit to return the specified value X to the processing circuit as at least a portion of the read target value.

2. 2. The apparatus of claim 1, wherein, in response to determining that, for at least one variant of the property read as X, all of the read target blocks correspond to pages associated with the property read as X, the memory management circuitry is configured to inhibit issuance of a cache access request or a memory access request to read the read target value from a cache or the memory.

3. 3. The apparatus of claim 1, further comprising a tag check circuit for performing a tag check operation to determine whether an address tag associated with a target address of a memory access request corresponds to an allocation tag associated with a memory system location corresponding to the target address, and for triggering a tag error handling response in response to the tag check operation detecting a mismatch between the address tag and the allocation tag.

4. In response to the memory management circuit determining, for a tag read request to obtain a given allocation tag checked in the tag checking operation, that a page corresponding to the given allocation tag is associated with the property read as X, the memory management circuit is configured to control the memory management circuit to return the specified value X as the given allocation tag; 4. The apparatus of claim 3, wherein the tag check circuitry is configured to perform the tag check operation using the specified value X for the given allocation tag.

5. The property read as X is a page of the memory address space used to store data; and a page of said memory address space used to store allocation tags 4. The apparatus according to claim 3, wherein the control signal is capable of being specified for both the first and second inputs.

6. 3. The apparatus of claim 1, wherein, in response to determining that, for at least one variant of the property read as X, the read target block corresponds to a page associated with the property read as X, the memory management circuitry is configured to control the specified value X to be returned to the processing circuitry as part of the read target value, and to enable a cache access request or a memory access request to be issued to read another portion of the read target value from a cache or the memory.

7. 3. The apparatus of claim 1, wherein for at least one variant of the property read as X, the specified value X is 0.

8. 3. The apparatus of claim 1, wherein for at least one variant of a property read as X, the specified value X is a value with all bits set to 1.

9. 3. The apparatus of claim 1, wherein the memory management circuitry is configured to support multiple variations of a property read as X corresponding to different values ​​for the specified value X.

10. 3. The apparatus of claim 1, wherein the memory management circuitry is configured to support address-dependent variation of the property read as X, such that for the address-dependent variation, when a given page is associated with the address-dependent variation of the property read as X, the specified value X depends on the address of the given page, such that the memory management circuitry can select different values ​​when returning the specified value X as the read target value for different pages of the memory address space associated with the same encoding of the property read as X.

11. for a write request issued by the processing circuitry to write a write value to a write target block of a memory address space, in response to determining that at least a portion of the write target block corresponds to a page associated with the property read as X, the memory management circuitry is configured to process the write request in accordance with a write behavior read as X; The write behavior read as X is triggering a fault signaling; ignoring the write request; and forwarding at least a portion of said written values ​​to a predetermined system location.

3. The device according to claim 1, further comprising one of:

12. the predetermined system location: a trace buffer for storing diagnostic trace information; a processor other than the processor that includes the processing circuit; and Peripheral devices 12. The apparatus of claim 11, comprising one of:

13. 12. The apparatus of claim 11, wherein the memory management circuitry is configured to support multiple variants of the read-as-X property corresponding to different read-as-X write behaviors.

14. 3. The apparatus of claim 1, wherein the memory management circuitry is configured to determine that the given page has the read-as-X property when a field of a page table entry corresponding to the given page has an encoding indicating the read-as-X property.

15. 3. The apparatus of claim 1, wherein the memory management circuitry is configured to determine that the given page has the property to be read as X when a page table entry corresponding to the given page specifies an indirection table entry select value that indicates a selected entry of an indirection table, and the selected entry of the indirection table has an encoding that identifies the property to be read as X.

16. 16. The apparatus of claim 15, wherein the memory management circuitry is configured to support at least two different encodings for the selected entry of the indirection table corresponding to different variations of a property read as X.

17. 17. The apparatus of claim 16, wherein the memory management circuitry is configured to determine the specified value X for the given page based on an encoding of a further entry in a further indirection table, the further entry being indicated by an encoding of the selected entry in the indirection table.

18. a given page table entry corresponding to a given page of said memory address space specifies an address mapping field; when the given page is not associated with the property read as X, the memory management circuitry is configured to use the address mapping field of the given page table entry to perform address translation; 3. The apparatus of claim 1, wherein the memory management circuitry is configured to use the address mapping field of the given page table entry for purposes other than address translation when the given page is associated with the property read as X.

19. 20. The apparatus of claim 18, wherein the memory management circuitry is configured to use the address mapping field to indicate the specified value X when the given page is associated with a property read as X.

20. 1. A method comprising: performing data processing by the processing circuitry in response to the instructions; controlling access to the memory based on page table information capable of associating, by the memory management circuitry, a given page of a memory address space with a property, read as X, indicating that a read to an address within said given page of said memory address space should be treated as returning a specified value X; Including, and, in response to a read request issued by the processing circuit to read a read target value for a read target block of the memory address space, determining that at least a portion of the read target block corresponds to a page associated with the property read as X, returning the specified value X to the processing circuit as at least a portion of the read target value.

21. 1. A computer program for causing a host data processing apparatus to perform operations to provide an instruction execution environment for executing target code, the computer program comprising: instruction decoding program logic for decoding instructions of the target code in response to the instructions of the target code to control the host data processing apparatus to perform data processing; memory management program logic for controlling access to the simulated memory address space based on page table information capable of associating a given page of the simulated memory address space with a property, read as X, that indicates that a read to an address within the given page of the simulated memory address space should be treated as returning a specified value X; Equipped with the computer program product being configured to, in response to a read request to read a read target value for a read target block of the simulated memory address space and determining that at least a portion of the read target block corresponds to a page associated with the property read as X, control the memory manager program logic to return the specified value X as at least a portion of the read target value.

22. A storage medium storing the computer program according to claim 21.

Images