Translation lookaside buffer miss

Abstract

This invention describes a type of Translation Backing Buffer (TLB) fail instruction that specifically targets a first type of TLB storing a combination of Stage 1 and Stage 2 translated data entries, and is configured to ignore TLB fail commands that fail based on a first set of one or more fail conditions, including a matching address-based fail condition depending on an intermediate address. A second type of TLB, other than this first type, ignores the fail command triggered by the first type of TLB fail instruction. This approach helps limit the performance impact of Stage 2 failes in systems supporting combined Stage 1 and Stage 2 TLBs that cannot be failed by intermediate address.

Description

Technical Field

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

[0002] Data processing systems can support address translation, where a virtual address specified by an instruction is translated into a physical address that identifies a location in the memory system. Some systems support two-stage address translation, where the mapping from virtual to physical addresses depends on stage 1 translation data used to map virtual addresses to intermediate addresses and stage 2 translation data used to map intermediate addresses to physical addresses. Two-stage address translation can be used in systems that support virtualization because it allows multiple operating systems or virtual machines to coexist on the same physical platform, where each virtual machine or operating system uses a corresponding set of stage 1 translation data to define its own virtual address-to-intermediate address mapping. Each virtual machine or operating system can function in the same way as if it were the only virtual machine or operating system running on the system, as if the intermediate address were actually a physical address. However, the hypervisor controlling different virtual machines or operating systems can define stage 2 translation data that maps a set of intermediate addresses used by a given operating system or virtual machine to physical addresses that actually refer to locations in the memory system (different sets of stage 2 translation data can be defined for different operating systems or virtual machines). Summary of the Invention

[0003] At least some examples provide an apparatus comprising:

[0004] Processing circuitry, the processing circuitry being configured to perform data processing in response to instructions; and

[0005] An address translation circuit performs two-stage address translation to translate a virtual address into a physical address. The virtual-to-physical address mapping depends on stage 1 translation data used to map the virtual address to an intermediate address and stage 2 translation data used to map the intermediate address to the physical address.

[0006] In response to a first type of translation back buffer (TLB) fail instruction for a specified target intermediate address, the processing circuitry is configured to issue a first TLB fail command to at least one TLB used to store translation entries derived from at least one of stage 1 translation data and stage 2 translation data. This first TLB fail command requests the at least one TLB to fail translation entries that satisfy a first set of one or more fail conditions. The first set includes intermediate address-based conditions satisfied when the translation entry corresponds to a target intermediate address.

[0007] In response to a second type of TLB failure command, the processing circuit is configured to issue a second TLB failure command, which requests:

[0008] If the at least one TLB includes a first type TLB, then the first type TLB shall invalidate one or more translation entries that satisfy one or more failure conditions of a second set, wherein the first type TLB is a TLB configured to ignore a first TLB failure command and configured to store the type of a combination of stage 1 and stage 2 entries depending on both stage 1 translation data and stage 2 translation data; and

[0009] If the at least one TLB includes a second type of TLB in addition to the first type of TLB, then the second type of TLB shall retain one or more translation entries that satisfy one or more failure conditions of the second set.

[0010] At least some examples provide an apparatus comprising:

[0011] A means for performing data processing in response to instructions; and

[0012] A means for translating a virtual address to a physical address using two-stage address translation, wherein the virtual address-to-physical address mapping depends on stage 1 translation data for mapping the virtual address to an intermediate address and stage 2 translation data for mapping the intermediate address to a physical address; wherein:

[0013] In response to a first type of translation back buffer (TLB) fail instruction for a specified target intermediate address, a means for performing data processing is configured to issue a first TLB fail command to at least one TLB storing translation entries derived from at least one of stage 1 translation data and stage 2 translation data. The first TLB fail command requests the at least one TLB to fail translation entries that satisfy a first set of one or more fail conditions, the first set including intermediate address-based conditions satisfied when the translation entry corresponds to a target intermediate address; and

[0014] In response to a second type of TLB failure command, the means for data processing is configured to issue a second TLB failure command, which requests:

[0015] If the at least one TLB includes a first type TLB, then the first type TLB shall invalidate one or more translation entries that satisfy one or more failure conditions of a second set, wherein the first type TLB is a TLB configured to ignore a first TLB failure command and configured to store the type of a combination of stage 1 and stage 2 entries depending on both stage 1 translation data and stage 2 translation data; and

[0016] If the at least one TLB includes a second type of TLB in addition to the first type of TLB, then the second type of TLB shall retain one or more translation entries that satisfy one or more failure conditions of the second set.

[0017] At least some examples provide a method for an apparatus comprising: processing circuitry for performing data processing in response to an instruction; and address translation circuitry for performing two-stage address translation to translate a virtual address to a physical address, wherein the mapping from virtual address to physical address depends on stage 1 translation data for mapping the virtual address to an intermediate address and stage 2 translation data for mapping the intermediate address to a physical address.

[0018] The method includes:

[0019] In response to a first type of translation back buffer (TLB) fail instruction for a specified target intermediate address, a first TLB fail command is issued to at least one TLB used to store translation entries derived from at least one of stage 1 translation data and stage 2 translation data. This first TLB fail command requests the at least one TLB to fail translation entries that satisfy a first set of one or more fail conditions. The first set includes intermediate address-based conditions satisfied when the translation entry corresponds to a target intermediate address.

[0020] In response to a Type 2 TLB fail instruction, a second TLB fail command is issued, which requests:

[0021] If the at least one TLB includes a first type TLB, then the first type TLB shall invalidate one or more translation entries that satisfy one or more failure conditions of a second set, wherein the first type TLB is a TLB configured to ignore a first TLB failure command and configured to store the type of a combination of stage 1 and stage 2 entries depending on both stage 1 translation data and stage 2 translation data; and

[0022] If the at least one TLB includes a second type of TLB in addition to the first type of TLB, then the second type of TLB shall retain one or more translation entries that satisfy one or more failure conditions of the second set. Attached Figure Description

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

[0024] Figure 1 An example of a data processing system with one or more translation backup buffers is illustrated schematically;

[0025] Figure 2Different types of translation backup buffers are illustrated schematically;

[0026] Figure 3 It is a table summarizing the properties of different types of translated backup buffer failure instructions;

[0027] Figure 4 This schematically illustrates an example of tracking failure conditions from a series of translated back buffer failure instructions within a trace structure, such that a single traversal of the translated back buffer can apply all corresponding sets of failure conditions to that series of instructions; and

[0028] Figure 5 This is a flowchart illustrating a method for handling translated backup buffer failure instructions. Detailed Implementation

[0029] In systems with address translation circuitry supporting two-stage address translation, stage 1 and stage 2 translated data can ultimately be stored within page table structures stored within the memory system. However, accessing those page table structures can be slow because multiple memory accesses may be required during page table traversal across multiple levels within the page table structure, and therefore a translation lookup buffer (TLB) is typically provided to cache translation entries that depend on either stage 1 or stage 2 translated data from the page table structure. The TLB can be provided locally at the point where the address translation circuitry resides and can be accessed much faster than the page table structure itself. The TLB caches translation entries for recently accessed or anticipated future address subsets, which helps improve performance.

