Apparatus, method, and computer program for performing translation table entry load / store operations

Abstract

The translation table entry load / store operation is performed on at least one target translation table entry address selected depending on software-defined address information identifying a selected address in the input address space. Each target translation table entry address includes an address of a leaf translation table entry that provides address mapping information for translating the selected address from the input address space to the output address space, or an address of a branch translation table entry that is traversed in a translation table walk operation to obtain the leaf translation table entry. At least one variant of the translation table entry load / store operation supports, for a given target translation table entry of the at least one target translation table entry, clearing access tracking metadata of the given target translation table entry from a first state (indicating that at least one load / store access has occurred to the corresponding region of the input address space) to a second state (indicating that no load / store access has occurred to the corresponding region).

Description

[Technical Field]

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

[0002] The processing system may perform address translation to translate between input and output address spaces based on address mapping information obtained from a translation table structure containing translation table entries. Supporting address translation allows different software written with conflicting definitions of input address spaces to be mapped to a common output address space to resolve address conflicts between the software. The translation table structure may also specify access permissions or memory region attributes used to control access to memory in the corresponding region of the address space.

[0003] At least some examples include an apparatus including: a processing circuit for processing instructions; an address translation circuit for translating between an input address space and an output address space based on address mapping information obtained from a translation table structure including translation table entries; and, in response to a translation table entry load / store trigger instruction processed by the processing circuit, at least one target translation table entry address selected depending on software-defined address information identifying a selected address in the input address space, wherein each target translation table entry address is the address of a leaf translation table entry that provides address mapping information for translating the selected address from the input address space to the output address space, or a translation table word for retrieving the leaf translation table entry that provides address mapping information for translating the selected address. and a translation table entry load / store circuit for performing a translation table entry load / store operation for a target translation table entry address including an address of a branch translation table entry traversed in the branch operation, wherein for at least one variant of the translation table entry load / store operation, the translation table entry load / store operation supports, for a given target translation table entry of the at least one target translation table entry, clearing access tracking metadata of the given target translation table entry from a first state to a second state, where the first state indicates that at least one load / store access has occurred to a corresponding region of an input address space, and the second state indicates that no load / store access has occurred to the corresponding region of the input address space.

[0004] At least some examples include a method including: processing an instruction using a processing circuit; and translating between an input address space and an output address space based on address mapping information obtained from a translation table structure including translation table entries using an address translation circuit; and, in response to the processing circuit processing the translation table entry load / store trigger instruction, obtaining at least one target translation table entry address selected depending on software-defined address information identifying a selected address in the input address space, wherein each target translation table entry address is the address of a leaf translation table entry that provides address mapping information for translating the selected address from the input address space to the output address space, or a leaf translation table entry that provides address mapping information for translating the selected address. and performing a translation table entry load / store operation for a target translation table entry address, the target translation table entry address including an address of a branch translation table entry traversed in a translation table walk operation to locate a target translation table entry address, wherein for at least one variant of the translation table entry load / store operation, the translation table entry load / store operation supports, for a given target translation table entry of the at least one target translation table entry, clearing access tracking metadata of the given target translation table entry from a first state to a second state, wherein the first state indicates that at least one load / store access has occurred to a corresponding region of an input address space, and the second state indicates that no load / store access has occurred to the corresponding region of the input address space.

[0005] At least some examples include a computer program including instructions for controlling a host data processing apparatus to provide an instruction execution environment for executing target code, the computer program including: address translation program logic for translating between an input address space and an output address space based on address mapping information obtained from a translation table structure including translation table entries; and, in response to a translation table entry load / store trigger instruction of the target code, at least one target translation table entry address selected depending on software-defined address information identifying a selected address in the input address space, wherein each target translation table entry address is the address of a leaf translation table entry that provides address mapping information for translating the selected address from the input address space to the output address space, or and translation table entry load / store program logic for performing a translation table entry load / store operation for a target translation table entry address including an address of a branch translation table entry traversed in a translation table walk operation to obtain a target translation table entry, wherein for at least one variant of the translation table entry load / store operation, the translation table entry load / store operation supports, for a given target translation table entry of the at least one target translation table entry, clearing access tracking metadata of the given target translation table entry from a first state to a second state, where the first state indicates that at least one load / store access has occurred to a corresponding region of an input address space, and the second state indicates that no load / store access has occurred to the corresponding region of the input address space.

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

