Address translation manipulation at cache coherency level
By performing address translation manipulation at the cache coherency level with a hardware agent, the limitations of rigid hardware-software boundaries and static partitioning are overcome, achieving efficient and flexible virtualization with reduced latency and improved system performance.
Patent Information
- Authority / Receiving Office
- WO · WO
- Patent Type
- Applications
- Current Assignee / Owner
- TRUSTEES OF BOSTON UNIV
- Filing Date
- 2025-12-02
- Publication Date
- 2026-06-11
AI Technical Summary
Existing virtualization techniques for safety-critical and real-time systems face limitations in flexibility and performance due to rigid hardware-software boundaries, all-or-nothing translation, and static partitioning, particularly in managing I/O devices, leading to increased overhead and latency.
Perform address translation manipulation at the cache coherency level using a hardware agent to generate modified page table entries (PTEs) that differ from original entries, allowing dynamic and flexible virtualization without software intervention, thereby reducing latency and improving efficiency.
This approach enables efficient and flexible virtualization by dynamically manipulating address translations at the cache coherency level, reducing latency and eliminating unnecessary page table walks, thus enhancing system performance and flexibility.
Smart Images

Figure US2025057631_11062026_PF_FP_ABST
Abstract
Description
[0001] PCT / US25 / 57631 02 December 2025 (02.12.2025)
[0002] 1
[0003] SYSTEMS, METHODS, AND MEDIA FOR ADDRESS TRANSLATION MANIPULATION IN A COMPUTING SYSTEM AT THE CACHE COHERENCY LEVEL
[0004] BACKGROUND
[0005] Technical Field
[0006] The present disclosure relates generally to the cache coherency level of a computer architecture and more specifically to techniques for address translation manipulation at the cache coherency level.
[0007] Background Information
[0008] Modern computing systems rely on a layered relationship between hardware and software, in which hardware provides fixed physical resources such as processors, memory, and communication buses, while software manages how those resources are scheduled and accessed. This separation simplifies design but enforces a rigid hardware and software boundary that can limit performance in domains requiring precise timing, low latency, and strict time constraints. These limitations are especially problematic in safety-critical and real-time systems that depend on efficient access to underlying hardware.
[0009] To manage increasingly heterogeneous System-on-Chip (SoC) architectures that include central processing units (CPUs), graphic processing units (GPUs), and field-programmable gate arrays (FPGAs), designers employ Virtualization at different levels. These levels typically include the Type 1 Hypervisors, namely bare metal virtualization software, and Type 2 Hypervisors, namely virtualization software running on top of an Operating System.
[0010] In the context of safety-critical and real-time systems, Type 1 Hypervisors are the most common solution, since they allow for strict, and often static, partitioning of the underlying resources. The bare metal virtualization is usually implemented as a second stage of Address Translation, similar to the Virtual-to-Physical address translation performed by the Operating System; this second stage is facilitated by the quasi-totality of the hardware. PCT / US25 / 57631 02 December 2025 (02.12.2025)
[0011] 2
[0012] While widely used, second stage translation as a virtualization method has some limitations: (1) the virtualization, given the hardware support, has to be all-or- nothing; namely to virtualize a memory range, the entire system has to undergo a second stage of translation, and (2) the static partitioning and the eventual overhead caused by manipulation of such mappings penalizes any run-time change, thereby limiting the utilization in some systems and contexts.
[0013] Moreover, more specialized partitioning, as the virtualization of I / O devices, remains particularly challenging. Two conventional approaches at this level are the split I / O model and the passthrough I / O model. In the split I / O model, the hypervisor manages the device and exports a virtualized interface to the virtual machines, adding access overhead. In the passthrough I / O model, the hypervisor maps an I / O device directly and exclusively to a single virtual machine, canceling the possibility of multiplexing for multiple virtual machines. Various hybrid software techniques have attempted to improve this tradeoff, but most still require specialized hardware or additional software support.
[0014] At the operating system level, various kemel-bypass techniques may be employed to implement I / O virtualization. Kernel-bypass techniques allow software applications to directly interface with I / O devices to handle requests efficiently. By removing kernel mediation, kernel-bypass techniques reduce the overhead of system calls and may improve throughput. As a result, while kemel-bypass approaches lower overheads when compared to hypervisor-based models, they do so at the expense of increased software complexity.
[0015] At the hardware level, Single-Root I / O Virtualization (SR-IOV) enables complex devices to be shared among multiple virtual machines. SR-IOV achieves this by exporting several virtual functions from a single physical I / O device, each of which can be mapped directly to a virtual machine or application. This hardwarebased approach reduces software overhead and improves I / O performance. However, SR-IOV support is device-specific and implemented through custom hardware logic, which limits flexibility and scalability across different platforms.
[0016] Therefore, there remains a need for a more efficient and flexible virtualization technique that overcomes the performance and latency limitations of existing software-based approaches and the rigidity of hardware -based solutions that are tied to specific devices or platforms. PCT / US25 / 57631 02 December 2025 (02.12.2025)
[0017] 3
[0018] SUMMARY
[0019] Techniques are provided for address translation manipulation at the cache coherency level. Specifically, a memory management unit (MMU) of a central processing unit (CPU) may encounter a table lookaside buffer (TLB) miss for a virtual address (VA) being monitored by a hardware agent. In an embodiment, the TLB miss is encountered because TLB entries and cache lines containing PTEs related to the monitored VA range are invalidated. Based on the TLB miss, the MMU initiates performance of a page table walk.
[0020] The hardware agent is configured to receive and monitor snoop requests from a cache coherency interconnect (CCI). The hardware agent can determine that a target PTE needed for the page table walk corresponds to the monitored VA range. In response to determining that the target PTE corresponds to the monitored VA range, the hardware agent can send a valid snoop response to the CCI. The snoop response may indicate that the hardware agent has a cache line for the target PTE even though the hardware agent does not.
[0021] The hardware agent may generate a modified PTE that is different from an original PTE of a page table stored in memory and accessed during a conventional page table walk. In an embodiment, the modified PTE may store a physical frame number (PFN) and / or attributes that are different from those of the original PTE. The hardware agent may provide the modified PTE to the CPU by way of the CCI. The MMU may create a new TLB entry that includes the PFN and attributes, from the modified PTE, which are indexed by the monitored VA.
[0022] The CPU may receive a subsequent transaction associated with the monitored VA. The MMU may access the TLB to identify the new TLB entry that can be used to translate the monitored VA to a modified (poisoned) PA. An I / O device corresponding to the modified PA may receive the transaction by way of the CCI. The I / O device may execute one or more functions for the received transaction. PCT / US25 / 57631 02 December 2025 (02.12.2025)
[0023] 4
[0024] BRIEF DESCRIPTION OF THE DRAWINGS
[0025] The description below refers to the accompanying drawings, of which:
[0026] Fig. 1 is an illustrative example of a system environment for address translation manipulation at the cache coherency level according to the one or more embodiments as described herein;
[0027] Fig. 2 is an illustrative example of a hardware agent according to the one or more embodiments as described herein;
[0028] Fig. 3 is a flow diagram of a sequence of steps for address translation manipulation at the cache coherency level according to the one or more embodiments as described herein;
[0029] Fig. 4 illustrates an example of an original PTE and a modified PTE according to the one or more embodiments as described herein;
[0030] Fig. 5 illustrates another example of an original PTE and a modified PTE according to the one or more embodiments as described herein; and
[0031] Fig. 6 is a flow diagram of a sequence of steps for processing a VA corresponding to a modified (poisoned) PA according to the one or more embodiments as described herein.
[0032] DETAILED DESCRIPTION OF AN ILLUSTRATIVE EMBODIMENT
[0033] Fig. 1 is an illustrative example of a system environment for address translation manipulation at the cache coherency level according to the one or more embodiments as described herein. As depicted in Fig. 1, particular devices are shown within a cloud environment, represented by the dashed box. However, it is expressly contemplated that only the memory 130 may reside in the cloud, while one or more of the other devices of system environment 100 may be on-premises.
[0034] System environment 100 includes one or more central processing units (CPU) 105, each including a memory-management unit (MMU) 110, a translation lookaside buffer (TUB) 115, and one or more lower- level caches 120. In an embodiment, a CPU 105 may execute one or more instructions or perform one or more operations. During execution of an instruction or performance of an operation, the CPU 105 may generate PCT / US25 / 57631 02 December 2025 (02.12.2025)
[0035] 5 a transaction (e.g., memory access request or an input / output (I / O) request) corresponding to a virtual address (VA) referenced by the instruction or operation. The MMU 110 may access the TLB 115 in an attempt to translate the VA to a corresponding physical address (PA). Specifically, the TLB 115 may store a plurality of TLB entries, each of which includes a physical frame number (PFN) and various associated attributes (e.g., permissions, cacheability, memory type, etc.) that are indexed by a particular VA. The PFN can be utilized to determine the corresponding PA, for example, by combining the PFN with a page offset portion of the VA.
[0036] When the MMU 110 determines that a TBL entry corresponding to a VA to be translated is present in the TLB 115, this condition may be referred to as a “TLB hit.” In response to a TLB hit, the CPU 105 may use the determined PA to access the one or more lower- level caches 120 to determine whether actual data corresponding to the PA is stored therein. The actual data may correspond to an instruction cache line or a data cache line. The one or more lower- level caches 120 may be configured as an LI cache and / or an L2 cache. If the actual data is not found in the one or more lower-level caches 120, the CPU 105 may obtain the data from a last-level cache (LLC) 125 or from memory 130 via the cache coherency interconnect (CO) 135.
[0037] When the MMU 110 determines that a TLB entry corresponding to the VA to be translated is not present in the TLB 115, this condition may be referred to as a “TLB miss.” In response to a TLB miss, the MMU 110 may initiate and perform a page table walk. The page table walk is a hierarchical traversal of a plurality of page tables 165 to identify successive PTEs, ultimately resulting in the determination of the corresponding PA . Because PTEs are cacheable data, they may be stored as cache lines in the one or more lower-level caches 120 and / or in the last- level cache (LLC) 125.
[0038] Accordingly, the MMU 110 may access the one or more lower- level caches 120 (i.e., local lower-level caches) of the CPU 105 to determine whether a PTE of interest (i.e., target PTE) is stored therein. If not, the MMU 110 may access the LLC 125 to determine whether the target PTE is stored therein. If both the lower- level caches 120 and the LLC 125 do not store the target PTE, the CCI 135 may issue a snoop request to one or more coherent managers (e.g., other CPUs 105) to determine whether their respective caches (e.g., remote lower-level caches 120) store the target PTE. If the target PTE is not found in any cache, the CCI 135 may obtain the target PTE from main memory 130. As an illustrative example, assume that the page table walk uses the VA PCT / US25 / 57631 02 December 2025 (02.12.2025)
[0039] 6 to access and identify an entry (i.e., PTE) from a page global directory table. The page global directory entry may be used to identify an entry from a page upper directory table. The page upper directory entry may then be used to identify an entry from a page middle directory table, and the page middle directory entry may in turn be used to identify an entry from a page table that determines the corresponding PA. For example, the entry from the page table, together with offset bits from the VA, may be used to determine the corresponding PA. Because the PTEs are cacheable, the one or more lower- level caches 120 and / or the LLC 125 may be accessed to determine whether the PTE is stored therein. The CCI 135 may issue snoop requests to one or more cache managers, as described above, to determine whether their respective caches store the PTE before accessing the page tables 165 in the memory 130. If the lower-level caches 120 and the LLC 125 do not store the PTE of interest (i.e., target PTE), the page tables 165 may be accessed from the memory 130 to obtain the target PTE, enabling the MMU 110 to perform the next lookup for the PTE of a subsequent page table level.
[0040] System environment 100 also includes hardware agent 140 that may implement the one or more embodiments as described herein. As discussed in greater detail below, hardware agent 140 may monitor coherence snoop requests issued by the CCI 135. If a snoop request targets a PTE of interest (i.e., target PTE) corresponding to a VA being monitored by the hardware agent 140, the hardware agent 140 may generate a modified PTE that differs from the original PTE stored in a page table 165 of the memory 130. The hardware agent 140 may respond with a valid coherence snoop response indicating that it maintains the PTE of interest even though it does not and may provide the modified PTE to the MMU 110 via the CCI 135. The MMU 110 may update TLB 115 with a new TLB entry that includes information from the modified PTE (also referred to as a “poisoned” PTE).
[0041] As a result, the MMU 110 may subsequently translate the monitored VA, for later transactions (e.g., memory access requests or I / O requests), to a modified (poisoned) PA that is determined from the new TLB entry stored in the TLB 115. In an embodiment, the modified PA corresponds to an I / O device (not shown), thereby enabling the I / O device to receive all subsequent transactions corresponding to the monitored VA. Alternatively, the modified PA may correspond to any preferred PA.
[0042] Fig. 2 is an illustrative example of a hardware agent according to the one or more embodiments as described herein. In an embodiment, the hardware agent 140 may be a field-programmable gate array (FPGA). In an embodiment, hardware agent PCT / US25 / 57631 02 December 2025 (02.12.2025)
[0043] 7
[0044] 140 is a coherent manager that appears to the cache-coherency interconnect (CO) 135 as a traditional cache manager.
[0045] Hardware agent 140 may be programmed with the necessary components (i.e., hardware components), which are depicted in Fig. 2, before the hardware agent 140 is operational and monitoring snoop requests from CCI 135 as will be described in further detail below. While in the operational mode, hardware agent 140 is directly coupled to (i.e., interfaces with) CCI 135 and indirectly coupled to memory 130 as depicted in Fig. 1. As depicted in Fig. 2, hardware agent 140 can communicate with CCI 135 and memory 130 via interface 205.
[0046] As depicted in Fig. 2, the hardware agent 140 includes snoop monitor module 215, a hardware module, that allows the hardware agent to monitor and respond to snoop requests issued by the CCI 135 for PTEs of interest as will be described in further detail below. Hardware agent 140 also includes PTE manipulator module 220, a hardware module, that can generate a PTE (i.e., modified PTE) that is different from a corresponding PTE (i.e., original PTE) stored in page table 165 of memory 130. In an embodiment, memory access module 225, a hardware module, may obtain an original PTE from memory 200 via interface 205. For example, the memory access module 225 may obtain the original PTE via CCI 135 and interface 205. The PTE manipulator module 225 may analyze the original PTE and generate the modified PTE based on the analysis. The PTE manipulator module 225 may provide the modified PTE to MMU 110 via interface 205 to update the TLB 115 with the modified PTE.
[0047] Fig. 3 is a flow diagram of a sequence of steps for address translation manipulation at the cache coherency level according to the one or more embodiments as described herein. Procedure 300 starts at step 305 and continues to step 310. At step 310, the TLB entries and cache lines containing PTEs related to the monitored VA range are invalidated.
[0048] As an illustrative example, assume that the VA range being monitored by hardware agent 140 is OxBOOO through OxDOOO. In an embodiment, the monitored VA range may correspond to an I / O device aperture. Alternatively, the monitored VA range may correspond to any selected PA range. Continuing with the example, hardware agent 140 may issue an invalidate command for the VA range of OxBOOO through OxDOOO to the CCI 135. For example, hardware agent 140 may transmit the invalidate command on a coherence channel via interface 205. Invalidation of all PTEs corresponding to the VA range of OxBOOO through OxDOOO from LLC 125 may be PCT / US25 / 57631 02 December 2025 (02.12.2025)
[0049] 8 enforced. The invalidate command may be propagated to each of the one or more CPUs 105 to cause invalidation of all PTEs corresponding to the VA range of OxBOOO through OxDOOO from the one or more lower-level caches 120, as well as invalidation of any corresponding TLB entries from TLBs 115 of the CPUs 105. As a result, subsequent transactions to the monitored VA range will trigger a new page table walk that can be intercepted and manipulated by hardware agent 140 as will be described in further detail below.
[0050] The procedure continues from step 310 to step 315. At step 315, A TLB cache miss is encountered. Continuing with the example, assume that the MMU 110 receives a VA within the VA range of OxBOOO through OxDOOO. For example, the VA may be generated based on the program counter of CPU 105 or a CPU access to an application’ s data. The MMU 110 may access the TLB 115 in an attempt to identify a TLB entry in the TLB 115 that corresponds to the VA. However, the MMU 110 encounters a TLB miss as a result of the invalidation of step 310.
[0051] The procedure continues from step 315 to step 320. At step 320, the MMU 110 initiates performance of a page table walk based on the TLB miss. Continuing with the example, the MMU 110 may initiate the page table walk as a result of the TLB miss in TLB 115. The TLB 115 stores only VA-to-PA translation information (e.g., the PFN and associated attributes) and does not contain the PTE entries of the page tables 165 that are accessed to determine the PA for a particular translation. The MMU 110 may begin the page table walk starting from the highest-level page table and traverse each intermediate page table to a final, lowest-level page table from which the PA can be determined. Because the PTEs related to the monitored VA range are not cached in lower- level caches 120 or LLC 125 due to the invalidation, the page table walk may require access to memory 130, which stores page tables 165, via the CO 135. Page tables 165 may be organized hierarchically. For example, the hierarchy may include a page global directory, a page upper directory, a page middle directory, and a page table.
[0052] The procedure continues from step 320 to step 325. At step 325, the hardware agent receives a snoop request for a target PTE, i.e., PTE of interest corresponding to the VA that resulted in the TLB miss. In an embodiment, the snoop monitor module 215 of hardware agent 140 monitors received snoop requests. During the page table walk, the MMU 110 may issue read requests (i.e., page table access requests) to the memory 130 through the CO 135. Each read request may include identification information, such as the physical address required to obtain the target PTE from a PCT / US25 / 57631 02 December 2025 (02.12.2025)
[0053] 9 corresponding page table 165 stored in the memory 130. As previously described, PTEs are cacheable data and may be stored in the one or more lower-level caches 120 of each CPU 105 and / or in the LLC 125. Because of the invalidation described in step 310, the lower- level caches 120 corresponding to the CPU 105 that includes the MMU 110 initiating the page table walk will not contain the target PTE. Because of the invalidation, the LLC 125 also will not contain the target PTE..
[0054] The CCI 135 may then determine whether any coherent managers (e.g., other CPUs 105 that did not initiate the page table walk) store the target PTE in their respective caches by issuing a snoop request for the target PTE to all coherent managers. Obtaining the target PTE from cache instead of obtaining the target PTE from the page table 165 stored in memory 130 improves efficiency and latency. If data is going to be stored in a cache, then the system needs to implement and ensure cache coherency. If a coherent manager stores the target PTE, the CCI 135 may retrieve the PTE from that coherent manager (for example, from a different CPU 105 than the one from where the page table walk was initiated). However, because of the invalidation, no coherent managers stores the target PTE. As will be explained in further detail below, hardware agent 140 may indicate that it maintains the target PTE, even though it does not, and may thereby implement the address manipulation as described herein.
[0055] The procedure continues from step 325 to step 330. At step 330, the hardware agent 140 determines that the target PTE corresponds to a monitored VA. In an embodiment, snoop monitor module 215 may determine whether a virtual page mapped by the target PTE falls within the monitored VA range. If the virtual page falls within the monitored VA range, then the target PTE corresponds to that VA range. If the virtual page does not fall within the VA range, the target PTE is outside the VA range. Each virtual page may correspond to a range of contiguous VAs defined by a page size (e.g., 4 KB), and the hardware agent 140 may determine whether the page-aligned VA identified by the PTE falls within the monitored VA range. It should be appreciated that other mechanisms may also be utilized to determine whether the target PTE corresponds to the monitored VA range. In this example, let it be assumed that the virtual page mapped by the target PTE falls within the VA range of interest, which is OxBOOO through OxDOOO.
[0056] The procedure continues from step 330 to step 335. At step 335, hardware agent 140 sends a valid snoop response indicating that it stores the target PTE (e.g., a corresponding cache line). In an embodiment, the snoop monitor module 215 of PCT / US25 / 57631 02 December 2025 (02.12.2025)
[0057] 10 hardware agent 140 sends the valid snoop response to CCI 135 via interface 205. In an embodiment, the hardware agent 140 sends the valid snoop response even though it does not actually store the target PTE, thereby enabling hardware agent 140 to manipulate the target PTE to generate a modified (i.e., poisoned) PTE, as will be described below. Because the hardware agent 140 provides the valid snoop response to the CCI 135, the read request is not transmitted to memory 130 to obtain the target PTE from page tables 165.
[0058] The procedure continues from step 335 to step 340. At step 340, the hardware agent 140 generates the modified (i.e., poisoned) PTE. In an embodiment, the PTE manipulator module 225 of hardware agent 140 generates the modified PTE. In an embodiment, the modified PTE is different from the original PTE stored in memory 130. For example, the modified PTE may store a PFN and / or attributes that are different from those of the original PTE. The attributes may include, but are not limited to, permissions, cacheability, and memory type.
[0059] In an embodiment, the PTE manipulator module 225 may generate the modified PTE such that the PFN included in the modified PTE corresponds to any preferred PA. For example, , the PTE manipulator module 225 may generate the modified PTE such that the PFN included in the modified PTE corresponds to a particular I / O device (not shown). Although the example indicates that the PFN of the modified PTE might correspond to an I / O device, it is expressly contemplated that the PFN of the modified PTE may correspond to any PA.
[0060] In an embodiment, the memory access module 220 of hardware agent 140 may first obtain the original PTE from a page table 165 stored in memory 130 via CCI 135 and interface 205. The PTE manipulator module 225 may then analyze the original PTE to generate the modified PTE according to the one or more embodiments as described herein.
[0061] Fig. 4 illustrates an example of an original PTE and a modified PTE according to the one or more embodiments as described herein. Original PTE 400A and modified PTE 400B each include fields 405, 410, 415, and 420. For this example, let it be assumed that original PTE 400A and modified PTE 400B correspond to an entry obtained from the lowest-level page table of a page table walk.
[0062] Field 405 may indicate the PFN associated with the PTE. For example, original PTE 400A indicates that the PFN is PFN_ORIGINAL. Field 410 may indicate the access permissions for the PTE. For example, original PTE 400A indicates that the PCT / US25 / 57631 02 December 2025 (02.12.2025)
[0063] 11 access permissions are read and write. Field 415 may indicate whether the memory location corresponding to the PTE is cacheable. For example, original PTE 400A indicates that the corresponding memory location is not cacheable. Field 420 may indicate whether the PTE is terminal. A value of true in field 420 indicates that the PTE is the final entry in the page table walk. A value of false in field 420 indicates that additional PTEs must be accessed to complete the page table walk. For the example of Fig. 4, original PTE 400A indicates that the corresponding PTE is the final entry in the page table walk.
[0064] Modified PTE 400B may be generated by PTE manipulator module 225 in accordance with the one or more embodiments as described herein. As depicted in Fig.
[0065] 4, the values in fields 410, 415, and 420 are the same in original PTE 400A and modified PTE 400B. However, the PFN value in field 405 differs. Specifically, PTE manipulator module 225 modifies the PFN such that field 405B stores a value of PFN_I / O_DEVICE corresponding to a particular I / O device (not shown). As a result, the modified PTE causes subsequent transactions to be directed to the particular I / O device, as described in further detail below.
[0066] Fig. 5 illustrates another example of an original PTE and a modified PTE according to the one or more embodiments as described herein. Similar to Fig. 4, original PTE 500A and modified PTE 500B each include fields 405, 410, 415, and 420. For this example, let it be assumed that original PTE 500A and modified PTE 500B correspond to an entry obtained from a higher- level page table (e.g., a page global director}' table) of a page table walk for a memory mapping, not an I / O device utilized in relation to the example of Fig. 4.
[0067] Modified PTE 500B may be generated by PTE manipulator module 225 in accordance with the one or more embodiments as described herein. As shown in Fig.
[0068] 5, the values in fields 410 and 415 are the same in original PTE 500A and modified PTE 500B. However, the PFN value in field 405 and the value in terminal field 420 differ. Specifically, PTE manipulator module 225 modifies the PFN such that field 405B stores a value PFN_NEW_MEMORY MAPPING corresponding to a new memory location (not shown) instead of an original memory location (e.g., PFN_ORIGINAL corresponding to an initial memory location that is different from the new memory location). In addition, the PTE manipulator module 225 changes the terminal value from false in the original PTE 500A to true in the modified PTE 500B. PCT / US25 / 57631 02 December 2025 (02.12.2025)
[0069] 12
[0070] Because higher-level page tables correspond to broader VA ranges, modifying a higher- level PTE to appear terminal causes a larger range of VAs to be mapped to the same physical frame number (e.g., PFN_NEW_MEMORY_MEMORY_MAPPING). As a result, the modified PTE appears, to the CCI 135, to be the final PTE of the page table walk even though the original PTE would have referenced additional page tables to complete the page table walk. Therefore, the hardware agent 140 can assign or redirect a wider set of VAs, when compared to lower-level PTEs, to the modified PFN (e.g., PFN_NEW_MEMORY_MAPPING) by manipulating the terminal value to true for PTEs originating from higher-level page tables.
[0071] Referring back to Fig. 3, the procedure continues from step 340 to step 345. At step 345, the hardware agent 140 provides the modified PTE to CPU 105 to update its TLB 115. For this example, let it be assumed that the hardware agent provides modified PTE 400B to CPU 105. In an embodiment, the hardware agent 140 provides the modified PTE 400B to the CCI 135 via interface 205, and the CCI 135 forwards the modified PTE to the CPU 105 in response to the outstanding read request for the target PTE that was issued by the CPU 105 as part of the page table walk. The MMU 110 may then update TLB 115 with a new TLB entry that includes the PFN and attributes from the modified PTE 400B. As a result, the MMU 110 may subsequently translate the monitored VA, for later transactions, to a modified (poisoned) PA using the PFN from the new TLB entry of the TLB 115. For example, the MMU may use the PFN with the page offset portion of the VA to translate the VA to the modified (poisoned) PA. The procedure then ends at step 350.
[0072] Therefore, the one or more embodiments as described herein provide an improvement to address translation manipulation in computing systems. Specifically, in conventional systems and techniques, address manipulation is typically performed at the software level, resulting in long access times or uncoordinated access. While conventional hardware-level techniques attempt to address the limitations of softwarebased approaches, they tend to be rigidly tied to specific devices or platforms. The one or more embodiments as described herein overcome these deficiencies by performing address translation manipulation on the fly and at the cache-coherency level, thereby providing a more efficient and flexible virtualization technique when compared to conventional approaches. Accordingly, the one or more embodiments as described herein provide an improvement in the existing technological field of computer system address translation manipulation. PCT / US25 / 57631 02 December 2025 (02.12.2025)
[0073] 13
[0074] As mentioned above, the MMU 110 may subsequently translate the monitored VA, for later transactions, to the modified (poisoned) PA using the new TLB entry stored in the TLB 115. Fig. 6 is a flow diagram of a sequence of steps for processing a VA corresponding to a modified (poisoned) PA according to the one or more embodiments as described herein. Procedure 600 starts at step 605 and continues to step 610. At step 610, the MMU 110 accesses TLB 115 to translate the VA, associated with a transaction (e.g., memory access request or I / O request), to a PA. For the example in relation to Fig. 6, let it be assumed that the VA for the transaction falls within the monitored VA range of OxBOOO through OxDOOO.
[0075] The procedure continues from step 610 to step 615. At step 615, the MMU 110 translates the VA to the modified PA based on the translation information stored in the TLB 115. As explained above in relation to the flow diagram of Fig. 3, the hardware agent 140 generates the modified PTE that results in the new TLB entry of TLB 115. Therefore, in this example, the MMU 110 translates the VA to the modified PA using the PFN of the new TLB entry. For example, the MMU 110 may translate the VA to the modified PA based on the PFN of the new TLB entry with a page offset portion of the VA. If, for example, the VA does not map to a TLB entry in the TLB 115, the page table walk would proceed as described above.
[0076] The procedure continues from step 615 to step 620. At step 620, the device corresponding to the modified PA receives the transaction. Continuing with the example, the I / O device (not shown) receives the transaction because the monitored VA is translated to the modified PA that corresponds to the I / O device. Although the example describes the I / O device receiving the transaction, it is expressly contemplated that the transaction may be transmitted to any type of device or memory location that corresponds to the modified (poisoned) PA.
[0077] The procedure continues from step 620 to step 625. At step 625, the device corresponding to the modified PA executes one or more functions for the received transaction. Continuing with the example, the I / O device corresponds to the modified PA and thus receives the transaction. In an embodiment, the I / O device executes one or more functions for the received transaction. The functions may include, but are not limited to, forwarding the transaction to another device, emulating the behavior of a particular device, or performing other processing as appropriate. The procedure then ends at step 630. PCT / US25 / 57631 02 December 2025 (02.12.2025)
[0078] 14
[0079] Therefore, the hardware agent 140 controls the processing of particular transactions corresponding to VAs of interest that are being monitored at the cachecoherency level, and does so without modifying the software layer (e.g., application layer, hypervisor layer, operating system layer, etc.) that interacts with the hardware. As such, the one or more embodiments as described herein provide an improvement in the existing technological field of computer system address translation manipulation for transaction control. This hardware-level implementation enables coordinated transaction handling without software intervention, thereby reducing translation latency and minimizing or even eliminating page table walks that would otherwise occur in conventional systems.
[0080] It should be understood that a wide variety of adaptations and modifications may be made to the techniques. For example, the steps of the flow diagrams as described herein may be performed sequentially, in parallel, or in one or more varied orders. In general, functionality may be implemented in software, hardware or various combinations thereof.. Hardware implementations may include logic circuits, application specific integrated circuits, and / or other types of hardware components. Further, combined software / hardware implementations may include both electronic device-executable instructions stored in a non-transitory electronic device-readable medium, as well as one or more hardware components. Above all, it should be understood that the above description is meant to be taken only by way of example.
[0081] What is claimed is:
Claims
CLAIMS1. A method for enabling address translation manipulation in a computing system without requiring software hypervisors or hardware virtualization extensions, the method comprising: detecting, by a hardware agent residing in a shared cache-coherence domain of a computer processing unit (CPU) cluster, a coherence snoop request issued by a cache coherent interconnect (CCI); determining, by the hardware agent, that the coherence snoop request identifies a target page table entry (PTE) corresponding to a monitored virtual address range; generating, by the hardware agent, a modified PTE that is different from an original PTE stored in a main memory, the modified PTE encoding at least one of (1) a modified physical frame number that is different from an original frame number of the original PTE and (2) a modified set of memory attributes that are different from an original set of memory attributes of the original PTE, wherein the modified set of memory attributes including one or more of access permissions, cacheability, and memory type; providing, by the hardware agent, the modified PTE as a valid coherence response to the coherence snoop request; and injecting a modified address translation, which is based on the modified PTE, into the TLB.
2. The method of claim 1, wherein the coherence snoop request includes a physical address of the target PTE and the physical address is within a physical address range for a plurality of target PTEs corresponding to the monitored virtual address range.
3. The method of claim 1, wherein the modified address translation of the TLB is used to translate a particular virtual address to a particular physical address.
4. The method of claim 3, wherein the particular physical address is associated with an input / output (I / O) device.
5. The method of claim 1, further comprising: retrieving, by the hardware agent and in response to detemrining that the coherence snoop request identifies the target PTE, a cache line from the main memory comprising the original PTE; and analyzing the original PTE to generate the modified PTE.
6. The method of claim 1, wherein before detecting the coherence snoop request, the method further comprising: determining, by a memory management unit (MMU) in the CPU cluster, that a virtual address translation is not stored in the TEB; initiating, by the MMU, a hardware page table walk; and generating, by the CCI, the coherence snoop request.
7. The method of claim 1, further comprising: determining, by the hardware agent, that the coherence snoop request does not identify the target PTE corresponding to the monitored virtual address range; performing and completing, by a memory management unit (MMU) in the CPU cluster, a hardware page table walk for a virtual address translation using the original PTE retrieved from the main memory.
8. The method of claim 1, wherein the modified PTE is formatted to include value terminal entry bits that terminate a hardware page table walk.
9. The method of claim 1, wherein the target PTE is an entry from a page global directory, a page upper directory, a page middle directory, or a page table.
10. A system for enabling hardware-level manipulation of virtual-to-physical address translations without the use of a hypervisor, the system comprising: a central processing unit (CPU) cluster comprising a memory management unit (MMU) configured to perform hardware-based multi-level page table walks to translate virtual addresses into physical addresses; a main memory storing operating system-managed page tables comprising a set of one or more page table entries (PTEs) associated with a set of virtual address ranges; anda hardware agent coupled to the CPU cluster via a cache coherent interconnect (CCI), the hardware agent configured to: monitor coherence snoop requests issued by the CCI in response to initiation of performance of a particular hardware-based multi-level page table walk; determine a particular coherence snoop for a target PTE corresponding to a monitored virtual address; generate a modified PTE data that is different from an original PTE, of the set of one or more PTEs stored at the main memory, wherein the modified PTE includes at least one of (1) a modified physical address that is different from an original physical address of the original PTE and (2) one or more modified memory attributes that are different form original memory attributes of the original PTE; and the MMU further configured to use the modified PTE to cache a modified address translation into a translation lookaside buffer (TLB).11 . The system of claim 10, wherein the snoop request includes a physical address of the target PTE and the physical address corresponds to the monitored virtual address.
12. The system of claim 10, wherein the modified address translation of the TLB is used to translate a particular virtual address to a particular physical address.
13. The system of claim 12, wherein the particular physical address is associated with an input / output (I / O) device.
14. The system of claim 10, wherein the hardware agent further configured to: retrieve, in response to determining the particular coherence snoop for the target PTE, a cache line from the main memory comprising the original PTE; and generate the modified PTE based on an analysis of the original PTE.
15. The system of claim 10, wherein before detecting the coherence snoop request, the system further comprising: the MMU further configured to determine that a virtual address translation is not stored in the TLB; the MMU further configured to initiate the particular hardware-based multilevel page table walk; and the CCI configured to generate the particular coherence snoop request in response to initiating the particular hardware-based multi-level page table walk.
16. The system of claim 10, further comprising: the hardware agent further configured to determine that the particular coherence snoop request does not identify the target PTE corresponding to the monitored virtual address range; the MMU further configured to complete performance of the particular hardware-based multi-level page table walk using the original PTE retrieved from the main memory.
17. The system of claim 10, wherein the modified PTE is formatted to include value terminal entry bits that terminate the hardware page table walk.
18. The system of claim 10, wherein the target PTE is an entry from a page global directory, a page upper directory, a page middle directory, or a page table.
19. A hardware module for dynamically modifying virtual-to-physical address translations in a computing system comprising a CPU cluster and a main memory, the hardware module comprising: an interface configured to: communicate with a cache coherent interconnect (CCI) that links the hardware module and the CPU cluster, and communicate with the main memory; one or more hardware components configured to:receive coherence snoop requests generated during a hardware-based page table walk performed by a memory management unit (MMU) of the CPU; identify an incoming snoop request, generated in response to performing the hardware-based page table walk, that corresponds to a target page table entry (PTE) involved in a virtual address translation of interest; obtain an original PTE data from main memory in response identifying the incoming snoop request; modify at least one of a physical frame number and memory attributes encoded in the original PTE; generate a manipulated PTE in response to modifying at least one of the physical frame number and the memory attributes encoded in the original PTE; and transmit the manipulated PTE as a valid cache line response to the CPU cluster, wherein the manipulated PTE is stored in a translation lookaside buffer (TEB) without modifying page tables stored in the main memory.
20. The hardware module of claim 19, wherein the one or more hardware components are further configured to modify the physical frame number to generate a modified physical frame number that corresponds to a particular physical address associated with an input / output (I / O) device.