[0030] However, when the page table structure in memory is updated by software, this means that some obsolete translated entries can still reside in the TLB. Therefore, the processing circuitry used to perform data processing in response to instructions can support at least one type of TLB fail instruction, which triggers the processing circuitry to issue a fail command to at least one TLB to request translated entries that satisfy a given set of fail conditions to be fail from the TLB. Different types of TLB fail instructions can impose different fail conditions.

[0031] The first type of TLB failure instruction can specify a target intermediate address, and in response to the first type of TLB failure instruction, the processing circuitry can issue a first TLB failure command to at least one TLB. The first TLB failure command can request at least one TLB to fail translation entries that satisfy a first set of one or more failure conditions, which includes at least an intermediate address-based condition satisfied when the translation entry corresponds to the target intermediate address specified by the first type of TLB failure instruction. This instruction can be used to handle scenarios where address mappings of certain addresses within the software update stage 2 translation data exist. By providing a type of instruction that specifies a particular target intermediate address to which a TLB entry will be failed, it means that not all stage 2 translation entries need to be failed, thus limiting the performance impact of the failure.

[0032] However, TLBs can be implemented differently in systems where the address translation circuitry supports two-stage address translation, and not all types of TLBs may be able to look up their translated entries based on the target intermediate address. Therefore, a first-type TLB invalidation instruction may not guarantee that all TLBs will invalidate any entries that depend on the stage 2 translated data associated with the target intermediate address. For example, a TLB could be a type that stores combined stage 1 and stage 2 entries that depend on both stage 1 and stage 2 translated data. Such combined stage 1 and stage 2 entries can directly map virtual addresses to physical addresses without specifying a corresponding intermediate address, and therefore may not be able to look up such entries based on the intermediate address, even if such entries would need to be invalidated when the stage 2 translated data associated with the intermediate address changes, since the mapping from virtual address to physical address does indeed depend on the stage 2 translated data. Therefore, this first-type TLB can be configured to ignore the first TLB invalidation command.

[0033] To handle this situation, an alternative approach could be to issue a second TLB fail instruction, after issuing a first type of TLB fail instruction that fails by the target intermediate address, which simply specifies that all TLB entries satisfying a certain set of fail conditions should be failed. The fail conditions for this type of TLB fail instruction do not depend on the address at all. For example, this could be an instruction specifying that any entry dependent on stage 1 translated data associated with a particular translation context should be failed. While this might successfully implement a first type of TLB to fail any combined stage 1 and 2 entries that depend on changes to the relevant stage 2 translated data for a target intermediate address specified by the previous first type of TLB fail instruction, it has the disadvantage of also failing many other TLB entries that depend on stage 1 translated data, even if they do not actually involve addresses that change in stage 2 translated data. This over-failure does not affect functional correctness but can have a performance impact because memory accesses relying on unnecessarily failed translated entries will then need to wait for the relevant translated data to be re-fetched from the page table structure, which is slow.

[0034] For some TLBs, such over-failures may not be considered a problem. For example, for TLBs provided within a central processing unit (CPU), it can be assumed that the performance impact of over-failures when a phase 2 failure is required may be acceptable, given that phase 2 failures are likely to be extremely rare. This is because for such CPUs, it is generally assumed that occasional poor performance is permissible if the average performance over a period of time is acceptable, since some poor performance of memory accesses can be compensated for by other accesses with much faster performance.

[0035] However, the inventors recognize that this assumption is not true for all devices using TLBs. For some devices, a more significant criterion than average performance might be worst-case performance for any memory access implementation. For example, for a display controller that needs to process each frame of image data fast enough to be ready for display at the end of a refresh period for refreshing the display, sometimes exceeding average performance might be slightly beneficial, since in any case, the display of the frame would have to wait until the next refresh period ends. However, in the event of worst-case performance, if this worst-case performance is too slow, it could lead to a cycle in which the display is black because the image data is not processed fast enough for display before the refresh period ends. For such devices, even if stage 2 failures are minimal, the abrupt over-failure of stage 1 TLB entries caused by the aforementioned alternative methods could become a significant problem.

[0036] In the techniques discussed below, in addition to the first type of TLB fail instruction that fails based on the target intermediate address, a second type of TLB fail instruction is also provided. In response to the second type of TLB fail instruction, the processing circuit issues a second TLB fail command that requests:

[0037] If at least one TLB includes a first-type TLB, then that first-type TLB should invalidate one or more translation entries that satisfy one or more failure conditions of the second set. A first-type TLB is a TLB that ignores the first TLB failure command and stores the type of both stage 1 and stage 2 translation data depending on the combination of stage 1 and stage 2 translation data; and

[0038] • If at least one TLB includes a second type of TLB in addition to the first type of TLB, then the second type of TLB shall retain one or more translation entries that satisfy one or more failure conditions of the second group.

[0039] Therefore, a type of TLB failure instruction is provided that targets a specific first-type TLB that stores the combined stage 1 and 2 entries but ignores the first-type TLB failure command because it cannot be queried by the target intermediate address. Thus, for any first-type TLB, the second-type TLB failure instruction requires the first-type TLB to fail any entry that matches one or more failure conditions of the second group. However, for second-type TLBs other than the first type, the second-type TLB may retain its translated entries after receiving the second TLB failure command, even if those translated entries do indeed satisfy one or more failure conditions of the second group.

[0040] Therefore, those TLBs that can comply with Type 1 TLB failure instructions or store split phase 1 and phase 2 translated data and thus can precisely handle phase 2 failures without over-failing other entries unrelated to the specified target intermediate address can ignore Type 2 TLB failure instructions, and thus this limits the performance impact of ensuring that all entries affected by the update of phase 2 translated data are failed. It is a Type 1 TLB that only cannot comply with Type 1 TLB failure instructions but still has a combination of phase 1 and phase 2 entries that must fail based on one or more failure conditions of the second set.

[0041] Similarly, support for Type 2 TLB fail instructions also gives system designers the flexibility to change the type of TLB provided in a particular device, balancing whether to choose a less area-efficient TLB design that provides better performance on a Stage 2 fail or to prefer a more area-efficient TLB even if it results in worse performance on a Stage 2 fail. For example, a TLB within a memory management unit intended for use with a display controller or other performance-sensitive device could implement a TLB of the type that complies with Type 1 TLB fail instructions, and therefore it would not need to fail in response to Type 2 TLB fail instructions, thus preserving performance in worst-case scenarios. However, a TLB within a memory management unit for a CPU could optionally implement a Type 1 TLB that does not comply with Type 1 fail commands, but for this Type 1 TLB, the performance impact of allowing a potential over-failure in response to a Type 2 TLB fail command might be acceptable, where the advantage of this approach is that the Type 1 TLB might be more area-efficient because it does not require consuming circuit area and power budget on logic circuitry capable of detecting which combined Stage 1 and 2 entries correspond to a given target intermediate address. Therefore, providing architectural support for both Type 1 and Type 2 TLB fail instructions in the processor has the benefit of giving system designers much greater flexibility in their design choices for their TLBs.

[0042] Different types of TLB fail instructions can be distinguished in various ways. In some implementations, first-type TLB fail instructions may have different instruction opcodes. Alternatively, different types of TLB fail instructions may have the same opcode, but may specify another parameter that identifies the type of TLB fail instruction, or a set of two or more parameters that jointly identify the type. Another option is that the instruction codes for first-type and second-type TLB fail instructions are virtually identical, but when these instructions are decoded, the processing circuitry refers to control data in a control register that identifies the specific type of TLB fail instruction intended to be executed. This control data may be set by an earlier instruction executed before the TLB fail instruction.