[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. [Figure 2] 1 illustrates an example of an execution state of a processing circuit. [Figure 3] Illustrates two-stage address translation. [Figure 4] 1 illustrates an example of a translation table walk for stage 1 and stage 2 address translation, respectively. [Figure 5] 1 illustrates an example of a translation table walk for stage 1 and stage 2 address translation, respectively. [Figure 6] 1 illustrates an example of a branch translation table entry and a leaf translation table entry. [Figure 7] An example of a load and store instruction is illustrated. [Figure 8] An example of a translation table entry load instruction and a translation table entry store instruction are illustrated, both of which are examples of translation table entry load / store trigger instructions. [Figure 9] Illustrates how to process commands. [Figure 10] 1 illustrates a method for performing a translation table entry load / store operation in response to a translation table entry load / store trigger instruction. [Figure 11] 1 shows an example of a translation table entry load / store circuit. [Figure 12] 1 illustrates an example of a programming interface for a translation table entry load / store circuit. [Figure 13] 1 illustrates a method for controlling asynchronous processing of translation table entry load / store operations based on parameters defined in a programming interface. [Figure 14] Illustrate the implementation of the simulator.

[0008] The device has processing circuitry for processing instructions and address translation circuitry that translates between an input address space and an output address space based on address mapping information obtained from a translation table structure that includes the translation table entries. In a typical instruction set architecture, for software to modify information in a translation table entry of such a translation table structure, the software would use general load / store instructions and arithmetic instructions to read the current value of each entry to be modified, determine what the modified value of each entry should be, and write each modified translation table entry back to memory. The load / store instructions used for such updates to the translation table structure would typically be general load / store instructions that specify the address of the memory location to be read / written in the load / store operation as the target address of the load / store. Thus, when using such load / store instructions to implement a translation table entry update, this would require software to identify the address of each translation table entry to be updated before performing the load / store to that address. In software, identifying the address of the location that stores a given translation table entry is often not trivial because it may require a software walk of multi-level translation table structures, which may require the software to perform a relatively long sequence of dependent memory accesses for each translation table entry to be updated just to identify the address of the translation table entry to be updated. This can be slow and can impair performance, especially when many translation table entries all need to be updated. One example scenario in which this is problematic is during the live migration of a virtual machine from one host processor to another, when a large portion of the translation table entries associated with the migrated virtual machine may need to be updated during the migration.

[0009] In an example discussed below, the translation table entry load / store circuit, in response to a translation table entry load / store trigger instruction processed by the processing circuit, performs a translation table entry load / store operation for at least one target translation table entry address selected depending on software-defined address information identifying a selected address in an input address space, wherein each target translation table entry address includes the address of a leaf translation table entry that provides address mapping information for translating the selected address from the input address space to the output address space, or the address of a branch translation table entry that is traversed in a translation table walk operation to obtain the leaf translation table entry that provides the address mapping information for translating the selected address.

[0010] Thus, an instruction that triggers a load / store operation on a target translation table entry address does not itself need to specify the address of the target translation table entry. Instead, the translation table entry load / store circuit can identify the target translation table entry to be updated using software-defined address information that identifies the selected address. Rather than triggering a load / store to the selected address itself, the translation table entry load / store circuit performs a load / store operation on the address of at least one target translation table entry corresponding to the selected address. The at least one target translation table entry may include a leaf target translation table entry that provides address mapping information for translating the selected address and / or at least one branch translation table entry that provides a pointer used in a translation table walk to locate the leaf translation table entry. The operation of identifying the target translation table entry address based on the selected address can be implemented in hardware rather than requiring an explicit set of instructions to be implemented in software to walk the translation table entry structure to find the address of the entry to be updated. This can improve performance of updates to the translation table structure.

[0011] For at least one variant of the translation table entry load / store operation, the translation table entry load / store operation supports, for a given target translation table entry among the at least one target translation table entry, clearing access tracking metadata of the given target translation table entry from a first state to a second state, where the first state indicates that at least one load / store access has occurred to the corresponding region of the input address space, and the second state indicates that no load / store access has occurred to the corresponding region of the input address space. One or more items of access tracking metadata may be specified in a given translation table entry, and each item of access tracking metadata may be for combined tracking of load / store accesses (e.g., simply tracking whether an access to a region has occurred, regardless of whether it is a load or a store) or may be specific to tracking either load accesses or store accesses (e.g., tracking store accesses may be particularly useful for identifying which regions of the address space may be “clean” (unwritten), and thus may not need to be written back to another storage device if data for that address space region is evicted from a memory device currently storing it). Thus, there may be one or more access tracking metadata that may be recorded in a translation table structure to allow software to track access patterns in the way the memory address space is being accessed, on a region-by-region basis.

[0012] Typically, it is software's responsibility to determine when to clear the access tracking metadata to an initial state indicating that no load / store accesses have occurred to the corresponding region of the input address space (e.g., this may be done at the beginning of a period for which access frequency or dirty state tracking information is to be collected for a particular group of memory regions). In a typical instruction set architecture, this requires a general load / store instruction of the type discussed above. However, when clearing the access tracking metadata, many translation table entries may need to have their access tracking metadata cleared. Thus, simply clearing the access tracking metadata for a monitored region of the address space to a first state may incur a significant performance cost, as each entry to be updated may require a software-managed walk of the translation table structure simply to identify the address at which the corresponding translation table entry is stored.

[0013] Thus, in at least one variant, by supporting translation table entry load / store operations that support clearing of access tracking metadata using instructions that do not need to specify the address of the translation table entry itself, but can use software-defined address information that specifies a selected address whose entry is used to translate the selected address itself or to provide a pointer on the path to a leaf translation table entry that translates the selected address, this can improve performance of various software use cases.

[0014] In response to a translation table entry load / store trigger instruction, the translation table entry load / store circuit may control the address translation circuit to identify at least one target translation table entry address based on a selected address. For example, the address translation circuit may include a translation table walking circuit that, in response to a given address, triggers a series of memory accesses needed to walk a translation table structure to identify addresses of translation table entries for translating the given address. The address translation circuit may also include at least one address translation cache that caches information derived from previous translation table walks performed by the translation table walking circuit. The cached information in the address translation cache may include information identifying mappings between input memory addresses for a translation table walk and translation table entry addresses of corresponding translation table entries used to translate those input memory addresses. Thus, the address translation circuit may typically already have hardware for identifying addresses of target translation table entries associated with managing the translation of a given address in an input address space. That hardware may be efficiently reused for translation table entry load / store operations, avoiding the need for software to trigger a translation table walk through a software-specified, dependent series of memory accesses. Hardware is typically much faster than software for performing translation table walks, and in either case, some portions of such translation table walks may be able to be eliminated by hardware if the relevant address information is already stored in an address translation cache. In contrast, software-managed translation table walks are unlikely to benefit from such caching, and in either case, even in the absence of caching, are typically slower than hardware-managed translation table walks.It may therefore be useful to provide as an architecturally defined operation available for use by software a translation table entry load / store operation that takes a selected address and triggers a load / store operation on the address of the corresponding translation table entry that corresponds to the selected address, leaving the responsibility of identifying the mapping between the selected address and the translation table entry address to the hardware of the address translation circuitry.

[0015] In response to a translation table entry load / store trigger instruction, it is not necessary to trigger a load / store operation to the selected address specified by the software-defined address information. Thus, a translation table entry load / store trigger instruction may cause the translation table entry load / store circuitry to trigger a load / store to at least one target translation table entry address without triggering a load / store to the selected address itself.

[0016] Different implementations may support different variants of translation table entry load / store operations. Some implementations may support only a single variant, but that variant may vary from implementation to implementation. Other implementations may support two or more different variants, with at least one software-defined information distinguishing which particular variant should be performed in response to a given instance of a translation table entry load / store triggering instruction. For example, the particular variant of the operation to be performed in response to a given instance of a translation table entry load / store triggering instruction may be set by any of the following architectural features: Translation table entry load / store trigger parameters of the instruction itself (e.g., the instruction's opcode, or another instruction field within the instruction's encoding). The presence or absence of a "prefix" instruction executed before the translation table entry load / store trigger instruction. If present, the "prefix" instruction modifies the behavior of the operation performed in response to a subsequent instance of the translation table entry load / store trigger instruction. The prefix instruction can identify which variant of the operation should be performed by the subsequent translation table entry load / store trigger instruction. If no prefix instruction is included before the translation table entry load / store trigger instruction, the translation table entry load / store operation may be performed according to the default variant. Control information stored in a register that identifies which variant of the operation should be performed. The register providing the control information may be, for example, a general-purpose register referenced by the instruction, or a predetermined system register not explicitly referenced by the instruction. Information stored at a given address in memory (e.g., in a memory-mapped register or in an entry in a buffer structure referenced based on a base address programmed in software) that can be read by the translation table entry load / store circuitry to identify the variant of the translation table entry load / store operation to be performed. Information specified within the selected address defined by the software-defined address information. For example, because the selected address is used to identify a translation table entry, and translation table entries are typically defined by region, some of the address bits of the selected address may be subregion bits that simply distinguish between different addresses within a region that all correspond to the same translation table entry. Therefore, these subregion bits are not meaningful for identifying which translation table entry corresponds to the selected address, and therefore can be reused to encode operation variant information that identifies the variant of the translation table entry load / store operation to be performed for a given instance of a translation table entry load / store trigger instruction.

[0017] One way in which variants of translation table entry load / store operations may differ may be with regard to how they determine which translation table entry is identified as the target translation table entry based on the selected address.

[0018] In some implementations, for at least one variant of the translation table entry load / store operation, the at least one translation table entry includes a leaf translation table entry. In this case, the translation table entry loaded or stored by the translation table entry load / store operation may be an entry that provides an address translation mapping for translating a selected address. In such variants, in addition to enabling clearing of access tracking metadata, the translation table entry load / store operation may also support updating the leaf translation table entry to change at least one of address mapping information for translating the selected address, access permission information indicating what types of memory access operations are allowed, and memory attribute information for controlling handling of memory accesses to the selected address.

[0019] In some implementations, for at least one variant of the translation table entry load / store operation, at least one translation table entry includes a translation table entry at a specified level of the translation table structure, regardless of whether the translation table entry is a leaf translation table entry or a branch translation table entry. For example, in a translation table structure having a certain maximum number of levels (e.g., four levels), leaf translation table entries (which provide address translation mappings rather than pointers to further translation tables that provide further translation table entries) may be defined at different levels of the table structure. For example, an entry at level 2 may be coded as a leaf translation table entry, so that the entry at level 2 is a branch translation table entry that points to another translation table, indicating address mapping information for a larger address space region than if the leaf translation table entry were defined at level 3. Thus, a variant of the translation table entry load / store operation may be provided in which the target translation table entry to be loaded or stored is at a specified level of the translation table structure reached by the translation table walk of the selected address, regardless of whether the entry at that level is a branch or a leaf. This option may be useful, for example, when software desires to set new translation table information for a given block of memory corresponding to a specified table level, regardless of whether that block of memory was previously defined with properties common to the entire block (using a leaf translation table entry at the specified level) or has been subdivided into smaller blocks (with either different properties, or the same compatible properties (with branch translation table entries at the specified level pointing to further tables that may define separate entries for each subdivision)).

[0020] In some implementations, for at least one variant of the translation table entry load / store operation, the at least one translation table entry includes a leaf translation table entry and each branch translation table entry traversed in the translation table walk operation to obtain the leaf translation table entry. Thus, this technique can hierarchically apply the translation table entry load / store operation to each translation table entry on a path through the translation table structure traversed in the translation table walk for the selected address, thereby allowing loads or stores to be performed on two or more translation table entries in response to the same translation table entry load / store trigger instruction. For example, in some implementations of the translation table structure, the access tracking metadata mentioned above may exist not only in the leaf entry but also at each level of the table. Thus, it may be useful to provide a variant of the translation table entry load / store operation that can, with a single instruction, clear the access tracking metadata in the leaf translation table entry corresponding to the selected address and in all branch translation table entries walked in the path to that leaf translation table entry. Thus, in some variants of the translation table entry load / store operation, based on a single selected address, two or more addresses of corresponding translation table entries may each be subjected to the translation table entry load / store operation.

[0021] In some implementations, for at least one variant of the translation table entry load / store operation, the at least one translation table entry includes a leaf translation table entry if a leaf translation table entry is validly defined for the selected address, and a final valid branch translation table entry reached in traversing the translation table structure for the selected address if a valid leaf translation table entry is not defined for the selected address. Thus, in this approach, the loaded / stored entry may be the final valid translation table entry that may be reached in a translation table walk for the selected address, regardless of whether the final valid translation table entry is a leaf entry or a branch entry and regardless of at what level of the translation table structure the final valid translation table entry appears. This may be useful for software, for example, when building a new translation table structure.

[0022] Another way in which variants of translation table entry load / store operations may differ may be in what type of load / store operation is performed on a given target translation table entry whose address is identified based on the selected address.

[0023] For example, at least one variant of a translation table entry load / store operation that supports clearing of access tracking metadata may also include at least one of the following: A store variant of a translation table entry load / store operation to update a given target translation table entry with an updated value specified by a store data operand. For example, the store variant may write a new value (specified as an operand of the operation) to a memory location corresponding to the address of a given target translation table entry. A swap variant of the translation table entry load / store operation to update a given target translation table entry with an updated value specified by a swap data operand and load either the pre-update value of the given target translation table entry or the post-update value of the given target translation table entry into a software-accessible location. This variant can be useful when, in addition to updating a given target translation table entry, subsequent operations that depend on information in that entry also need to be performed. an atomic compare and swap variant of a translation table entry load / store operation for determining whether a result of a comparison between a given translation table entry and a compare operand satisfies a compare condition, and, in response to determining that the result of the comparison satisfies the compare condition, updating a given target translation table entry based on a swap operand of the compare and swap variant, wherein the operation is performed atomically such that the result of the translation table entry load / store operation matches the result that would occur if a read operation to obtain a value for comparison with the compare operand and a write to write the updated value of the given target translation table entry were performed without an intervening write to the address of the given target translation table entry between the compare and swap read and write. Atomic bit update variants of translation table entry load / store operations to set or clear one or more specified bits of a given translation table entry, identified by a bit selection operand (e.g., an index identifying a single bit to be updated, or a mask for each bit identifying whether that bit should be updated). A bit update can set one or more specified bits to either 1 or 0, depending on the variant of the operation. In some implementations, a bit update operation may require a read to an address of a given translation table entry followed by a write to that address, because writes may be performed at a word granularity greater than 1 bit, and therefore a read operation may be required to read other bits of the same word as the bit to be updated, so that a new value including the updated bit (the other bits are still the same as those read previously) can be written back. Because separate read and write operations may be involved, atomicity may again be enforced for the bit update operation to ensure that the results are consistent with what would occur if there were no intervening write to the address of a given target translation table entry between the read and write of the atomic bit update operation.

[0024] For the atomic compare and swap and atomic bit update variants, atomicity can be implemented in different ways, such as by locking access to the relevant memory locations to prevent intervening write operations during the period between the read and write, or by speculatively allowing the read and write to proceed assuming there are no intervening write operations (without locking access to the locations) but providing techniques for detecting intervening writes to the locations, so that if an intervening write is detected, the translation table entry load / store operation can be canceled and repeated to ensure atomicity.

[0025] For each of the store, swap, atomic compare and swap, and atomic bit update variants described above, these variants may be capable of clearing access tracking metadata as mentioned above. These variants may also be capable of performing other types of updates to translation table entries, such as updating address mapping information, access permission information, or memory attribute information, as previously discussed. The operands of these variants of translation table entry load / store operations may define specific values ​​to be written to the target translation table entry to specify what type of information in the entry should be updated. These variants may also support setting the access tracking metadata to a first state.

[0026] The translation table entry load / store circuitry may also support load variants of translation table entry load / store operations to load at least one target translation table entry into at least one software-accessible register, in addition to the variants that support clearing of access tracking metadata as mentioned above. This may be useful to allow software to perform more complex operations of the loaded translation table entries using regular arithmetic instructions that operate on data stored in software-accessible registers. The store or compare and swap variants of the translation table entry load / store operations mentioned above can later be used to write back updated values ​​of the translation table entries once these operations are completed.

[0027] In response to the translation table entry load / store trigger instruction, the translation table entry load / store circuit is configured to perform an error reporting action in response to identifying that an error condition has occurred, the error condition including at least one of: no valid leaf translation table entry defined for the selected address; and a valid leaf translation table entry defined for the selected address at a level of the translation table structure other than an expected level. The expected level may be defined as an operand of the translation table entry load / store operation or may be part of the definition of which variant of the operation is being performed.

[0028] It may be useful to provide support for error responses because software may request a load / store to a translation table entry using one of the variants of the operations discussed above, but in reality the current configuration of the translation table structure may differ from that expected by the software, and therefore applying the load / store to the entry returned by that operation may run the risk of an error occurring that could result in improper setting of the translation table information.

[0029] For example, if software expects a leaf translation table entry to be defined for a given address, but there is no such leaf translation table entry, applying the update to some other location (e.g., an address that is not a valid translation table entry) could risk leaking information about the address space layout to software processes that are not trusted to see the mapped address. It could also risk other errors in memory access control (e.g., if an updated address mapping intended to be applied to a leaf entry is mistakenly applied to a branch entry, this could cause the intended leaf's mapped address to be treated as a pointer to a further translation table instead, which could give incorrect results for subsequent levels of the page table walk). Similarly, if software expects to set updated information for a given block of memory of a size corresponding to the leaf entry expected for a certain level of the table, but the leaf is found at a different level of the table than expected, applying the update at the incorrect level could result in the updated information being applied to a memory address region smaller or larger than expected. Thus, by providing a mechanism for reporting an error if a valid leaf is not identified for a selected address or if a valid leaf is at an incorrect level in the translation table structure from the expected level, this can reduce the risk of improper setting of translation table information. Supporting error responses also allows instructions to be used without requiring the use of coarse-grained locking structures in software, thus providing performance benefits.

[0030] Error reporting actions can be implemented in a variety of ways, for example, they can include signaling a fault (raising an exception) that may interrupt current software processing, or setting an error status indication in a register or other storage location that software can read to identify that an error has occurred.

[0031] In some examples, in response to a translation table entry load / store trigger instruction, the translation table entry load / store circuit is configured to update at least one software-accessible register with syndrome information, where the syndrome information specifies, for a selected address, at least one of a level of the translation table structure at which a valid leaf translation table entry is defined and information specified by the at least one target translation table entry. For example, the syndrome information may be written to the software-accessible register regardless of whether an error occurs. Even in an error-free scenario, it may still be useful for software to learn information from the translation table entry targeted by the translation table entry load / store operation.

[0032] The processing circuit may support a given instruction set architecture. The translation table entry load / store trigger instruction may be implemented within the instruction set architecture in different ways.

[0033] In some examples, the translation table entry load / store trigger instruction specifies a selected address as an operand of the translation table entry load / store trigger instruction, and the translation table entry load / store trigger instruction has an instruction opcode different from the load / store instruction to trigger a load / store operation to be performed on the address specified as the operand of the load / store instruction. The operand defining the selected address may be an immediate operand directly specified in the encoding of the instruction, or may be an operand stored in a register referenced by a register field specified in the encoding of the instruction.

[0034] Thus, the dedicated instruction (or multiple dedicated instructions supporting different variants of translation table entry load / store operations) may be defined in the instruction set architecture used by the processing circuitry separately from general load / store instructions that apply the load / store to an address specified as an operand of the instruction itself, rather than to the address of the corresponding translation table entry.

[0035] In this example, the translation table entry load / store circuit may be a general load / store unit provided within the processing circuit to handle general load / store instructions, but the processing circuit may have a mechanism for distinguishing (based on whether a translation table entry load / store instruction or a general load / store instruction is being executed) whether the address at which the general purpose load / store unit initiates the load / store operation is the address specified as an operand of the instruction itself or the address of a corresponding translation table entry identified by the address translation circuit as being used to translate the address specified as an operand of the instruction. Alternatively, for some implementations, the translation table entry load / store circuit may be implemented within the address translation circuit (rather than a load / store unit) because the address translation circuit may already have mechanisms for controlling page table walks or for retrieving translation table entries from a cache structure; therefore, once the address of the corresponding translation table entry is identified based on the selected address, it may be more efficient to implement the translation table entry load / store operation by expanding the range of operations available to the address translation circuit (e.g., by adding compare and swap or bit clear / set functions).

[0036] In another example, the translation table entry load / store trigger instruction includes a store instruction that specifies a predetermined translation table entry load / store trigger address as a store address operand, where a store to that address triggers the translation table entry load / store circuit to perform the translation table entry load / store operation. Therefore, this approach eliminates the need to provide encoding space within the instruction set architecture for a dedicated type of instruction for triggering a translation table entry load / store operation. Instead, an existing general store instruction can be used to trigger the translation table entry load / store operation, and the store address operand of the store instruction distinguishes whether the store should be treated as a conventional store operation (triggering a store to the address specified by the store address operand) or as a translation table entry load / store trigger instruction (the store address operand is an address mapped as a special address for triggering a translation table entry load / store operation). In this approach, for example, the predetermined translation table entry load / store trigger address can be the address of a memory-mapped register that, when written to, causes the translation table entry load / store circuit to perform a translation table entry load / store operation.

[0037] In this approach, the translation table entry load / store circuitry may obtain software-defined address information from a memory-based data structure that is accessed based on a software-programmable base address. When a normal store instruction is reused to trigger a translation table entry load / store operation, its address operand is already used to specify a predetermined translation table entry load / store trigger address, so the selected address used to identify which translation table entry should be loaded / stored is instead obtained from the memory-based data structure.

[0038] When the software-defined address information specified by the memory-based data structure specifies multiple selected addresses, the translation table entry load / store circuitry may perform a translation table entry load / store operation for each of the selected addresses in response to a single instance of executing a store instruction that serves as a translation table entry load / store trigger instruction. Thus, one advantage of using a store to a memory-mapped location to trigger a translation table entry load / store operation is that a single instruction executed by software may trigger multiple instances of a translation table entry load / store operation for each selected address specified by the memory-based data structure.

[0039] In this approach, the translation table entry load / store circuitry may operate asynchronously, eliminating the need for each selected address to be explicitly flagged using a separate instance of the instruction. The selected addresses to be processed may have previously been stored in a memory-based data structure prior to triggering the translation table entry load / store operation. In the asynchronous approach, the set of loads / stores required for each translation table entry corresponding to a defined set of selected addresses can be performed in the background of continued execution of other instructions by the processing circuitry, which may be beneficial for performance.

[0040] The translation table entry load / store circuitry may update a software-accessible location to specify a progress indicator that indicates progress made in performing translation table entry load / store operations on multiple selected addresses. This may be useful because if any error occurs in processing one of the selected addresses, processing may stop, and it may be useful for software to be able to identify how many of the selected addresses have already been successfully processed so that the address that caused the error can be identified.

[0041] If the translation table entry load / store circuit is triggered to perform translation table entry load / store operations on a plurality of selected addresses in response to a store instruction being processed by the processing circuit in a more privileged execution state, and the processing circuit subsequently switches to a less privileged execution state, the translation table entry load / store circuit may continue processing the remaining addresses of the plurality of selected addresses after switching to the less privileged execution state. Again, this reflects an asynchronous approach, whereby applying translation table entry load / store operations to the set of selected addresses may continue in the background while processing continues in the processing circuit based on execution of other instructions. Allowing this processing to continue despite the reduction in privilege in the processing circuit may be particularly useful because, in many cases, the responsibility for updating translation table entries lies with software executing in a more privileged execution state, but while those translation table entries are being updated, there may be no other processing required for the more privileged software, and therefore it may be useful to allow less privileged processes to make some forward progress executing instructions in the processing circuit in the meantime.

[0042] As mentioned above, a memory-based data structure may be used to define one or more selected addresses to which translation table entry load / store operations are applied. The selected addresses defined in such a data structure may be non-contiguous addresses that need not be contiguous within a given range.

[0043] Another option that may be used in either the approach of providing dedicated instructions in an instruction set architecture or the asynchronous accelerator approach of applying an operation to each address specified in a defined memory structure may be to specify, as the software-defined address information, range information that identifies a contiguous range of addresses to which the translation table entry load / store operation applies. Thus, for at least one variant of the translation table entry load / store operation, the software-defined address information specifies a range of addresses, and the translation table entry load / store circuitry is configured to perform the translation table entry load / store operation for each address in the range as the selected address.

[0044] The address translation circuit may support two-stage address translation between a virtual address space and a physical address space based on a first translation table structure providing address mapping information for translating between the virtual address space and an intermediate address space and a second translation table structure providing address mapping information for translating between the intermediate address space and a physical address space. The techniques discussed above may be applied to loads / stores to either entries in the first translation table structure or entries in the second translation table structure. Accordingly, several variants of transition table entry load / store operations may be defined targeting specific stages of address translation.

[0045] For example, the translation table entry load / store circuit is a variant of the first stage of the translation table entry load / store operation, wherein the selected address comprises a specified virtual address of the virtual address space, and the at least one target translation table entry comprises at least one translation table entry of the first translation table structure; and a second stage variant of the translation table entry load / store operation, wherein the selected address comprises a specified intermediate address within the intermediate address space and the at least one target translation table entry comprises at least one translation table entry of a second translation table structure.

[0046] Thus, the first stage variant may be useful for operating system software to manage updates to stage 1 translation tables, while the second stage variant may be useful for hypervisor software to manage stage 2 translation tables.

[0047] Several variants of translation table entry load / store operations are discussed above. As discussed above, it will be understood that a given implementation may support any one or more of these variants, so long as there is at least one variant that supports clearing access tracking metadata.

[0048] The techniques discussed above may be implemented in a data processing apparatus having hardware circuitry provided for implementing processing circuitry as discussed above, address translation circuitry and translation table entry load / store circuitry.

[0049] However, the same technique may also be implemented in a computer program that runs on a host data processing device to provide an instruction execution environment for execution of target code. Such a computer program may control the host data processing device to simulate an architectural environment provided on a hardware device that actually supports target code according to a particular instruction set architecture, even if the host data processing device itself does not support that architecture. The computer program may have address translation program logic and translation table entry load / store program logic that emulates the functionality of the address translation circuitry and translation table entry load / store circuitry discussed above, including support for translation table entry load / store operations. Such a simulation program may be useful, for example, when legacy code written for one instruction set architecture is being executed on a host processor that supports a different instruction set architecture. Furthermore, running software on a simulation execution environment can enable testing of software in parallel with the ongoing development of hardware devices that support the new architecture, so that simulation can enable software development of a new version of an instruction set architecture to begin before processing hardware that supports the new architecture version. The simulation program may be stored on a storage medium, which may be a non-transitory storage medium.

[0050] Examples of data processing devices 1 schematically illustrates an example data processing device 2. The data processing device has a processing pipeline 4 (an example of a processing circuit) that includes several pipeline stages. In this embodiment, 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 the micro-operation for execution once the operands required for a given micro-operation are available, an execute stage 16 for performing a data processing operation corresponding to the micro-operation by processing operands read from the register file 14 to generate a result value, and a writeback stage 18 for writing the results of the processing back to the register file 14. It will be understood that this is just one example of a possible pipeline architecture and that other systems may have additional stages or different configurations of stages. For example, an out-of-order processor may include a register rename stage for mapping architectural registers specified by a program instruction or micro-operation to physical register specifiers that identify physical registers in register file 14. In some examples, there may be a one-to-one relationship between 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 to be processed as a single micro-operation.

[0051] 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 that access data in the memory systems 8, 30, 32, 34. A memory management unit (MMU) 28, an example of memory management circuitry, is provided for performing 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 the 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 address translation mappings and may also specify access permissions that affect, for example, whether a given process running on the pipeline is allowed to read, write, or execute instructions from a given memory region.

[0052] 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 understood that this is only one example of a possible memory hierarchy and that other arrangements of caches may be provided. The particular types of processing units 20-26 shown in execution stage 16 are merely one example; other implementations may have different sets of processing units or may include multiple instances of the same type of processing unit so that multiple micro-operations of the same type can be handled in parallel. It will be understood that FIG. 1 is only a simplified representation of some components of a possible processor pipeline implementation, and that a processor may include many other elements that are not illustrated for the sake of brevity. While FIG. 1 shows a single processor core with access to memory 34, device 2 may have one or more additional processor cores that share access to memory 34, each core having its own cache 8, 30, 32.

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

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

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

[0056] Address Translation One task performed by the MMU 28 is address translation between virtual addresses (VA) and physical addresses (PA). Software executing on the processing circuitry 4 uses virtual addresses to specify memory locations; these virtual addresses can be translated by the MMU 28 into physical addresses that identify the memory system locations to be accessed. An advantage of using virtual addresses is that it allows management software, such as an operating system (OS), to control the view of memory presented to the software. The OS can control which memory is visible, the virtual addresses to which that memory is visible, and what accesses are allowed to that memory. This allows the OS to sandbox applications (hide one application's resources from another) and provide abstraction from the underlying hardware. Another advantage of using virtual addresses is that the OS can present multiple fragmented physical regions of memory to an application as a single contiguous virtual address space. Virtual addresses also benefit software developers, who do not know the system's exact memory addresses when writing their applications. With virtual addresses, software developers do not need to be concerned with physical memory. The application knows that it is up to the OS and hardware to work together to perform the address translation.

[0057] In practice, each application can use its own set of virtual addresses that are mapped to different locations in the physical system. When the operating system switches between different applications, it reprograms the maps, which means that the virtual addresses of the current application are mapped to the correct physical locations in memory.

[0058] Virtual addresses are translated to physical addresses through a mapping. The mapping between virtual addresses and physical addresses is stored in a translation table (sometimes called a page table). The translation table is stored in memory and managed by software, typically an OS or a hypervisor. The translation table is not static; the table can be updated as needed for software changes, which changes the mapping between virtual addresses and physical addresses.

[0059] For memory accesses performed when processing circuitry 4 is in a particular subset of execution states (specifically, when processing circuitry 4 is in non-secure EL0 or non-secure EL1), a two-stage address translation is used as shown in FIG. 3 (for other execution states, one stage of address translation using stage 1 page tables is sufficient). Thus, virtual addresses from non-secure EL0 and non-secure EL1 are translated using two sets of tables. These tables support virtualization and allow the hypervisor to virtualize the view of physical memory seen by a given virtual machine (VM) (the virtual machine corresponding to the guest operating system and the applications controlled by that guest operating system). The set of translations controlled by the OS is called Stage 1. The Stage 1 tables translate virtual addresses into intermediate physical addresses (IPAs—an example of the intermediate addresses mentioned above). In Stage 1, the OS considers the IPA to be a physical address space. However, the hypervisor controls a second set of translations, called Stage 2. This second set of translations translates the IPA into a physical address.

[0060] The stage 1 translation table and the stage 2 translation table are implemented as a hierarchical table structure that includes several levels of translation tables as shown in Figures 4 and 5 for stage 1 and stage 2, respectively. In this example, both the stage 1 table and the stage 2 table can have up to four levels of page tables: level 0 (level0, L0), level 1 (level1, L1), level 2 (level2, L2), and level 3 (level3, L3).

[0061] To find the physical address mapping for a given address, a translation table walk is performed, which includes one or more translation table lookups. A translation table walk is the set of lookups required to translate a virtual address to a physical address. In the case of a non-secure EL1&0 translation regime, this set includes lookups for both stage 1 and stage 2 translations. Information returned by a successful translation table walk using stage 1 and stage 2 lookups includes the following: The required physical address (translated based on the stage 1 mapping to intermediate addresses and the stage 2 mapping to physical addresses). Access permissions and / or memory attributes of the target memory region that provide information about how to control access to that memory region. These may include Stage 1 access permissions and / or attributes defined in the Stage 1 table structure and Stage 2 access permissions and / or attributes defined in the Stage 2 table structure.

[0062] To traverse a given one of the Stage 1 and Stage 2 structures, the walk begins by reading the top-level (L0) translation table for an initial lookup, based on the address specified in the Translation Table Base Address Register (TTBR for Stage 1, VTTBR_EL2 for Stage 2). Each translation table lookup returns a descriptor indicating one of the following: The entry is the final entry in a traversal of a stage 1 or stage 2 structure and provides the address mapping being explored. If the entry is in the last L3, it is called a page descriptor (D_Page), while if the entry providing the final entry of the walk is in one of the higher levels, it is called a block descriptor (D_Block). Page and block descriptors are sometimes collectively referred to as "leaf" translation table entries, where "leaf" refers to the final entry of the walk that provides the address mapping. The final entry of a traversal contains the output address (OA, i.e., IPA in stage 1 or PA in stage 2) and access permissions and attributes. If a block descriptor is found at a higher level in the translation table structure, this means that the block descriptor represents a memory region of a size larger than the 4kB memory page represented by a single entry in L3 (the specific size represented by the block descriptors in L1 and L2 depends on the number of index bits used to index into the L1 or L2 table; in this example, the L1 and L2 block descriptors represent 1GB and 2MB regions, respectively). An additional level of lookup is required. In this case, the entry is called a table descriptor (D_Table), or "branch" translation table entry, because it provides the translation table base address for that lookup in the further level table. The table descriptor can optionally also provide other hierarchical attributes that can be applied to the final translation. The encoding of translation table entries at level 1 and level 2 distinguishes block descriptors from table descriptors. The descriptor is invalid. In this case, the memory access generates a translation failure.

[0063] Figure 4 illustrates indexing of the stage 1 translation table using respective bits of the virtual address provided as the input address for the table lookup. The base address of the top-level table L0 is read from the TTBR, and the base addresses of the L1, L2, and L3 tables are indicated by the addresses stored in the indexed table descriptors in the L0, L1, and L2 tables, respectively. (If no block descriptor is identified in the L1 or L2 table, or if a block descriptor is found in an indexed entry in L1 or L2, the output address mapping has already been found and traversal stops at that level.) The particular entry to select within a given level of the stage 1 translation table is determined based on index values ​​a, b, c, and d, which correspond to a certain subset of the bits of the virtual address provided as the input address for the lookup. Figure 4 illustrates which bits of the input address are used for each index value a, b, c, and d in one particular example. The address of the relevant entry in a given table is obtained by adding a multiple of index bits a, b, c, or d to the base address of that given table, determined based on the TTBR, or to the address specified in the previous level table descriptor (the multiplier is applied to the index value corresponding to the size of one translation table entry).

[0064] Similarly, FIG. 5 illustrates indexing of the stage 2 translation table using respective bits of the intermediate address provided as the input address for the stage 2 table lookup. The indexing is similar to that shown in FIG. 4 for stage 1, but uses a different base address register, VTTBR_EL2, to provide the base address of the L0 table. As shown in the example of FIG. 5, for stage 2 lookup, it is possible to change the starting level at which the walk of the stage 2 translation table begins based on the value stored in control register VTCR_EL2.SL0, which can specify whether the lookup should start from either L0 or L1. If the stage 2 lookup starts from L0, indexing for levels 0, 1, 2, and 3 uses index values ​​a, b1, c, and d, respectively, as in FIG. 4 for stage 1. If the stage 2 lookup starts from L1, indexing is performed in a similar manner, but now more index bit b2 is used at the top level (L1) of the lookup, as shown in FIG. 5. Providing a variable starting level is not an essential feature and can be omitted if desired. Although not shown in FIG. 4, it is also possible to provide a variable starting level for the lookup in stage 1.

[0065] In effect, when a full translation table walk is performed, including both stage 1 and stage 2 translations, each stage 1 table base address obtained from the TTBR and table descriptor accessed in the stage 1 L0, L1, L2 translation tables becomes an intermediate address that itself needs to be translated using the stage 2 translation table. Thus, if the translation table walk does not encounter a block descriptor but continues all the way to L3 where a page descriptor is found, the full page table walk process may involve accessing multiple levels of page tables in the following sequence: Stage 2 translation of the Stage 1 L0 page table base address to a physical address (the Stage 1 L0 base address is typically an intermediate physical address, as the Stage 1 translation is constructed by the operating system). The Stage 2 translation involves four lookups (Stage 2 L0; Stage 2 L1; Stage 2 L2; Stage 2 L3). Stage 1 L0 lookup of the entry at the address obtained based on the L0 index portion "a" of the target virtual address and the translated Stage 1 L0 base address to obtain the Stage 1 L1 base address (intermediate physical address). Stage 2 translation of stage 1 L1 base address to physical address (again involving 4 lookups). Stage 1 L1 lookup of the entry at the address obtained based on the L1 index portion "b" of the target virtual address and the translated Stage 1 L1 base address to obtain the Stage 1 L2 base address (intermediate physical address). Stage-2 translation of stage-1 L2 base address to physical address (again involving 4 lookups). Stage 1 L2 lookup of the entry at the address obtained based on the L2 index portion "c" of the target virtual address and the translated Stage 1 L2 base address to obtain the Stage 1 L3 base address (intermediate physical address). Stage 2 translation of stage 1 L3 base address to physical address (again involving 4 lookups). A stage 1 L3 lookup of an entry at an address obtained based on the L3 index portion “d” of the target virtual address and the translated stage 1 L3 base address to identify a target intermediate physical address corresponding to the target virtual address. Stage 2 translation of the target intermediate physical address to a target physical address representing a location in memory to access corresponding to the original target virtual address (again involving four lookups).

[0066] Thus, assuming no caching and a stage 2 starting level of L0, the translation would involve a total of 24 lookups. If the starting level for stage 2 were L1, this could reduce the number of lookups to 19 (one less lookup for each of the five stage 2 translations performed). Nevertheless, as can be seen from the above sequence, performing the entire page table walk process can be very slow, potentially requiring numerous accesses to memory to step through each of the levels of page tables in each stage of the address translation. This is why it is often desirable to cache information derived from the translation table walk in the TLB 29 of the MMU 28. The cached information may include not only the final stage 1 address mapping of VA to IPA, the final stage 2 mapping of IPA to PA, or the combined stage 1 and stage 2 mapping of VA directly to PA (derived from previous lookups of the stage 1 and stage 2 structures), but entries from the upper-level page tables of the stage 1 and stage 2 tables may also be cached in the TLB 29 of the MMU 28. This allows at least some steps of the full page table walk to be bypassed even if the last level address mapping for a given target address is not currently in the address translation cache.

[0067] Thus, a TLB 29 that supports "walk caching" (caching of pointers from branch translation table entries) may provide a faster route for identifying the address of a location in memory that stores a branch translation table entry or leaf translation table entry that corresponds to a particular address. Even if walk caching is not supported, the MMU 28 may support translation table walking circuitry in hardware that can generate the sequence of memory accesses needed to traverse the page table structure based on an input address to be translated, faster than would be possible if software had to explicitly execute a series of load / store / arithmetic instructions to calculate an index value into the translation table based on the address to be translated, use that index to generate an address to read for the next level translation table entry, load the next level translation table entry, and then repeat for any further levels based on the pointer loaded for the previous level until a leaf entry that provides the address mapping is found.

[0068] FIG. 6 illustrates an example of a branch translation table entry 50 and a leaf translation table entry 52. ​​Both types of translation table entries have an encoding that identifies them as valid translation table entries. In the example of FIG. 6, for example, a valid translation table entry is required to have its least significant bit set to 1. This encoding can help avoid instruction address pointers, which are typically aligned to multiples of the instruction size and therefore may be expected to have some low-order bits equal to 0, from being mistakenly treated as valid translation table entries. It will be appreciated that there may be other ways of identifying valid translation table entries. In a translation table walk, if the value loaded for a given level of the walk is not a validly encoded translation table entry, a fault may be signaled.

[0069] In this example, the penultimate bit is used to distinguish between branch translation table entries 50 and leaf translation table entries 52 that are found at a given level of the translation table walk other than the maximum level supported in the translation table walk (in the example above, the maximum level is level 3). Thus, in the above example, the penultimate bit is used at levels 0, 1, and 2 to distinguish between table descriptors and block descriptors. If the penultimate bit is 1, the entry is a table descriptor, and if the penultimate bit is zero, the entry is a block descriptor. Page descriptors (leaf entries at the maximum supported level 3) are encoded with the penultimate bit as 1. Again, it will be understood that this is just one example encoding and that other encodings can be used to distinguish between different types of descriptors.

[0070] A branch translation table entry (table descriptor) 50 specifies a next level table address 54 that provides a pointer to the next level table in the translation table structure. The next level table address 54 serves as a base address from which the addresses of individual entries in the next level table can be calculated based on offsets derived from an index value selected based on bits in the address being translated.

[0071] In contrast, leaf translation table entries 52 specify address mapping information 56 that provides address mappings for mapping addresses to be translated from an input address space to an output address space. For stage 1 tables, the input address space is a virtual address space and the output address space is an intermediate address space, and for stage 2 tables, the input, intermediate, and output address spaces are physical address spaces.

[0072] The leaf translation table entry 52 may also specify several fields 58 for encoding access permissions and / or memory attributes. The access permissions may specify what type of memory accesses are permitted to be performed for the corresponding region of the address space. For example, the access permissions may specify whether the region is permitted to be read, written, and / or used for instruction fetching of executable instructions. The memory attributes may specify other properties of the memory region, which may affect how memory accesses are performed when access is permitted based on the permissions. For example, these attributes may specify properties such as whether caching data from the corresponding memory region is permitted or whether the region is defined as device memory such that reordering or merging of different memory accesses into device memory is not permitted. The access permissions and memory attributes may be explicitly encoded within the fields 58 of the translation table entry, but may also be defined using indirect references to registers. For example, the fields 58 of the leaf translation table entry 52 may specify a register number that identifies a given register and / or a register field identifier that identifies a particular field within the register, and the access permissions and / or memory attributes may be encoded by a value stored in the register or register field referenced by the translation table entry. Indirect permission / attribute specification using registers can be useful because it allows software to quickly update permissions for many translation table entries that all reference the same permission / attribute field with a single update to a register, rather than having to update many different translation table entries in memory. Also, in implementations where each field in the permission indirect register has more bits than the corresponding permission field in the translation table entry, indirection can be useful for supporting more types of permissions / attributes than is possible with the limited encoding space for permissions in the entry.It will be appreciated that in some implementations, access permissions and memory attributes may be defined through a combination of explicitly encoded information within the translation table entry format itself and indirectly referenced information in registers. Although the branch translation table entries in Figure 6 are not shown as specifying access permissions or memory attributes, in other examples, the branch translation table entries may also specify some permissions or attributes that apply to the corresponding block of memory covered by the branch translation table entry.

[0073] Leaf translation table entries (and in some examples, branch translation table entries as well) may also specify one or more access tracking metadata that can be used to provide information about which regions have been accessed by load / store operations. In this example, there are two types of access tracking metadata: an access flag (AF) 70 and a dirty bit modifier (DBM) 72. It will be understood that providing both types of access tracking metadata is not required, and other types of access tracking metadata (e.g., a counter that counts the frequency of accesses to the corresponding memory region) can be used. Both forms of access tracking metadata can have a first state indicating that at least one load / store access has occurred to the corresponding region of the input address space, and a second state indicating that no load / store access has occurred to the corresponding region of the input address space. The access flag 70 can be used to track read accesses to the region, and the DBM 72 can be used to track write accesses.

[0074] Periodically, operating system software may set access flag 70 to a second state (indicating zero accesses) in entries corresponding to the set of monitored memory regions. When a read access is made to one of these memory regions, access flag 70 may be set to the first state in the corresponding stage 1 block or page descriptor (if not already set following a previous access). In some examples, a store memory access used to set access flag 70 in leaf translation table entry 52 corresponding to a target address specified by another load access may be triggered automatically in hardware by MMU 28 when processing the load to the target address, rather than requiring an explicit software instruction to write to leaf translation entry 52.

[0075] After a certain monitoring period, the operating system can check the access flag 70 of the monitored entries to support operations that can benefit from information about how frequently a particular page is accessed. For example, the operating system can maintain a further tracking data structure in memory with an entry for each memory region that tracks how many times the memory region has been accessed, and thus, at the end of each monitoring period, increment the entry in that further tracking structure that corresponds to the memory region that has the access flag 70 set. After several monitoring periods, the further tracking structure provides an indication of the relative frequency of accesses to the corresponding memory region. This can provide useful information for controlling operations such as paging; it can be useful to know the least frequently accessed pages of memory whose corresponding data can be prioritized for paging out to external storage compared to other, more frequently accessed pages. The specific use of the access flag 70 can vary based on the software, but generally, it can be useful for software to provide at least one bit used to track whether any read accesses have occurred to the corresponding region of memory.

[0076] Similarly, DBM 72 helps track which pages have received writes. If the operating system wants to track whether a given page has been written to, it can set the access permissions for that page as "read-only" when the page is mapped or at the beginning of a monitoring period (even if the page is intended to be allowed to be written to) and set DBM bit 72 to a second state (indicating that there has been no previous write access to the page). If a access permissions failure is caused by a write to a read-only page when DBM bit 72 is set, the operating system can determine that this is not a "true" violation of read-only permissions because DBM bit 72 is set, and instead cause the operating system to update a data structure stored in memory that tracks pages that are the subject of write requests, update DBM bit 72 to the first state (indicating that at least one previous write access has occurred), and update the write access permissions for the page to indicate that the page can now be written to without triggering a failure. After a period of monitoring, the tracking data structure in memory can be used by software to determine whether modified data from a particular region needs to be written back to external storage when that region is paged out, or whether the corresponding data in external memory can be assumed to still be the same if the data is clean, and therefore the data stored in memory can simply be discarded when the region is paged out.

[0077] In other implementations, translation table entry permission information 58 can function as access tracking metadata used to track whether a given page has been written. For example, all pages may be initially set as “read-only,” as mentioned above, and DBM indicator 72 may be set for pages that should actually be readable / writable but are only temporarily “read-only” because they have not yet been written to. When set, DBM indicator 72 may indicate to MMU 28 hardware whether it is permitted to update translation table entry permission information 58 to add write permission when a write to a read-only region is detected. Thus, similar to the example above, the first write to a previously unwritten page can be detected from the fact that the page was read only when DBM bit 72 was set to a state indicating that a hardware update to add write permission is permitted; subsequently, once write permission is added, the permission field can be used to determine that the page has been written. Thus, in this example, a first state of the access tracking metadata (indicating at least one previous write access) may be when the permission information 58 indicates read / write permission, and a second state (indicating no previous write access) may be when the permission information 58 indicates read-only when the DBM bit 72 is set.

[0078] Thus, for both access flags 70 and DBM bits 72 (and / or permission field 58, if the permission field is used to indicate whether the page has been previously written), it is software, not hardware, that is responsible for clearing the access tracking metadata back to the second state (indicating that no previous load / store accesses have occurred to the corresponding region of address space).If translation table entry load / store operations of the type discussed below were not supported, this would require a general store instruction specifying as a target address the address of the memory location where the translation table entry to be updated is stored.

[0079] General Load / Store Instructions FIG. 7 illustrates an example of a general load / store instruction for comparison with FIG.

[0080] A load instruction is an instruction that triggers the reading of a location in the memory system 30, 32, 34 and returns the read data to a register. A general load instruction specifies a destination register Xn into which the read data should be loaded and a target address operand (specified in this example using the value stored in register Xm) that identifies the memory location to be read using, for example, a virtual address in the virtual address space.

[0081] A store instruction is an instruction that stores store data obtained from a register at a location in a memory system. A general store instruction specifies a source register Xn from which the store data is to be obtained and a target address operand (specified using the value stored in register Xm in this example) that identifies the memory location to which the store data is to be written.

[0082] Thus, for a general load / store instruction, the load / store operation is performed on the memory location identified by the address specified by the address operand of the instruction.

[0083] When updates are required to a translation table, it is conventional to use such general load / store instructions. A general load instruction may read the current contents of a translation table entry, and a general store instruction may update the contents of a translation table entry. However, because the load / store operation is performed on a location corresponding to the address specified in the address operand of the load / store instruction, this means that software must first identify the address of the location storing the relevant translation table entry. This can be complicated, as shown above in Figures 4 and 5, because software may need to walk the translation table structure based on the particular address of interest for which the corresponding translation table entry (which provides the address mapping for that particular address or provides a pointer on the path through the translation table walk to find the entry that provides the mapping for that particular address) is to be updated. This walk requires software to execute many instructions (e.g., several dependent load instructions, as well as arithmetic instructions to calculate the address of the entry to read at each level of the walk). This can be slow. This can incur a significant performance cost, as in many cases a large number of translation table entries may need to be updated (e.g., when clearing access tracking metadata at the end of an accounting period to monitor memory access frequency, or when migrating a virtual machine from one host processor to another).

[0084] Conversion table load / store trigger instructions 8 illustrates an example of a translation table entry load / store trigger instruction that controls the translation table entry load / store circuitry to perform a translation table entry load / store operation on at least one target translation table entry address selected depending on software-defined address information identifying a selected address in an input address space translated to an output address space by a given translation table structure. Unlike the general load / store instruction shown in FIG. 7, a translation table entry load / store operation triggered by a translation table entry load / store trigger instruction being processed by the processing circuitry 4 does not perform a load / store on the selected address itself, but rather performs a load / store operation on at least one target translation table entry address selected based on the selected address defined in the software-defined address information. The at least one target translation table entry address is selected by the address translation circuitry 28 to be one or more addresses of one or more target translation table entries corresponding to the selected address. Each target translation table entry is either a leaf translation table entry that provides the actual address mapping information for translating a selected address from an input address space to an output address space, or a branch translation table entry that is traversed in a transition table walk operation to obtain the leaf translation table entry that corresponds to the selected address.

[0085] Therefore, the instruction that triggers a translation table entry load / store operation does not itself need to specify the address of the location where the entry is to be stored. This is because the address of the translation table entry to be loaded or stored can instead be derived in hardware by the address translation circuit 28 based on an existing mechanism for caching translation table entries in the TLB 29 (e.g., based on a page table walk cache that caches pointers to entries in the translation table structure) or based on a page table walk circuit implemented using hardware circuit logic that can trigger a series of memory accesses to walk the translation table structure based on an input address. Therefore, by supporting this operation, software can manipulate translation table entries without performing a page table walk in software. The page table walk is performed by hardware and is permitted to utilize the walk cache in the MMU 28. The benefits are reduced software complexity, reduced total execution time spent on the operation, and therefore improved performance. This also allows for the elimination of locking structures, further saving time because software agents manipulating translation table entries do not need to acquire coarse-grained locks while performing the operation.

[0086] Also, because software manipulating page tables does not need to issue explicit loads / stores to the addresses of page table entries, this means that software manipulating page tables does not need to create a separate set of page table entries that point to page table entries of interest. This is useful because by not explicitly mapping page table entries to the address space visible to the software manipulating them, the software avoids the possibility of corrupting page table entries when another load / store operation not intended to update the page table incorrectly sets its address operand (either accidentally due to an error or maliciously due to an attacker exploiting a memory bug to make the address operand incorrect). If the address operand of another load / store is incorrectly set to the address of a translation table entry, the memory access triggers a fault due to not having a valid translation table entry defined for that address in the input address space. Nevertheless, even if there are no page table entries providing input-to-output address mappings for some of the addresses pointed to by the translation table pointers, the hardware may still be able to follow the trail of pointers defined in other translation table entries to walk the translation table structure.

[0087] In some examples, the instruction set architecture supported by processing circuitry 4 may support a new set of memory access instructions that trigger translation table entry load / store operations (as distinguished from general load / store operations). Figure 8 illustrates two examples of such instructions: a translation table entry load trigger instruction and a translation table entry store trigger instruction.

[0088] The translation table entry load trigger instruction, in this example, specifies a destination register Xa and an address operand, which is provided using the value stored in register Xb in this example. Similarly, the translation table entry store trigger instruction, in this example, specifies a source register Xa and an address operand, which is provided using the value stored in register Xb in this example. The address operand can specify either the address itself or an offset to a reference address, such as the current value of a program counter, which indicates the execution point reached by the executing program. For both load and store variants of the instruction, the address operand is an example of software-defined address information and specifies the selected address.

[0089] For both variants, in response to the instruction being decoded by the decode stage 10 and processed by the execution stage 16, the MMU 28 retrieves the address of the leaf translation table entry corresponding to the selected address from its address translation cache 29 (if already cached), or if there is no existing cached information providing the address of the leaf translation table entry, the MMU 28 triggers a page table walk to retrieve the address of the leaf translation table entry. For the load variant of the instruction, a load is performed to read the leaf translation table entry from the memory system 30, 32, 34, and the loaded translation table entry is written to the destination register Xa. For the store variant of the instruction, the store data retrieved from the source register Xa is written to the location in the memory system 30, 32, 34 corresponding to the address of the leaf translation table entry.

[0090] FIG. 8 shows two examples of translation table entry load / store trigger operations that may be implemented, although several other variants may also be provided, as follows:

[0091] First, the operation variants may differ in which translation table entry is targeted by the load or store operation. In the example of Figure 8, the target translation table entry is a leaf translation table entry that translates the selected address specified using address operand Xb. However, other examples may select one or more target translation table entries in different ways, for example: · selecting a translation table entry obtained for the selected address at a specified level of the translation table walk (e.g., a level 1 translation table entry obtained in the translation table walk for the selected address, regardless of whether the level 1 translation table entry is a leaf translation table entry or a branch translation table entry) as a target translation table entry; Select as target translation table entries the leaf translation table entry and each branch translation table entry on the path to the leaf translation table entry to be used to translate the selected address. For example, this variant of the translation table entry store instruction may be used to clear the access flags at each level of the translation table structure on the path to the leaf. Select the last valid translation table entry reached in the translation table walk for the selected address as the target translation table entry, regardless of whether that last valid entry is a branch translation table entry or a leaf translation table entry (this can be useful when the table structure is still only partially built).

[0092] There may also be variants of the operation that target a stage 1 translation table entry or a stage 2 translation table entry, respectively. In the stage 1 variant of the operation, the selected address specified using address operand Xb is a virtual address, and the load / store operation is performed on at least one stage 1 translation table entry corresponding to that address. In the stage 2 variant of the operation, the selected address specified using address operand Xb is an intermediate address, and the load / store operation is performed on at least one stage 2 translation table entry corresponding to that address.

[0093] Additionally, variants of the behavior can be defined that vary in the specific behavior applied to each target translation table entry. For the load variant of the instruction in Figure 8, the operation is a load, which loads a translation table entry into the destination register. For the store variant of the instruction in Figure 8, the operation is a store, writing the store data obtained from source register Xa to the memory location associated with the target translation table entry address.

[0094] Further variants can be defined as follows: CASS1 Xa,Xb,[Xc] - Atomic compare and swap stage 1 translation table entries. Xa provides the comparison operand. Xb provides the swap operand. Xc provides an address operand to identify the selected address.

[0095] In response to the instruction, MMU 28 is controlled to obtain at least one target translation table entry address of at least one target stage 1 translation table entry corresponding to the selected address (the target entry is determined according to any of the examples above). For each such target translation table entry address, an atomic compare and swap operation is initiated, and the atomic compare and swap is reading data from a memory location corresponding to the target translation table entry address; comparing the read data with the comparison operand; If the comparison between the read data and the comparison operand satisfies the comparison condition, writing the swap operand to a memory location corresponding to the target translation table entry address, which is not performed if the comparison condition is not satisfied; Returning a status indication (e.g., in a control register or by setting a condition status flag) indicating whether the comparison condition was met.

[0096] The read and write operations in a compare and swap are performed atomically, such that the compare and swap operation is seen as a single, indivisible operation by other observers of the memory location corresponding to the target translation table entry address. This means that the result of the compare and swap is equivalent to the result that would be obtained if no other writes to the target translation table entry address occurred between the read and write. Atomicity can be implemented in different ways, for example, by locking access to the address to prevent intervening write operations, or by continuing to allow access to the location corresponding to the address but providing a mechanism for detecting when an intervening write occurs between the read and write of the atomic compare and swap operation and canceling and re-executing the atomic compare and swap operation if an intervening write is detected. In some implementations, the memory system 30, 32, 34 may have a mechanism for allowing the atomic compare and swap operation to be performed locally near the location storing the data to reduce the delay between the read and write performed. Other examples may not support this and may require data transfer between the processing pipeline 4 and memory to support the atomic compare and swap, so the comparison portion of the operation may be performed in the processing pipeline 4.

[0097] SWAPS1 Xa,Xb,[Xc] - Swap stage 1 translation table entries Xa is the destination register, Xb provides the swap data operand, and Xc provides the address operand for identifying the selected address. The instruction causes the MMU to obtain the target translation table entry address of the stage 1 translation entry based on the selected address specified by operand Xc. The swap operation is performed to update the translation table entry at the target translation table entry address to the update value specified by the swap data operand in Xb, and to load either the pre-update value of the target translation table entry before the update or the post-update value of the target translation table entry after the update into destination register Xa.

[0098] BITSETS1 Xa,[Xb] In response to the instruction, MMU 28 is controlled to obtain at least one target translation table entry address of at least one target stage 1 translation table entry corresponding to the selected address (the target entry is determined according to any of the examples above). Xa provides a bit position operand or bit mask specifying the position within the translation table entry of at least one bit that is set to 1. Xb provides an address operand for identifying the selected address.

[0099] For each such target translation table entry address, an atomic operation is initiated to Read data from the memory location corresponding to the target translation table entry address; Updates one or more bits of the target translation table entry at any bit positions specified by the bit position operand Xa, setting one or more bits to 1 and leaving all other bits of the translation table entry unchanged; ·Write the updated value of the translation table entry back to the memory location corresponding to the target translation table entry address.

[0100] Again, this is done atomically, imposing atomicity as discussed above for the compare and swap variant. A similar bit-clear variant of the instruction can be provided, which sets the specified bit to 0 instead of 1.

[0101] For each of the variants described for stage 1 above, a similar stage 2 variant can also be provided in which the address operand is instead interpreted as an intermediate address (rather than a virtual address as in the stage 1 variants) and the target translation table entry is an entry in the stage 2 table (and therefore any walk to obtain the address of the target translation table entry is based on the stage 2 base address in VTTBR_EL2 instead of the stage 1 base address in TTBR in the stage 1 variant of the operation).

[0102] In addition to all of the above, instructions can be provided to support different variants for describing the final level of the walk. In the first variant, the instruction encoding indicates "perform the operation regardless of what the final level of the walk will be." In the second variant, the instruction encoding indicates "expect the final level of the walk to be level X," and the hardware will raise a fault condition or signal another error response (e.g., set an error code in a register) if this does not match the current configuration of the translation table (i.e., if the leaf entry for the selected address is at a level other than level X).

[0103] In addition to all of the above, instructions can handle error conditions according to their controls. It is possible for software to use instructions improperly so that leaf-level page table entries are not found. In these situations, the hardware can generate an exception or populate a register to indicate "operation failed." Regardless of the reporting mechanism, an error code is reported indicating the nature of the error.

[0104] Different variants of an operation can be distinguished either by the instruction opcode, another field in the instruction encoding, a preceding instruction that modifies the behavior of the instruction, or by control information stored in a control register or other storage location. Also, some low-order bits of the selected address specified by the address operand can be used to encode the variant of the operation, since those low-order bits (subpage or subregion address bits) are not needed to identify the address of the page corresponding to the associated translation table entry to be updated.

[0105] At least the store, compare and swap, and bit set / clear variants may be examples of variants that support clearing of access tracking metadata 70, 72, 58 in translation table entries, but these instructions may also be used to update other translation table information such as address mappings 56, table pointers 54, and access permissions or memory attributes 58.

[0106] Variants may also be provided that identify multiple selected addresses, each of which has a translation table entry load / store operation applied to it. For example, an instruction may specify information defining a range of addresses, and each address within the range may be considered a selected address at which a respective instance of a translation table entry load / store operation is to be performed. Thus, a range-based operation may target more than one translation table entry and perform appropriate translations to multiple leaf-level translation table entries and / or higher-level entries leading to them.

[0107] In an example where the instruction set architecture supports dedicated instructions for triggering translation table entry load / store operations, the translation table entry load / store circuitry can be considered to comprise a load / store unit 26 (also used for general load / store operations) and an MMU 28 (address translation circuitry).

[0108] method 9 shows a method of data processing. In step 200, instructions are processed (e.g., decoded and executed) by the processing circuitry. In step 202, for any load / store instruction, the address translation circuitry 28 translates between the input address space and the output address space based on mapping information 56 obtained from the translation table structure.

[0109] 10 illustrates a method for processing a translation table entry load / store operation that may be performed in step 200 of FIG. 9. In response to a translation table entry load / store trigger instruction being processed in step 210, in step 212, the address translation circuit 28 selects at least one target translation table entry address according to software-defined address information identifying a selected address in the input address space translated by a given translation table structure. Each target translation table entry address includes the address of a leaf translation table entry that provides address mapping information for translating the selected address or the address of a branch translation table entry that is traversed in a translation table walk operation to obtain the leaf translation table entry. For example, the at least one target translation table entry address may be obtained from the address translation cache 29 or by performing a translation table walk on the selected address.

[0110] In step 214, the address translation circuit 28 determines whether an error condition has been identified, such as there being no valid translation table entry defined for the selected address or there being a leaf translation table entry identified at a different level in the translation table structure compared to the expected level. If an error condition is identified, in step 216, an error reporting action is taken, such as signaling a fault or setting an error status indication in a register, which can notify software that the current configuration of the translation table structure was not as expected.

[0111] If no error condition is identified, then in step 218, the translation table entry load / store circuit 26, 300 performs a load / store operation on at least one target translation table entry address. This load / store may be any of the variants of the translation table entry load / store operation discussed above. For at least one of these variants, the load / store supports clearing of access tracking metadata.

[0112] In step 220, syndrome information is updated in a software-accessible register. The syndrome information may provide information about the updated translation table entry, such as specifying the level of the translation table structure at which the translation table entry was found and / or specifying information about access permissions or memory attributes within that entry (e.g., whether the entry specified a read-only region of memory).

[0113] Accelerator example 11 illustrates another example of the device 2, in which a translation table entry load / store circuit 300 is provided as an accelerator separate from the load / store unit 26 used to perform normal load / store operations. The translation table entry load / store accelerator 300 has access to the address translation circuit 28, which can trigger a lookup in the TLB or any walk cache 29 and trigger a walk circuit 302 in the address translation circuit 28 to perform a hardware-managed translation table walk for a given address specified by the translation table entry load / store circuit 300. Alternatively, the accelerator 300 can have the address translation circuit 28 provided by a local MMU-like structure separate from the main MMU used by the load / store unit 26 for normal loads / stores. The translation table entry load / store circuit 300 can also initiate load / store operations to the memory system 304 (including the caches 30, 32 and the memory 34), which can be performed asynchronously and does not require specific execution of individual load / store instructions for each address to be loaded / stored.

[0114] 12 illustrates a programmer interface for accelerator 300 that includes one or more memory-mapped registers. A memory-mapped register is a register that is accessed by processing circuitry 4 by performing a general load / store operation that specifies a predetermined address assigned to represent the memory-mapped register as the target address of the load / store. A memory-mapped register provides: A base address 310 indicating a physical address that marks the start of a memory-based ring buffer structure 320, which serves as software-defined address information that defines one or more addresses to be used as "selected addresses" for translation table entry load / store operations. The ring buffers 320 are in a contiguous region of physical address space. Software can assign addresses to the ring buffers at which corresponding translation table entries should be loaded / updated. The accelerator 300 hardware can read the buffer to identify addresses to process using translation table entry load / store operations. A size parameter 312 to allow the accelerator 300 to find the location of the end of the buffer 320. An "execute" parameter 314 that indicates to the accelerator 300 whether to perform a translation table entry load / store operation on the next address in the ring buffer 320. When software sets the "execute" parameter to a first state (e.g., 1), the accelerator 300 begins working through the buffer, performing a translation table entry load / store operation on each address indicated in the buffer. When the accelerator reaches the end of the buffer or encounters an error, the accelerator 300 hardware clears the "execute" parameter to a second state (e.g., 0). When the "execute" parameter is in the second state, the accelerator 300 does not perform a translation table entry load / store operation. A "fault" field 316 used to record fault information indicating any errors detected by the accelerator 300 when performing a translation table entry load / store operation. Software can clear the "fault" field to a first state (e.g., 0) before starting the operation, and hardware 300 can set the fault field to a second state (e.g., 1) when a fault occurs (and change "run" to the second state to stop continued performance of the translation table entry load / store operation). When in the second state, the fault field can also specify further information about the cause of the fault. A "progress" field 318 provides a "current index" that identifies the most recent entry in the memory-based buffer 320 that was processed using a translation table entry load / store operation. The index 318 can be used to calculate the memory address to read for the next entry in the buffer, relative to the base address 310. The index is incremented each time an address from the buffer 320 is successfully processed using a translation table entry load / store operation. If an error occurs, the index provided by the progress indicator 318 can be used by software to identify which address caused the error.

[0115] The various pieces of information 310-318 indicated in the memory-mapped registers may be encoded in the registers in different ways, for example, in some instances there may be a separate register for each piece of information, or some of the information may be combined in the same register. For example, the base address 310 and size 312 may be encoded in one memory-mapped register (given address A), while the execution 314, fault 316, and progress 318 indicators may be encoded in a second memory-mapped register (given address B).

[0116] Thus, in this approach, the instruction that triggers the translation table entry load / store instruction can be a general store instruction processed by processing circuitry 4 that specifies as a target address an address mapped to a memory-mapped register that includes execution indicator 314. This avoids the need to consume coding space in the instruction set architecture for a dedicated instruction to trigger the translation table entry load / store operation. This approach can also be useful because it allows accelerator 300 to apply the translation table entry load / store operation to multiple addresses in an asynchronous or semi-asynchronous manner while other instructions are being processed in the background on processing circuitry 4, where other operations can continue. This therefore improves the throughput of processing operations. Software can program the relevant addresses in buffer 320, program base / size indicators 310, 312, set the "current index" in progress indicator 318 to 0, and set RUN=1 and FAULT=0. The software can then stop and work on something else, and later check the RUN bit to see if the process completed without identifying a fault.

[0117] When RUN=1, the accelerator 300 hardware may iterate as follows: 1. Read entry = [base + (8 * current index)] from ring buffer. Entry is VA or IPA. 2. Obtain the translation table entry address corresponding to the VA or IPA read from that entry. For example, look up the VA or IPA in the walk cache 29 and / or trigger a translation table walk using the current stage 1 or stage 2 translation table base address obtained from the TTBR or VTTBR_EL2 configuration to find the leaf entry and / or branch entry for that VA or IPA and perform a load, store, compare and swap, bit set, or bit clear operation on that entry. For example, this can be used to clear access flags 70, dirty bits 72, or other access tracking metadata. 3. Increment "current index". If this is the end of the ring buffer (e.g., if size parameter 312 is encoded as log(2) of the number of entries in the buffer, then this is determined based on whether current index >= 2^size), then set RUN=0 and abort. Otherwise, repeat from step 1 for the next entry in buffer 320.

[0118] If the walk encounters a fault or the leaf descriptor is invalid (which would generate a translation fault), the accelerator 300 hardware sets RUN=0 and FAULT=1 and aborts. This does not generate a data abort or other exception. Software checks the RUN / FAULT bits and the "current index" to check for progress / errors.

[0119] Once configured to execute, translation table entry load / store accelerator 300 may continue to execute even if there is a transition to a lower privilege state in processing circuit 4. For example, if accelerator 300 is configured to apply updates to various stage 2 translation table entries by software executing at EL2, accelerator 300 may continue to walk buffer 320 and apply translation table entry load / store operations to each address in the buffer, even if processing circuit 4 performs an exception return to EL1 or EL0. Later, when processing circuit 4 transitions back to EL2, software in EL2 may check execution / fault / progress indicators 314, 316, 318 to check progress and whether the operation was successful. This approach therefore means that translation table entry load / store operations may be performed asynchronously in the background of other instructions executing on processing circuit 4.

[0120] 13 is a flow diagram illustrating a method for performing a translation table entry load / store operation using the accelerator 300. In step 250, the accelerator 300 determines whether the run indicator 314 (set in a memory-mapped register) is set to a first state (e.g., RUN=1). If the run indicator is in a second state (RUN=0), the accelerator takes no action.

[0121] If it is determined that the execution indicator 314 is set to the first state, then in step 252, the accelerator determines the next buffer address to be read. The next buffer address is determined based on the base address 310 and the progress indicator 318 (e.g., by adding a multiple of the index provided by the progress indicator 318 to the base address 310). In step 254, the accelerator 300 controls the address translation circuit 28 to obtain at least one translation table entry address of at least one translation table entry used to translate the selected address read from the entry of the buffer 320 corresponding to the next buffer address. Thus, in step 254, a load operation is performed to load an address from the next buffer entry identified by the next buffer address, and the selected address read from that entry is then provided to the address translation circuit 28, which can use the selected address to trigger a lookup of the walk cache 29 and / or a translation table walk using the walk circuit 302.

[0122] In step 256, the accelerator 300 and / or the address translation circuit 28 determine whether an error condition is detected. For example, an error may be detected if a walk of the translation table structure does not find a valid translation table entry for the selected address, or if a leaf translation table entry is identified at the wrong level of the table structure. An error may also occur if a load into a buffer entry based on the next buffer address violates the access permissions for that address. If an error is detected, in step 258, the fault reporting register 316 is updated to indicate that a fault occurred and the cause of the fault. The accelerator 300 also clears the run indicator 314 to a second state (e.g., RUN=0).

[0123] If no error was detected in step 256, then in step 260, accelerator 300 performs a load / store operation on each of the one or more addresses returned as the at least one translation table entry address. The load / store may be any of the variants discussed above, such as a load, store, compare and swap, or bit set / clear variant. In the case of a load variant, when this is performed by accelerator 300, a second buffer (identified by a second base address) may be provided to be written to the translation table entry loaded based on the address identified in step 254. When one of the store / compare and swap / bit clear / bit swap variants is used, additional operands for these operations (e.g., store data, compare and swap value, or setting bit positions for the bit clear / swap operation) may be obtained from further structures in memory or may be encoded within the same buffer as buffer 320 used to provide the selected address. However, in some implementations, such an additional operand may not be required (e.g., if the accelerator 300 is dedicated to clearing the access flag 70 and / or the DBM 72, it may be implicit that the operation to be performed is an atomic operation to read the translation table entry, update the access flag 70 and the DBM 72 to a state indicating zero previous accesses, and write back the updated translation table entry, and therefore no explicit operand may be required).

[0124] In step 262, accelerator 300 increments progress indicator 318 (in a memory-mapped register) to reflect the success of the load / store operation on the current buffer entry, so that any further iterations of the translation table entry load / store are performed on the next entry. In step 264, accelerator 300 detects whether all valid addresses in buffer 320 have been processed based on progress indicator 318 and size indicator 312; if not, the method returns to step 250 to continue execution. The check for whether execution indicator 314 is set to the first state is repeated in each iteration of the loop, because software may choose to explicitly stop progress by accelerator 300 by clearing the execution indicator to the second state, even if all addresses have not yet been processed. If, in step 264, the accelerator 300 detects that all addresses in the buffer have been processed, then, in step 266, the running indicator 340 is cleared by hardware to a second state (e.g., RUN=0), and the accelerator then stops its operation and awaits reprogramming for a later instance of performing a translation table entry load / store operation.

[0125] simulator FIG. 14 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 techniques, it is also possible to provide an instruction execution environment according to the embodiments described herein implemented through the use of a computer program. Such computer programs are often referred to as simulators, insofar as they provide a software-based implementation of a hardware architecture. Various simulator computer programs include emulators, virtual machines, models, and binary translators, including dynamic binary translators. Typically, a simulator implementation may run on a host processor 1330, which optionally runs a host operating system 1320 and supports the simulator program 1310. In some arrangements, there may be multiple layers of simulation between the hardware and the provided instruction execution environment, and / or there may be multiple different instruction execution environments provided on the same host processor. Historically, powerful processors have been required to provide simulator implementations that run at reasonable speeds, but such an approach may be justified in certain situations, such as when it is desirable to execute code native to another processor for compatibility or reuse reasons. For example, a simulator implementation may provide an instruction execution environment with additional functionality not supported by the host processor hardware, or may provide an instruction execution environment typically associated with a different hardware architecture. An overview of simulation is given in "Some Efficient Architecture Simulation Techniques," Robert Bedichek, Winter 1990 USENIX Conference, pp. 53-63.

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

[0127] Simulator program 1310, which may be stored on a computer-readable storage medium (which may be a non-transitory medium), provides a program interface (an instruction execution environment) to target code 1300 (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 1310. Thus, program instructions of target code 1300, including the translation table entry load / store trigger instructions described above, may be executed from within an instruction execution environment using simulator program 1310, thereby enabling host computer 1330, which does not actually have the hardware capabilities of device 2 discussed above, to emulate these capabilities.

[0128] Thus, simulator program 1310 may have processing program logic 1312 that simulates the states of processing circuit 4 described above. For example, processing program logic 1312 may simulate execution state transformations in response to events occurring during simulated execution of target code 1300. Instruction decode program logic 1314 (which may be considered part of the processing program logic) decodes instructions of target code 1300 and maps these instructions to corresponding instructions in the native instruction set of host device 1330. Register emulation program logic 1316 maps register accesses requested by the target code to accesses to corresponding data structures maintained on the host hardware of host device 1330, such as by accessing registers of host device 1330 or data in memory 1332. The memory manager logic 1318 has address translation program logic 1319 for implementing address translation, page table walks, and access control checks in a manner corresponding to the MMU 28 described in the hardware implementation embodiment above, but with the additional functionality of mapping simulated physical addresses obtained by address translation based on translation tables defined for the target code 1300 to host virtual addresses used to access host memory 1332. These host virtual addresses may 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 what is controlled by the simulator program 1310).

[0129] Thus, by supporting within simulator program 1310 translation table entry load / store operations with the same functionality as discussed above, target code 1300 written for a device 2 that supports this operation in hardware can be presented using the same architectural interface (e.g., CPU instructions in an instruction set architecture and / or an accelerator programming interface as shown in FIG. 12) that would be available in hardware device 2, and thereby can also be executed on a host device 1330 that does not have this hardware.

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

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

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

Claims

1. 1. An apparatus comprising: processing circuitry for processing instructions; an address translation circuit for translating between an input address space and an output address space based on address mapping information obtained from a translation table structure containing translation table entries; a translation table entry load / store circuit for performing, in response to a translation table entry load / store trigger instruction processed by the processing circuit, a translation table entry load / store operation for at least one target translation table entry address selected depending on software-defined address information identifying a selected address in the input address space, wherein each target translation table entry address includes an address of a leaf translation table entry that provides the address mapping information for translating the selected address from the input address space to the output address space, or an address of a branch translation table entry that is traversed in a translation table walk operation to obtain the leaf translation table entry that provides the address mapping information for translating the selected address; and wherein, for at least one variant of the translation table entry load / store operation, the translation table entry load / store operation supports, for a given target translation table entry of the at least one target translation table entry, clearing access tracking metadata of the given target translation table entry from a first state to a second state, the first state indicating that at least one load / store access has occurred to a corresponding region of an input address space, and the second state indicating that no load / store access has occurred to the corresponding region of an input address space.

2. 2. The apparatus of claim 1, wherein in response to the translation table entry load / store trigger instruction, the translation table entry load / store circuitry is configured to control the address translation circuitry to identify the at least one target translation table entry address based on the selected address.

3. 3. The apparatus of claim 1, wherein for at least one variant of the translation table entry load / store operation, the at least one translation table entry comprises the leaf translation table entry.

4. For at least one variant of the translation table entry load / store operation, the translation table entry load / store operation: the address mapping information for converting the selected address; access permission information indicating what types of memory access operations are permitted; 4. The apparatus of claim 3, further comprising: a memory attribute information for controlling handling of memory accesses to the selected address; and a leaf translation table entry for modifying at least one of the following:

5. 5. The apparatus of claim 1, wherein for at least one variant of the translation table entry load / store operation, the at least one translation table entry comprises a translation table entry of a specified level of the translation table structure, regardless of whether the translation table entry is the leaf translation table entry or the branch translation table entry.

6. 6. The apparatus of claim 1, wherein for at least one variant of the translation table entry load / store operation, the at least one translation table entry includes the leaf translation table entry and each branch translation table entry that is traversed in the translation table walk operation to obtain the leaf translation table entry.

7. For at least one variant of the translation table entry load / store operation, the at least one translation table entry: If the leaf translation table entry is validly defined for the selected address, the leaf translation table entry and and if no valid leaf translation table entry is defined for the selected address, a final valid branch translation table entry reached in traversal of the translation table structure for the selected address.

8. The at least one variant of the translation table entry load / store operation that supports clearing of the access tracking metadata is: a store variant of the translation table entry load / store operation for updating the given target translation table entry with an updated value specified by a store data operand; a swap variant of the translation table entry load / store operation to update the given target translation table entry with an updated value specified by a swap data operand and to load either the pre-update value of the given target translation table entry or the updated value of the given target translation table entry into a software accessible location; an atomic compare and swap variant of the translation table entry load / store operation for determining whether a result of a comparison between the given translation table entry and a comparison operand satisfies a comparison condition, and for updating the given target translation table entry based on a swap operand of the compare and swap variant in response to determining that the result of the comparison satisfies the comparison condition; and 8. The apparatus of claim 1, further comprising at least one of: an atomic bit update variant of the translation table entry load / store operation for setting or clearing at least one specified bit of the given translation table entry, the specified bit being identified by a bit selection operand.

9. 9. The apparatus of claim 1, wherein the translation table entry load / store circuitry is configured to support a load variant of the translation table entry load / store operation to load the at least one target translation table entry into at least one software accessible register.

10. In response to the translation table entry load / store trigger instruction, the translation table entry load / store circuitry is configured to perform an error reporting action in response to identifying that an error condition has occurred, the error condition being: that no valid leaf translation table entry is defined for the selected address; and 10. The apparatus of claim 1, wherein for the selected address, a valid leaf translation table entry is defined at a level of the translation table structure other than the expected level.

11. In response to the translation table entry load / store trigger instruction, the translation table entry load / store circuitry is configured to update at least one software accessible register with syndrome information, the syndrome information comprising: the level of the translation table structure at which a valid leaf translation table entry is defined for the selected address; and 11. The apparatus of claim 1, wherein the apparatus specifies at least one of the information specified by the at least one target translation table entry.

12. 12. The apparatus of claim 1, wherein the translation table entry load / store trigger instruction specifies the selected address as an operand of the translation table entry load / store trigger instruction, and the translation table entry load / store trigger instruction has an instruction opcode different from that of the load / store instruction for triggering a load / store operation to be performed on the address specified as the operand of the load / store instruction.

13. 12. The apparatus of claim 1, wherein the translation table entry load / store trigger instruction includes a store instruction that specifies a predetermined translation table entry load / store trigger address as a store address operand, for which a store to the predetermined translation table entry load / store trigger address triggers the translation table entry load / store circuitry to perform the translation table entry load / store operation.

14. the translation table entry load / store circuitry is configured to obtain the software-defined address information from a memory-based data structure accessed based on a software-programmable base address; 14. The apparatus of claim 13, wherein when the software-defined address information specifies multiple selected addresses, the translation table entry load / store circuitry is configured to perform the translation table entry load / store operation for each of the selected addresses in response to a single instance of executing the store instruction that functions as the translation table entry load / store trigger instruction.

15. 15. The apparatus of claim 14, wherein the translation table entry load / store circuitry is configured to update a software accessible location to specify a progress indicator that indicates progress made in performing the translation table entry load / store operations on the plurality of selected addresses.

16. when the translation table entry load / store circuitry is triggered to perform the translation table entry load / store operations on the plurality of selected addresses in response to the store instruction being processed by the processing circuitry in a more privileged execution state, and the processing circuitry subsequently switches to a less privileged execution state; 16. The apparatus of claim 14 or 15, wherein the translation table entry load / store circuitry is capable of continuing to process remaining addresses of the plurality of selected addresses after the switch to the less privileged execution state.

17. 17. The apparatus of claim 1, wherein for at least one variant of the translation table entry load / store operation, the software-defined address information specifies a range of addresses, and the translation table entry load / store circuitry is configured to perform the translation table entry load / store operation for each address in the range as the selected address.

18. the address translation circuitry is configured to support two-stage address translation between the virtual address space and the physical address space based on a first translation table structure providing address mapping information for translating between a virtual address space and an intermediate address space, and a second translation table structure providing address mapping information for translating between the intermediate address space and a physical address space; the translation table entry load / store circuit a variant of the first stage of the translation table entry load / store operation, wherein the selected address comprises a specified virtual address of the virtual address space and the at least one target translation table entry comprises at least one translation table entry of the first translation table structure; and a second stage variant of the translation table entry load / store operation, wherein the selected address comprises a specified intermediate address in the intermediate address space and the at least one target translation table entry comprises at least one translation table entry of the second translation table structure.

19. 1. A method comprising: processing instructions using processing circuitry; using an address translation circuit to translate between an input address space and an output address space based on address mapping information obtained from a translation table structure including translation table entries; performing, in response to the processing circuit processing a translation table entry load / store trigger instruction, a translation table entry load / store operation for at least one target translation table entry address selected depending on software-defined address information identifying a selected address in the input address space, wherein each target translation table entry address includes an address of a leaf translation table entry that provides the address mapping information for translating the selected address from the input address space to the output address space, or an address of a branch translation table entry that is traversed in a translation table walk operation to obtain the leaf translation table entry that provides the address mapping information for translating the selected address; and wherein for at least one variant of the translation table entry load / store operation, the translation table entry load / store operation supports, for a given target translation table entry of the at least one target translation table entry, clearing access tracking metadata of the given target translation table entry from a first state to a second state, the first state indicating that at least one load / store access has occurred to a corresponding region of an input address space, and the second state indicating that no load / store access has occurred to the corresponding region of an input address space.

20. 1. A computer program comprising instructions for controlling a host data processing apparatus to provide an instruction execution environment for executing target code, said computer program comprising: address translation program logic for translating between an input address space and an output address space based on address mapping information obtained from a translation table structure containing translation table entries; translation table entry load / store program logic for performing, in response to a translation table entry load / store trigger instruction of the target code, a translation table entry load / store operation for at least one target translation table entry address selected depending on software-defined address information identifying a selected address in the input address space, wherein each target translation table entry address includes an address of a leaf translation table entry that provides the address mapping information for translating the selected address from the input address space to the output address space, or an address of a branch translation table entry that is traversed in a translation table walk operation to obtain the leaf translation table entry that provides the address mapping information for translating the selected address; 10. The computer program product of claim 9, wherein for at least one variant of the translation table entry load / store operation, the translation table entry load / store operation supports, for a given target translation table entry of the at least one target translation table entry, clearing access tracking metadata of the given target translation table entry from a first state to a second state, the first state indicating that at least one load / store access has occurred to a corresponding region of an input address space, and the second state indicating that no load / store access has occurred to the corresponding region of the input address space.

21. A storage medium storing a computer program according to claim 20.

Images