[0043] The first type of TLB that serves as the target of the second TLB failure command can be a TLB of a type that cannot determine whether a given combination of stage 1 and 2 entries corresponds to the target intermediate address.

[0044] On the other hand, the second type of TLB that ignores the second TLB failure command can be at least one of the following: a stage 1 TLB only, whose translation entries depend on stage 1 translation data and are independent of stage 2 translation data; a stage 2 TLB only, whose translation entries depend on stage 2 translation data and are independent of stage 1 translation data; or a combination of stage 1 and 2 TLBs, which are configured to store the combined stage 1 and 2 entries, and which are capable of determining whether the combined stage 1 and 2 entries correspond to a target intermediate address.

[0045] For a stage 1 TLB only, the second type of TLB invalidation command can be ignored because the second type of TLB invalidation instruction is expected to invalidate stage 2 translated entries, and since the stage 1 TLB only does not store any entries that depend on the stage 2 translated data, it does not need to comply with the second TLB invalidation command. On the other hand, for stage 2 TLB only, or for combined stage 1 and 2 TLBs that can determine whether a combined entry corresponds to a target intermediate address, these TLBs do not need to comply with the second TLB invalidation command because they are already able to invalidate any desired entries corresponding to the target intermediate address in response to the first type of TLB invalidation instruction.

[0046] Therefore, in general, system designers can design any combination of Stage 1 and Stage 2 TLBs as either Type 1 or Type 2, such that any combination of TLBs will respond to either a Type 1 TLB failure instruction (for Type 2 TLBs) or a Type 2 TLB failure instruction (for Type 1 TLBs). In either case, a sequence of instructions including at least one Type 1 TLB failure instruction and one Type 2 TLB failure instruction is then sufficient to ensure that all translated entries dependent on the updated Stage 2 translated data are invalidated.

[0047] For a Type 2 TLB failure instruction, the second set of one or more failure conditions may include at least one context-based condition satisfied by a translation entry whose translation context identifier matches at least one target translation context identifier. For example, a translation entry may specify a translation context identifier that can be used to distinguish page table data from different groups used by different software processes, ensuring that an entry from one process is not found when access is made from another process. For example, a translation context identifier may be one or more of the following: virtual machine identifier, security state identifier, and exception level identifier. Therefore, a Type 2 TLB failure instruction may specify a combination of one or more translation context identifiers for which the entry will fail. The specified translation context identifier may be defined by the operand specified by the Type 2 TLB failure instruction, or it may depend on the current operating state of the processing circuitry when the Type 2 TLB failure instruction is executed (in which case, it may be implied that the specified translation context identifier of the Type 2 TLB failure instruction is a translation context identifier related to the current operating state of the processing circuitry, rather than using an explicit identifier in the instruction's operands). Regardless of which of these options is used, by including context-based conditions in the second set of one or more failure conditions in the second type of TLB failure instructions, it means that the potential performance impact of over-failure of an entry (when attempting to ensure that a stage 2 failure reaches all affected entries) is limited to those entries associated with the relevant translation context that updates the stage 2 translation data.

[0048] The second set of one or more failure conditions may not include any address-based conditions. Therefore, checking whether a translated entry in a given TLB satisfies the second set of one or more failure conditions can be independent of the address field used to specify the virtual or intermediate address within the TLB. This is because second-type TLB failure instructions are designed to capture those TLBs that cannot perform address-based failure queries in response to first-type TLB failure instructions and therefore cannot identify the relevant TLB entry to be failed by address. Conversely, full capture failures may be performed, which may be limited by other parameters (such as the translation context) but are independent of addresses.

[0049] On the other hand, for a Type 1 TLB fail instruction, the first set of one or more fail conditions includes at least an address-based condition based on the target intermediate address, as discussed above. However, the first set of one or more fail conditions can also be extended to include at least one context-based condition satisfied by a translation entry whose translation context identifier, specified by the translation entry, matches at least one target translation context identifier. The translation context identifier can be any type of translation context identifier discussed above and can be specified by the operand of the instruction or implicitly determined based on the current operating state of the processing circuitry when executing a Type 1 TLB fail instruction.

[0050] It should be understood that for both Type 1 and Type 2 TLB failure instructions, the corresponding first and second set of failure conditions can also be extended to include other conditions. Furthermore, for each of these types of TLB failure instructions, multiple variants of the instruction with different sets of failure conditions can be provided.

[0051] In addition to the first and second type TLB fail instructions discussed above, the processing circuitry may also respond to a third type TLB fail instruction that controls the processing circuitry to issue a third TLB fail command. This third TLB fail command requests at least one TLB to fail all translation entries that depend on stage 1 translated data and specify at least one translation context identifier that matches at least one target translation identifier. Similarly, for the third type TLB fail instruction, the fail condition may be address-independent. Full capture TLB failes, such as failing all stage 1 translated data associated with a specific group of one or more translation context identifiers, may be supported for the purpose of supporting stage 1 failes performed when updating the stage 1 page table of a given translation context, and for supporting legacy code that may have been written to perform full capture failes by translation context identifier following the first type TLB fail instruction, so as to ensure that all stage 2 related entries for a given intermediate address are failed even in TLBs that do not support lookups by intermediate address. However, for newer code written with second-type TLB invalidation instructions, it is not necessary to use third-type TLB invalidation instructions, and this will tend to improve performance by avoiding over-invalidation in only stage 1 TLB or in a combination of stage 1 and 2 TLBs that can be looked up by intermediate address.

[0052] As described above, one form of the second type of TLB can be an intermediate address tracking combined stage 1 and 2 TLB, which stores combined stage 1 and 2 entries and is capable of determining whether combined stage 1 and 2 entries correspond to a target intermediate address. For example, each translation entry in the intermediate address tracking combined stage 1 and 2 TLB can specify both the virtual-to-physical address mapping and the corresponding intermediate address. For example, each entry can have fields for all virtual, intermediate, and physical addresses. Therefore, although such a TLB will be able to directly map a virtual address to a physical address in response to a translation request specifying a virtual address without performing a second lookup in the stage 2 TLB from intermediate address to physical address, it can also query its entries based on the intermediate address and thus comply with first type TLB invalidation commands.

[0053] This intermediate address tracking combination stage 1 and 2 TLBs may be able to comply with the first failure command in different ways. A relatively simple approach is that each first TLB failure command triggers the associated failure of entries that satisfy the first set of failure conditions upon receipt of the first TLB failure command itself. Therefore, each time a first TLB failure command with a specified intermediate address is received, intermediate address tracking combination stage 1 and 2 TLBs can iterate through each of their translated entries to check if each entry satisfies the first set of failure conditions and fail those entries that do.

[0054] However, this can be relatively common for several first TLB fail instructions that specify different intermediate addresses to be failed and are to be executed sequentially. If each first-type TLB fail instruction causes the intermediate address tracking combination stages 1 and 2 TLB to perform a separate traversal of its entries to find the entries that satisfy the first set of fail conditions for the corresponding instruction, this can have a relatively significant impact on performance and power consumption because there are multiple traversals of the TLB in response to the entire TLB fail instruction sequence.

[0055] Another approach is that intermediate address tracking combination stages 1 and 2 of the TLB can comply with the first failure command by executing the failure with a delay, since it is expected that a second type of TLB failure command may eventually follow the multiple failure commands of the first type. In this case, intermediate address tracking combination stages 1 and 2 of the TLB can then update the tracking information based on a first set of failure conditions specified by the first TLB failure command in response to the first TLB failure command. If there are multiple first TLB failure commands, then each time a first TLB failure command is received, the tracking information can be further updated based on the first set of failure instructions for the most recently received TLB failure command, such that over time, the tracking information tracks the group of first failure conditions for each of the received first TLB failure commands. Then, in response to the second TLB failure command, although the command itself indicates a failure that does not need to be complied with by the intermediate address tracking combination stages 1 and 2 (because the second TLB failure command is intended to target those combination stages 1 and 2 that cannot comply with the first TLB failure command), the intermediate address tracking combination stages 1 and 2 may still use the second TLB failure command as a signal that the sequence of first TLB failure commands has been completed, and then respond by triggering failures in their combination translation entries that satisfy one or more of the set of traced failure conditions represented by the trace information. By deferring the actual failures indicated by the series of first TLB failure commands to be executed upon receiving the second TLB failure command, this allows the failures required by the first TLB failure commands to be implemented only by a single traversal of the translation entries of the intermediate address tracking combination stages 1 and 2, which checks each entry as it is traversed whether the entry satisfies any set of failure conditions represented by the traced failure conditions in the trace information. This eliminates multiple redundant traversals of the TLB, and thereby saves power and improves performance by making the TLB available for subsequent lookups more quickly.

[0056] Therefore, as mentioned above, when a certain type of TLB is able to comply with a first type of TLB failure command, it does not necessarily mean that it must directly trigger its failure in response to that command, because some types of TLB may be able to store tracking information acting on the failure and postpone it until a second TLB failure command is received later.

[0057] In some examples, the trace structure may have a capacity limit even if no second TLB failure command is received, and therefore the failure represented by the trace structure may be applied to the TLB if the number of first TLB failure commands received exceeds a threshold.

[0058] The tracing information used for this method can be maintained in different ways. In some cases, the tracing information can precisely track the first set of failure conditions specified by a series of one or more first TLB failure commands. For example, the tracing information can maintain an address list tracking all target intermediate addresses specified by each of the first TLB failure commands in a series. The tracing information can also track one or more translation context identifiers associated with those first TLB failure commands. It is generally expected that in the series of one or more first TLB failure commands preceding the second TLB failure command, all of those first TLB failure commands should have failure conditions specifying the same set of one or more translation context identifiers, so the tracing information may not need to record more than one set of translation context identifiers. By precisely tracking the failure conditions of a series of first TLB failure commands, this ensures that entries that would not satisfy the first set of failure conditions specified by any of the received first TLB failure commands are not over-failed.

[0059] In another approach, the trace information may include a filter representation that does not precisely trace the first set of failure conditions of a series of one or more TLB failure commands. This means that translation entries satisfying a set of traced failure conditions are allowed to include at least one translation entry that does not satisfy the first set of failure conditions specified by any of the received series of one or more first TLB failure commands for updating the trace information. While this allows for some over-failure, it allows for a more efficient circuit implementation for the logic used to store and update the trace information. For example, a Bloom filter can be used to trace the intermediate address of each of the received first TLB failure commands, allowing for the use of fewer trace information bits to record the address.

[0060] The Type 1 and Type 2 TLB fail instructions defined above can be architectural instructions supported by the instruction set architecture implemented for the processing circuitry. These instructions can be native instructions supported by an instruction decoder that decodes instructions to be processed by the processing circuitry. It should be understood that the processing circuitry supports this architecture so that Type 1 and Type 2 fail instructions can be executed even in systems that do not actually have any Type 2 TLBs. The same software can be executed across a range of system designs using different types of TLBs, and therefore it is useful for the processing circuitry to support a specific type of TLB fail instruction to ensure that it functions correctly on systems with Type 1 TLBs or on systems without Type 1 TLBs. Therefore, the presence of at least one Type 1 TLB is not necessary for implementing a processor with processing circuitry that supports the Type 1 and Type 2 TLB fail instructions discussed above. Similarly, the presence of a specific Type 2 TLB is not required. In general, a system can have a range of types of TLBs, and the specific type chosen can be a design choice by the system designer. Architectural support for Type 1 and Type 2 TLB fail instructions allows system designers the flexibility to choose the type of TLB based on the performance and area requirements of a given device or memory management unit using the TLB.

[0061] Figure 1 An example of a data processing system 2 is schematically shown, having at least one CPU (Central Processing Unit) 4, which has an instruction decoder 6 for decoding program instructions and processing circuitry 8 controlled to perform processing operations in response to instructions decoded by the instruction decoder 6. The CPU 4 has a cache 10 for caching data from memory for faster CPU access and a memory management unit (MMU) 12 serving as address translation circuitry to translate virtual addresses specified by instructions executed by the CPU 4 into physical addresses identifying locations within the memory system. The MMU may have at least one TLB 14 for storing translated entries dependent on page table data from a page table structure stored in the memory system. The page table structure defines the address mapping between virtual and physical addresses and may also define memory access permissions, which may define whether certain software processes executing on the CPU 4 are allowed to access certain addresses. MMU 12 supports two-stage address translation, where the mapping from virtual to physical addresses depends on stage 1 address translation data that maps virtual addresses (VA) to intermediate physical addresses (IPA) and stage 2 translation data that maps IPAs to physical addresses (PA). Stage 1 address translation data can be configured by the operating system or virtual machine. Stage 2 translation data can be configured by the hypervisor.

[0062] CPU 4 is an example of a master device capable of executing program instructions. Although Figure 1 Only one such master device is shown, but it should be understood that System 2 may have two or more such devices, which may include additional CPUs or may include other types of instruction execution devices (such as graphics processing units (GPUs)).

[0063] In addition to the CPU 4 or other instruction-executing devices with their own internal MMU 12, the system may also include a master device 20, which may not have an internal MMU and is therefore used to access memory and provide address translation functionality. Such a device may communicate with the rest of the system via a system memory management unit (SMMU) 22, which includes address translation circuitry that controls address translation and memory access based on translation data defined in a page table structure in memory. Similarly, the SMMU 22 may have one or more TLBs 24, which have similar functionality to the TLB 14 within the CPU 4's MMU 12. Devices 20 accessing memory via the SMMU 22 may include cached devices (including an internal cache 26) and uncached devices (those without any cache). For example, device 20 may include a display controller for controlling the display of image frames on a monitor, a network controller for controlling the input or output of data via a network, and a hardware accelerator for performing certain specialized processing functions in a more efficient manner than software that can be executed on a general-purpose processor such as the CPU 4.

[0064] All master devices 4 and 20 communicate with each other via interconnect 30, which is responsible for routing transactions between the master devices and the memory system 32. Interconnect 30 is also responsible for managing the coherence between data cached in the corresponding caches 10 and 26 of the system. It should be understood that Figure 1 This is a simplified diagram, and for simplicity, System 2 may have elements not shown in... Figure 1 Many other components are shown in the figure.

[0065] like Figure 1 As shown, System 2 may include multiple TLBs 14, 24. These TLBs may include different types of TLBs. Any specific implementation of System 2 may not have all of these types of TLBs, and which types are provided may depend on the design choices made by the system designer. Figure 2 This document summarizes several different types of TLBs.

[0066] As in Figure 2As shown at the top, one option for the TLBs supporting two-stage address translation is to split TLBs 14 and 24 into two separate TLBs: a stage 1-only TLB 40 and a stage 2-only TLB 42. Stage 1-only TLB 40 can be looked up based on the supplied virtual address, and when it contains a matching entry for that virtual address, the virtual address is mapped to the corresponding intermediate address (IPA). Stage 2-only TLB 42 can look up its entry based on the input IPA, and when the TLB contains an entry matching that IPA, it can output the corresponding physical address (PA) for that IPA. Therefore, translating a virtual address to a physical address using such split TLBs 14 and 24 requires two separate lookups, one in stage 1-only TLB 40 and one in stage 2-only TLB 42. As shown in both stage 1-only TLB 40 and stage 2-only TLB 42, each entry can be qualified by a set of context identifiers representing the translation context storing the corresponding address mapping. Each translation context can have a separate page table structure with defined address mappings stored in memory, and which contexts are used can depend on the current operating state of the CPU 4 or other master device when it issues a memory access transaction. For example, different applications can be associated with different address space identifiers (ASIDs) to distinguish their respective access permissions and address mappings. Similarly, different virtual machines or operating systems can be associated with corresponding virtual machine identifiers (VMIDs) to allow access to the corresponding page table structures. Therefore, when looking up a TLB, context identifiers (or several such identifiers) can also be provided as input to the TLB, and only entries that match a set of supplied context identifiers can be returned as a hit. For a stage 1 TLB only, each entry can be labeled with ASID 50 and VMID 52, while for a stage 2 TLB only 42, only VMID 52 can be recorded, because for stage 2 translation, the associated page table data is not associated with individual applications, and therefore ASIDs are unrelated (all processes with different ASIDs controlled by the same virtual machine can share the same stage 2 translation data). Although Figure 2 Not shown, but TLB lookups can also be qualified by other translation context identifiers, such as requesting the current exception (permission) level or security state of the master device.

[0067] As in Figure 2 As shown in the middle section, another approach could be to provide a combined stage 1 and 2 TLB 60, which allows virtual addresses to be directly mapped to physical addresses without requiring two separate TLB lookups. Figure 2The combined Stage 1 and 2 TLB 60 shown does not actually record the IPA (Intra-Program Address) via which the virtual address is translated to the physical address in each translation entry. Therefore, each translation entry may store the ASID 50 and VMID 52 of the corresponding address mapping, as well as the VA and PA, but may not store any indication of the IPA. When such a combined TLB populates its translation entries, deriving the VA-to-PA mapping requires a page table traversal from both the Stage 1 translated data in the first set of page tables and the Stage 2 translated data in the second set of page tables. Once both sets of translated data have been accessed, the associated PA can be identified, and the VA-to-PA mapping is then recorded in the combined TLB, so that the same VA is accessible the next time, and the PA can be obtained directly without revisiting the page tables. This type of TLB is more efficient in terms of hardware and performance because only one TLB lookup is required to obtain the PA when a hit exists in TLB 60. However, this means that this type of TLB cannot perform a TLB lookup to find whether it contains an entry associated with a specific IPA, which affects Stage 2 page table updates and associated TLB failures.

[0068] Figure 2 The bottom section shows a third type of TLB 70, which is a combination of stage 1 and 2 TLBs capable of lookups by IPA. Similar to the example of combination stage 1 and 2 TLB 60, each entry also tracks ASID 50, VMID 52, VA, and PA, but now an IPA field is also present. In a regular TLB lookup used to translate VA to PA, the IPA field is not used because VA can be directly mapped to PA using the VA and PA fields. However, if it is desired to support failure commands that require failures of entries matching a specific IPA or a specific group of IPAs, then in some scenarios, additional circuitry logic for storing IPAs and additional lookup control logic for querying whether a given entry matches a specific IPA can be reasonable.

[0069] Figure 3 Three different types of TLB fail instructions are summarized, which can be supported by the instruction decoder 6 and processing circuitry 8 of CPU 4. When any of these TLB fail instructions (TLBI) is executed, the processing circuitry 8 is controlled to issue a TLB fail command to a group of one or more TLBs 14, 24 within the processing system 2. In some systems, different types of TLB fail instructions can be defined, defining different parts of the processing system in which TLBs need to be failed, so each TLB fail instruction does not need to send a fail command to every TLB within the system. However, when a TLB fail instruction is executed, there may be a group of TLBs to which the TLB fail command is sent, which may include TLBs in other master devices or TLBs within SMMU 22.

[0070] These TLB invalidation instructions can be used to ensure that the TLB can no longer retain outdated translated data after the stage 1 or stage 2 address translation data in the page table in memory has been updated.

[0071] Sometimes, the management procedure controlling the stage 2 translated data may update the address mapping for only a portion of the intermediate address space. While one method to ensure that the TLB does not continue to store stale data could simply broadcast a request for the TLB to invalidate the packet stage 2 based on the stage 2 page table associated with specific group context IDs 50, 52, this could cause many unnecessary entries to be over-invalidated that do not actually involve intermediate addresses undergoing address mapping updates.

[0072] To allow for more targeted invalidation of translated entries in the TLB that depend on updated Stage 2 translated data, a TLB instruction is provided to restrict entries to invalidation based on a specified intermediate address (IPA). Figure 3 The first type of TLB instruction shown provides this intermediate address-based failure condition. This type of TLB failure instruction specifies the target intermediate address, for example, by specifying a register Xt that stores the intermediate address. In this example, the failure condition of the instruction includes: an address-based condition relating the translated entry to the address mapping associated with the specified target intermediate address, and a context-based condition that is satisfied when any translation context identifier associated with the translated entry to be failed matches one or more specified translation context identifiers, which may include a virtual machine identifier, an exception level, and a security state. The specified target translation context identifier matching the corresponding identifier of the entry to be failed in the TLB can be specified within the operands of the TLB failure instruction or can be implied based on the current operating state of CPU 4 when it executes the instruction. Therefore, when the first type of TLB failure instruction is executed, this control processing circuitry 8 issues a first TLB failure command to a group of one or more TLBs 14, 24. The first TLB failure command requests the TLB to fail any entry that matches a first set of failure conditions, which includes both address-based conditions based on an intermediate address specified by the instruction and context-based conditions based on various target translation context identifiers.

[0073] While this type of TLB invalidation instruction can be used to invalidate stage 2-related entries corresponding to a specific intermediate address, not all types of TLBs are likely to comply with this type of invalidation. Stage 1-only TLBs 40 can ignore this type of TLB invalidation command because their entries depend only on the stage 1 translated data and are independent of the stage 2 translated data, and therefore any update to the stage 2 translated data will not affect the validity of any translated entries cached in the stage 1-only TLB 40. Stage 2-only TLBs 42 and combined stage 1 and 2 TLBs 60 and 70 can contain entries that depend on the stage 2 translated data, and therefore such TLBs will need to invalidate some of their entries if the underlying stage 2 translated data has been updated. For combined stage 2-only TLBs 42 and TLBs 70 that can be looked up by intermediate address, the first TLB invalidation command can be complied with by those TLBs because it is possible to identify which entries of those TLBs 42 and 70 are mapped to the target intermediate address. Therefore, only stage 2 TLB 42 and the combined TLB capable of being looked up at intermediate address 70 actually respond to the first TLB failure command and fail any other entries that match the first set of failure conditions (including both address-based and context-based conditions). It should be noted that for the combined TLB capable of being looked up at intermediate address 70, compliance with the first TLB failure command can be delayed, and therefore failure does not necessarily need to occur upon receiving the command, as it can be accomplished by storing trace information associated with the first TLB failure command and then subsequently failing at a later stage in response to another TLB failure command, which will be referred to... Figure 4 Further discussion is needed.

[0074] However, for the type of combined Stage 1 and 2 TLB 60, whose entries cannot be found based on intermediate addresses, it is impossible to determine whether such a TLB has any entries related to the target intermediate address specified by the Type 1 TLB failure instruction. Therefore, in practice, the Type 1 TLB failure instruction alone may not be sufficient to ensure that the TLBs do not contain TLB entries that depend on the obsolete Stage 2 translated data.

[0075] like Figure 3As shown, the instruction decoder 6 and processing circuitry 8 can also support a third type of TLB failure instruction, VMALL. This requires that any TLB entry dependent on the stage 1 translated data be allowed to fail based on a match between its translation context identifier (including VMID, and optionally other identifiers such as security status or exception level) and any entry matching a context-based failure condition, but with a failure condition independent of any address-based failure condition, thus eliminating the need for address checks. The third type of TLB failure instruction can be complied with by stage 1-only TLB 40 and combined TLBs 60 and 70 of both types. This third type of TLB failure instruction causes processing circuitry 8 to issue a third failure command that does not need to be complied with by stage 2-only TLB 42, because stage 2-only TLB does not store any entries related to the stage 1 translated data.

[0076] Therefore, one method to ensure that a Phase 2 failure correctly invalidates any TLB entries that depend on Phase 2 translated data associated with a particular IPA could be following a Type 1 TLB failure instruction (or a series of such Type 1 TLB failure instructions) followed by a Type 3 TLB failure instruction. The Type 3 TLB instruction is designed to capture any entries that cannot be looked up at intermediate addresses within the combined Phase 1 and 2 TLBs 60 but may depend on stale translated data from the Phase 2 page table. However, a side effect of the Type 3 TLB failure instruction is that it can also invalidate many Phase 1 TLB entries, even if these entries are unrelated to the IPA in which the Type 1 TLB instruction was executed.

[0077] In systems that only support Type 1 and Type 3 TLB fail instructions, the performance impact of Type 3 TLB fail instructions on Phase 2 failures per IPA can be considered acceptable in some scenarios because Phase 2 failures are likely to be rare, and average performance over a period of time can still be acceptable. For application CPU 4, this may be acceptable, as performance is good in most cases, and occasional poor performance caused by refreshing the TLB for Phase 1 related entries is acceptable, and thus performance hits are acceptable when the entries are retrieved again.

[0078] However, this overlooks the impact on real-time performance, which is particularly important for some of the devices 20 interacting with the SMMU 22. For real-time critical devices, worst-case performance may be a more significant factor than average performance. Even among non-real-time devices, some may still be performance-sensitive. An example of such a device could be a display controller, for which it is important that the performance level achieved in each frame display cycle is sufficient to prepare image data frames for display at the end of the cycle to allow the display controller to keep pace with the frame refresh rate used. Therefore, even if stage 2 failures are infrequent, for such performance-sensitive devices, the occasional refresh of many stage 1-related entries unnecessarily via third-type TLB failure instructions can have a significant performance impact. This is particularly likely to occur because such performance-sensitive devices may employ strategies such as pre-fetching page table information before the device actually requires those translations to perform actual address translations for memory access. If there is packet phase 1 address translation by virtual machine ID, such as in response to a Type 3 TLB failure instruction, the benefits of such prefetching may be significantly limited. This Type 3 TLB failure instruction may be sufficient to ensure that the display controller cannot meet the performance requirements imposed by the frame refresh rate and may therefore cause the user to see some black screens with display loops.

[0079] To solve these problems, such as Figure 3As shown, the instruction decoder 6 and processing circuitry 8 can also support a second type of TLB failure instruction, VMALLCOMB, which specifies a set of failure conditions independent of any address-based conditions but including context-based conditions requiring a match between a set of translation context identifiers associated with a given translated entry in the TLB and a specified set of translation context identifiers. Similarly, these translation context identifiers can be the virtual machine ID, exception level, and / or security state of CPU 4. The target translation context identifier sought when matching a TLB entry can be specified in the operand of the instruction or implied based on the current operating state of CPU 4 when executing the instruction. Therefore, the failure conditions specified by the second type of instruction can essentially be the same as those specified by the third type of TLB failure instruction. However, the difference with the second type of TLB failure instruction is that it targets a more limited subset of the types of TLBs. In response to the second type of TLB failure instruction, the instruction decoder 6 controls the processing circuitry 8 to issue a second TLB failure command to the relevant sets of TLBs 14, 24 that may have undergone failure. If any of these TLBs is a stage 1-only type 40, a stage 2-only type 42, or a combined stage 1 and 2 type 70 that can be looked up by intermediate address, then the second fail command can be ignored. The second fail command only needs to be complied with by combined stage 1 and 2 TLBs 60 of types whose entries cannot be looked up based on intermediate address. By limiting the effect of the second type of TLB fail instruction to only those combined stage 1 and 2 TLBs 60 that cannot respond to the first type of TLB fail instruction, this greatly reduces the chance of over-failure because it avoids the blanket failure of many stage 1-related entries within stage 1-only TLBs 40 or combined TLBs that can be looked up by intermediate physical address 70, which would otherwise be executed if the third type of TLB fail instruction were used. Therefore, to perform stage 2 failure, in systems that support Type 2 TLB failure instructions, a programmer or compiler can define a set of instructions that includes one or more Type 1 TLB failure instructions (TLBI IPAS2), followed by a Type 2 TLB failure instruction (TLBI VMALLCOMB) to erase any remaining stage 2 related entries in the combined stage 1 and 2 TLB 60 that cannot be failed by Type 1 TLB failure instructions and cannot be found by IPA. This significantly reduces the performance impact, especially for real-time critical or performance-sensitive devices.

[0080] Therefore, system designers can choose which type of combined TLB 60 or 70 to use when designing the combined Stage 1 and 2 TLBs, depending on the needs of the associated master devices. For TLB 14 within CPU 4, where the performance impact of over-failure caused by the Type 3 TLB failure instruction may not be a major issue, it might be preferable to use a Type 60 TLB that cannot be looked up at intermediate addresses, in order to save circuit area by eliminating the memory unit and lookup logic used to track intermediate addresses. However, for TLB 24 within SMMU 22, designers might prefer to use a larger type of TLB 70 that can be looked up at intermediate addresses, so that in the event of a Stage 2 failure, they can respond to the Type 1 TLB failure instruction and therefore do not need to over-fail the entry when executing the Type 2 TLB failure instruction.

[0081] For a TLB 70 that stores the combined entries of stages 1 and 2 and can look up its entries by intermediate address, compliance with the first TLB fail command can be implemented in different ways. One option is that the first TLB fail operation precisely fails the required TLB entry when it receives a TLB fail command from CPU 4, and in this case, the second type of TLB fail command triggered by the second TLB fail instruction VMALLCOM can be completely ignored. This approach is relatively simple to implement; however, since each fail operation may require traversing every entry in the TLB to check if it matches the fail condition, if the program executes a series of two or more TLB fail instructions of the first type specifying different intermediate addresses, this could require many separate traversals of the TLB, which could have performance and power impacts.

[0082] The second method could be to postpone the invalidation of the first TLB invalidation instruction until the TLB receives a subsequent TLB invalidation command triggered by a second type of instruction. For example... Figure 4As shown, a trace structure 100 is provided in association with a TLB 70 of a type capable of being looked up by IPA. When a first TLB failure command that must be obeyed by this type of TLB 70 is received, rather than immediately being failed, the trace structure is simply updated to record an indication of the failure condition associated with the first TLB failure command, including an indication of intermediate addresses. If multiple TLB instructions of the first type are executed, each time a corresponding first TLB failure command is received by the combined TLB 70, the combined TLB updates its trace structure 100 based on the latest group failure condition of the received TLB failure command. Subsequently, when a second type of TLB failure instruction is executed and the combined TLB 70 receives a corresponding second TLB failure command, this can be used as a triggering event to then traverse all entries of the TLB 70 to check whether each of those entries matches any of the group failure conditions traced in the trace structure 100, and then fail those entries that do match one of those group failure conditions. This means that all failures of each of the executed first type of TLB failure instructions can be implemented with a single traversal of the TLB 70.

[0083] The trace structure 100 can be implemented in different ways. Generally, it is expected that in a series of consecutive TLB failure instructions of the first type, they may all be associated with the same set of translation context IDs and therefore may only require a single set of translation context storage entries to trace the context identifier of each of the series of failure instructions, but may require separate entries to trace the corresponding intermediate addresses specified by the series of instructions. In some cases, the trace structure may simply be a list of intermediate addresses of received failure operations, which can then be checked for each entry once a second type TLB failure command is received. In some cases, the number of addresses that can be traced in the trace structure 100 may be limited to a maximum number, so that even if a second type TLB failure instruction has not yet been executed, once the maximum number is reached or exceeded, this can be used as a trigger event to apply the failure traced by the trace structure to the combined type TLB 70 to fail the relevant entry that matches either the intermediate physical address specified by the previous failure operation or the set of translation context identifiers.

[0084] On the other hand, the tracking structure 100 can also use imprecise filters, such as Bloom filters, to track the intermediate addresses of the pending first TLB fail command, and then, once a second TLB fail command (VMALLCOMB) is received or the maximum number of first TLB fail commands has been reached, the combined TLB 70 can fail any of the entries with intermediate addresses that match the representation stored in the filter. This approach has the potential to over-fail entries because the filter representation can be constructed such that, although it is impossible to provide a correct / false identification (a TLB entry for any address used to update the filter will be considered to match the filter representation), the filter can identify correct / false identifications where addresses other than one of the intermediate addresses used to update the filter structure are considered to match the filter, and thus unnecessary failures of additional TLB entries can be performed, which is not a strict requirement of the received first TLB fail command. Although some over-failure of entries is possible, this may involve fewer entries than in the case where a third type of TLB fail instruction has already been executed. Using filters reduces the overhead of the tracking structure (resulting in less circuit area and power compared to a precise tracking structure).

[0085] Other types of combined stage 1 and 2 TLBs that can be looked up by IPA 70 may not prefer to use this tracing method, and instead, each time a first TLB failure command is received, the TLB is simply traversed to look for any entry that matches the required intermediate address.

[0086] Figure 5 This is a flowchart illustrating a method for processing TLB invalidation instructions at CPU 4. At step 150, instruction decoder 6 decodes the TLB invalidation instruction. At step 152, instruction decoder 6 identifies the type of TLB invalidation instruction to be executed. This type can be identified based on the instruction's opcode, or based on another parameter specified in the instruction encoding, or based on parameters stored in the CPU 4's control register, and can be updated in response to earlier instructions controlled, for example, by software. Another example could be that this type of TLB invalidation instruction is affected by a previous instruction that prefixes it with a TLB instruction and modifies subsequent TLB invalidation instructions of that type.

[0087] If instruction decoder 6 identifies the TLB invalid instruction as type 1, such as... Figure 3As shown, at step 154, the instruction decoder 6 controls the processing circuit 8 to issue a first TLB fail command to TLBs 14 and 24. The first TLB fail command requests the TLBs to fail entries that satisfy a first set of fail conditions, which includes a condition that the intermediate address corresponding to the entry to be failed corresponds to a specified target intermediate address identified in the operand of the instruction (e.g., by referring to the register Xt containing the target address). Although a first TLB fail command is issued to the TLBs, not all TLBs may be able to comply with the command. For example, the combined TLB 60, which cannot be looked up by intermediate address, may not respond and therefore may allow the first TLB fail command to be ignored.

[0088] If the TLB failure command is identified as type 2 (VMALLCOMB), then at step 156, the instruction decoder 6 controls the processing circuit 8 to issue a second TLB failure command to TLBs 14 and 24. This second TLB failure command requests that TLBs 60 in combined stages 1 and 2 that did not comply with the first TLB failure command should fail entries that satisfy a second set of failure conditions. This second set of failure conditions can be based on context identifier matching, but can be independent of any address-based comparison. Therefore, this type 2 TLB failure command enables those TLBs that did not comply with the first TLB failure command to fail relevant entries that may have already undergone stage 2 translated data updates.

[0089] If, at step 152, the instruction decoder 6 identifies a TLB failure instruction as type 3, then at step 158, the instruction decoder 6 controls the processing circuitry 8 to issue a third TLB failure command to TLBs 14 and 24. The third TLB failure command requests that only stage 1 TLB 40, or a combination of stages 1 and 2 TLBs 60 and 70, fail all entries (regardless of address) that satisfy a third set of failure conditions based on a comparison between the target translation context identifier in the specified group and a set of translation context identifiers associated with the TLB entry. The third TLB failure command will have a greater impact on performance than the second TLB failure command because it affects more types of TLBs.

[0090] The instruction decoder also supports Figure 3 Other types of TLB failure instructions not specifically shown. For any other type of TLB instruction, at step 160, the instruction decoder 6 controls the processing circuit 8 to send another type of TLB failure command to control the TLB to apply some other set of failure conditions to determine which entries need to be failed.

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

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

Claims

1. A data processing apparatus, the data processing apparatus comprising: Processing circuitry, the processing circuitry being configured to perform data processing in response to instructions; and An address translation circuit performs two-stage address translation to translate a virtual address into a physical address, wherein the mapping from the virtual address to the physical address depends on stage 1 translation data for mapping the virtual address to an intermediate address and stage 2 translation data for mapping the intermediate address to the physical address; wherein: In response to a first type of translation back buffer (TLB) fail instruction for a specified target intermediate address, the processing circuitry is configured to issue a first TLB fail command to at least one TLB used to store translation entries derived from at least one of the stage 1 translation data and the stage 2 translation data. The first TLB fail command requests the at least one TLB to fail translation entries that satisfy a first set of one or more fail conditions, the first set including intermediate address-based conditions satisfied when the translation entry corresponds to the target intermediate address; and In response to a second type of TLB failure command, the processing circuit is configured to issue a second TLB failure command, the second TLB failure command requesting: If the at least one TLB includes a first type TLB, then the first type TLB shall invalidate one or more translation entries that satisfy one or more failure conditions of a second set, wherein the first type TLB is a TLB configured to ignore the first TLB failure command and configured to store the type of a combination of stage 1 and 2 entries depending on both the stage 1 translation data and the stage 2 translation data. as well as If the at least one TLB includes a second type of TLB in addition to the first type of TLB, then the second type of TLB shall retain one or more translation entries that satisfy one or more failure conditions of the second set.

2. The apparatus of claim 1, wherein the first type TLB is a TLB of a type in which it is impossible to determine whether the combined stage 1 and 2 entries correspond to the target intermediate address.

3. The apparatus according to any one of claims 1 and 2, wherein the second type TLB comprises at least one of the following: Stage 1 TLB only, wherein the translation entries of Stage 1 TLB only depend on the Stage 1 translation data and are independent of the Stage 2 translation data; Stage 2 TLB only, wherein the translation entries of the Stage 2 TLB depend on the Stage 2 translation data and are independent of the Stage 1 translation data; or Combining Stage 1 and TLB, which are configured to store the entries of Combining Stage 1 and TLB, which are capable of determining whether the entries of Combining Stage 1 and TLB correspond to the target intermediate address.

4. The apparatus of claim 1, wherein the second set of one or more failure conditions includes at least one context-based condition, the at least one context-based condition being satisfied by the translation entry for which at least one translation context identifier specified by the translation entry matches at least one target translation context identifier.

5. The apparatus of claim 4, wherein the second set of one or more failure conditions does not include address-based conditions.

6. The apparatus according to any one of claims 4 and 5, wherein the at least one translation context identifier comprises one or more of the following: Virtual machine identifier; Security status identifier; and Exception level identifier.

7. The apparatus according to any one of claims 4 and 5, wherein each target translation context identifier includes one of the following: The translation context identifier specified by the operand of the second type of TLB invalidation instruction; and The translation context identifier depends on the current operating state of the processing circuit when executing the second type of TLB failure instruction.

8. The apparatus according to any one of claims 1 and 2, wherein the first group of one or more failure conditions includes at least one context-based condition, the at least one context-based condition being satisfied by the translation entry which specifies at least one translation context identifier that matches at least one target translation context identifier.

9. The apparatus according to any one of claims 1 and 2, wherein: In response to a third type of TLB failure instruction, the processing circuitry is configured to issue a third TLB failure command that requests the at least one TLB to fail all translation entries that depend on the stage 1 translation data and specify at least one translation context identifier that matches at least one target translation context identifier.

10. The apparatus of claim 1, comprising at least one TLB of the second type, wherein the at least one TLB of the second type is an intermediate address tracking combination stage 1 and 2 TLB configured to store the combination stage 1 and 2 entries, the combination stage 1 and 2 TLB being capable of determining whether the combination stage 1 and 2 entries correspond to the target intermediate address.

11. The apparatus of claim 10, wherein each translation entry of the intermediate address tracking combination stages 1 and 2 TLBs specifies a virtual-to-physical address mapping and a corresponding intermediate address.

12. The apparatus of any one of claims 10 and 11, wherein the intermediate address tracking combination stages 1 and 2 TLBs are configured to comply with the first TLB failure command by triggering a failure of one or more translation entries that satisfy the first set of failure conditions in response to the first TLB failure command.

13. The apparatus of any one of claims 10 and 11, wherein the intermediate address tracking combination stages 1 and 2 TLBs are configured to comply with the first TLB invalidation command in such a way that: In response to the first TLB failure command, update the tracking information based on the first set of failure conditions; and In response to the second TLB failure command or the detection that the number of received first TLB failure commands exceeds a threshold, a failure is triggered on one or more translated entries that satisfy a set of tracked failure conditions represented by the tracking information.

14. The apparatus of claim 13, wherein the tracking information precisely tracks the first set of failure conditions specified by a series of one or more first TLB failure commands.

15. The apparatus of claim 13, wherein the tracking information includes a filter representation that inaccurately tracks the first set of failure conditions specified by a series of one or more first TLB failure commands, such that the translation entries satisfying the set of tracked failure conditions are allowed to include at least one translation entry that does not satisfy the first set of failure conditions specified by any of the series of one or more first TLB failure commands.

16. The apparatus according to any one of claims 1 and 2, comprising at least one TLB of the first type.

17. The apparatus according to any one of claims 1 and 2, comprising at least one TLB of the second type.

18. A data processing apparatus, the data processing apparatus comprising: A means for performing data processing in response to instructions; and A means for translating a virtual address to a physical address using two-stage address translation, wherein the mapping from the virtual address to the physical address depends on stage 1 translation data for mapping the virtual address to an intermediate address and stage 2 translation data for mapping the intermediate address to the physical address; wherein: In response to a first type of translation back buffer (TLB) fail instruction for a specified target intermediate address, the means for performing data processing is configured to issue a first TLB fail command to at least one TLB storing translation entries derived from at least one of the stage 1 translation data and the stage 2 translation data. The first TLB fail command requests the at least one TLB to fail translation entries that satisfy a first set of one or more fail conditions, the first set including intermediate address-based conditions satisfied when the translation entry corresponds to the target intermediate address; and In response to a second type of TLB failure command, the device for data processing is configured to issue a second TLB failure command, the second TLB failure command requesting: If the at least one TLB includes a first type TLB, then the first type TLB shall invalidate one or more translation entries that satisfy one or more failure conditions of a second set, wherein the first type TLB is a TLB configured to ignore the first TLB failure command and configured to store the type of a combination of stage 1 and 2 entries depending on both the stage 1 translation data and the stage 2 translation data. as well as If the at least one TLB includes a second type of TLB in addition to the first type of TLB, then the second type of TLB shall retain one or more translation entries that satisfy one or more failure conditions of the second set.

19. A method for a data processing apparatus, the data processing apparatus comprising: Processing circuitry, the processing circuitry being configured to perform data processing in response to instructions; And an address translation circuit that performs two-stage address translation to translate a virtual address into a physical address, wherein the mapping from the virtual address to the physical address depends on stage 1 translation data for mapping the virtual address to an intermediate address and stage 2 translation data for mapping the intermediate address to the physical address. The method includes: In response to a first type of translation back buffer (TLB) fail instruction for a specified target intermediate address, a first TLB fail command is issued to at least one TLB storing translation entries derived from at least one of the stage 1 translation data and the stage 2 translation data. The first TLB fail command requests the at least one TLB to fail translation entries that satisfy a first set of one or more fail conditions, the first set including intermediate address-based conditions satisfied when the translation entry corresponds to the target intermediate address; and In response to a Type 2 TLB failure instruction, a second TLB failure command is issued, the second TLB failure command requesting: If the at least one TLB includes a first type TLB, then the first type TLB shall invalidate one or more translation entries that satisfy one or more failure conditions of a second set, wherein the first type TLB is a TLB configured to ignore the first TLB failure command and configured to store the type of a combination of stage 1 and 2 entries depending on both the stage 1 translation data and the stage 2 translation data. as well as If the at least one TLB includes a second type of TLB in addition to the first type of TLB, then the second type of TLB shall retain one or more translation entries that satisfy one or more failure conditions of the second set.

Images