A method and system for managing address translation cache based on multi-granularity hash table

Abstract

The present application relates to the technical field of input / output virtualization, in particular to an address translation cache management method and system based on multi-granularity hash table, which provides multiple address translation tables, each of which stores address mapping entries of fixed size; when an address translation response is received, the corresponding table is stored according to the entry size; when a virtual address to be converted is received, parallel hash search is performed in multiple tables simultaneously; if a matching entry is found, the final physical address is obtained by splicing the physical address base address and the low bit offset of the virtual address, and end-to-end access is directly performed. The present application solves the problem of uncertain hash key length caused by the non-fixed size of address mapping entries, realizes the unified management of different granularities, shortens the access path from endpoint device→switch→root complex to local table lookup of the device, reduces the access delay, and realizes efficient storage and search with low hardware cost.

Description

Technical Field

[0001] This invention relates to the field of input / output (I / O) virtualization technology, and in particular to an address translation cache management method and system based on a multi-granularity hash table. Background Technology

[0002] In Peripheral Component Interconnect Express (PCIe) devices (Endpoints, EPs) that support Address Translation Services (ATS), endpoints need to use a virtual address (VA) when accessing host memory or performing peer-to-peer (P2P) communication. This virtual address needs to be translated into a physical address (PA) by the Input / Output Memory Management Unit (IOMMU) in the Root Complex (RC) before it can access actual memory. A typical address translation process is as follows: the endpoint first sends an ATS Request to the Root Complex. This request may be forwarded through multiple PCIe switches to reach the Root Complex. The IOMMU in the Root Complex looks up the mapping entry and returns it to the endpoint via an ATS Response along the original path. Because the entire link is long, and the root complex and IOMMU need to handle a large number of translation requests from different endpoint devices, performance bottlenecks can easily form, resulting in a significant increase in address translation latency.

[0003] Furthermore, the size (SIZE) of the address mapping entry returned by the root complex is not fixed; it can be 4KB, 2MB, 1GB, or other values. The storage structure used to cache address mapping entries in the endpoint device uses only a single hash table. Because different entries have different SIZEs, the hardware cannot determine which bits of the virtual address to use to calculate the hash key: if the SIZE is 4KB, the high 52 bits of the virtual address are needed as the key; if the SIZE is 2MB, the high 43 bits are needed. Similarly, during a query, the hardware cannot determine which bits of the virtual address to use for matching. This makes it impossible for a single hash table to efficiently store and query address mapping entries of different granularities simultaneously.

[0004] In existing technologies, some solutions split all entries into the smallest granularity (e.g., 4KB) for storage, but this significantly increases the number of entries, wastes storage space, and reduces query efficiency. Other solutions use multi-level tables or range trees, but these are complex to implement in hardware and suffer from high latency. Therefore, how to achieve efficient storage and querying of entries mapped to different granularities of addresses without increasing hardware complexity is a pressing technical problem that needs to be solved. Summary of the Invention

[0005] To address one of the aforementioned technical problems, the present invention adopts the following technical solution: According to one aspect of the present invention, an address translation cache management method based on a multi-granularity hash table is provided, applied in an endpoint device, comprising the following steps: Multiple address translation tables are provided, each configured to store address mapping entries of a fixed size, and the address mapping entry sizes of different address translation tables are different; When an address translation response is received from the root complex, the virtual address, physical address, and address mapping entry size are parsed out, and the address mapping entry is stored in one or more corresponding address translation tables according to the address mapping entry size. When an input virtual address to be translated is received, a parallel hash lookup is performed in multiple address translation tables to determine whether there is an address mapping entry that matches the input virtual address. If a matching address mapping entry is found, the final physical address is obtained by concatenating the physical address base address stored in the matching address mapping entry with the low-order offset of the input virtual address, and end-to-end access is performed directly through this physical address.

[0006] According to another aspect of the present invention, an address translation cache management system based on a multi-granularity hash table is provided, applied in an endpoint device, comprising: The translation table module provides multiple address translation tables. Each address translation table is configured to store address mapping entries of a fixed size, and the address mapping entry sizes of different address translation tables are different. The parsing module is used to parse the virtual address, physical address, and address mapping entry size when it receives an address translation response from the root complex, and store the address mapping entry into one or more corresponding address translation tables according to the address mapping entry size; The lookup module is used to perform parallel hash lookups in multiple address translation tables simultaneously when an input virtual address to be translated is received, in order to determine whether there is an address mapping entry that matches the input virtual address. The address concatenation module is used to, if a matching address mapping entry is found, concatenate the physical address base address stored in the matching address mapping entry with the low-order offset of the input virtual address to obtain the final physical address, and directly perform end-to-end access through the physical address.

[0007] This invention has at least one of the following beneficial effects: First, eliminate the storage and query difficulties caused by the variable size of address mapping entries, and achieve unified management at different granularities.

[0008] Background technology indicates that the address mapping entry size (SIZE) returned by the root complex is not fixed (e.g., 4KB, 2MB, 1GB, etc.). If a single hash table is used, the hardware cannot determine which bits of the virtual address to use as the hash key, resulting in inefficient storage and retrieval. This invention provides multiple address translation tables, each configured to store address mapping entries of a fixed size, with different entry sizes for different tables. When an address translation response is received, the entry is stored in one or more corresponding address translation tables based on the parsed address mapping entry size. Thus, each table stores only one fixed-size entry, and storage can utilize a fixed-length hash key corresponding to that table (e.g., the high 52 bits of the virtual address for a 4KB table, and the high 43 bits for a 2MB table). Retrieval also uses a fixed-length hash key for parallel hash lookup. Compared to existing solutions where a single table cannot handle different SIZEs, this invention fundamentally solves the problem of uncertain hash key length caused by variable SIZEs, achieving unified and efficient management of address mapping entries of different granularities.

[0009] Second, shorten the access path after address translation to achieve end-to-end direct memory access.

[0010] Traditional address translation processes require a long link through endpoint devices → switches → root complex → IOMMU, resulting in significant round-trip latency and potential bottlenecks. In this invention, after finding an address mapping entry matching the input virtual address in multiple address translation tables, the final physical address is obtained by concatenating the physical address base address stored in the matching entry with the low-order offset of the input virtual address. End-to-end access is then performed directly through this physical address. Therefore, endpoint devices no longer need to send address translation requests to the root complex again; they can directly use the locally cached physical address to initiate direct memory access operations to host memory or peer devices. Compared to existing technologies where each address translation requires a long round trip, this invention shortens the access path after address translation to a local table lookup and direct access, significantly reducing access latency and avoiding bottlenecks in the root complex and IOMMU.

[0011] Third, achieve efficient storage and retrieval of multi-granularity address mapping with low hardware cost and low query latency.

[0012] In this invention, each of the multiple address translation tables adopts a fixed-granularity hash table structure with a fixed hash key length. Hardware implementation can utilize simple hash functions (such as modulo operations) and comparators. During a query, all tables undergo parallel hash lookups simultaneously, completing the lookup operation within one clock cycle. Compared to existing solutions using multi-level tables or interval trees, this invention avoids complex multi-level traversal and interval judgment logic. Compared to solutions that split all entries into the smallest granularity, this invention does not require a significant increase in the number of entries, thus saving storage space. Therefore, this invention achieves efficient storage and retrieval of address mapping entries at different granularities with extremely low hardware costs (each table requires only a small number of storage units and comparison logic) and constant low query latency (parallel table lookups, not linearly increasing with the number of tables), and is easily implemented in endpoint devices. Attached Figure Description

[0013] To more clearly illustrate the technical solutions in the embodiments of the present invention, the accompanying drawings used in the description of the embodiments will be briefly introduced below. Obviously, the accompanying drawings described below are only some embodiments of the present invention. For those skilled in the art, other drawings can be obtained based on these drawings without creative effort.

[0014] Figure 1 This is a flowchart of an address translation cache management method based on a multi-granularity hash table, provided as an embodiment of the present invention.

[0015] Figure 2 The flowchart illustrates the multi-granularity table structure and its creation and query methods provided in this embodiment of the invention.

[0016] Figure 3 A flowchart is provided for the pending request filtering table mechanism in embodiments of the present invention.

[0017] Figure 4 This is a structural block diagram of an address translation cache management system based on a multi-granularity hash table, provided for an embodiment of the present invention. Detailed Implementation

[0018] The technical solutions of the embodiments of the present invention will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of the present invention, and not all embodiments. Based on the embodiments of the present invention, all other embodiments obtained by those skilled in the art without creative effort are within the scope of protection of the present invention.

[0019] As one possible embodiment of the present invention, such as Figure 1 and Figure 2As shown, an address translation cache management method based on a multi-granularity hash table is provided and applied to endpoint devices, including the following steps: The method in this embodiment is applied to the Address Translation Services (ATS) process of Peripheral Component Interconnect Express (PCIe) devices. The endpoint (EP) can be a network interface card (NIC), NVMe solid-state drive (NVMe SSD), or other devices that support Direct Memory Access (DMA). The Address Translation Cache (ATC) stores address mapping entries obtained from the Input / Output Memory Management Unit (IOMMU) of the Root Complex (RC).

[0020] S100: Provides multiple address translation tables, each configured to store address mapping entries of a fixed size, with different address mapping entry sizes for different address translation tables.

[0021] Specifically, the preset address mapping entry size of multiple address translation tables can include at least two of the following: 4KB, 64KB, 2MB, and 1GB, and the preset address mapping entry size is configurable.

[0022] This step introduces a structure design using multiple fixed-granularity tables. In traditional single hash tables, because the address mapping entry size (SIZE) is not fixed (e.g., 4KB, 2MB, 1GB, etc.), the hardware (i.e., PCIe endpoint devices) cannot determine which bits of the virtual address to use as the hash key. This invention solves this fundamental problem by providing multiple tables, each specifically storing entries of a fixed SIZE. For example, four tables can be configured: a 4KB table, a 64KB table, a 2MB table, and a 1GB table. The 4KB table stores entries with a SIZE of 4KB, using the high 52 bits of the virtual address as the hash key; the 2MB table stores entries with a SIZE of 2MB, using the high 43 bits of the virtual address as the hash key. The preset address mapping entry size can be configured via software to adapt to the address mapping granularity requirements of different server architectures (e.g., Intel, AMD, ARM, etc.). For example, in some ARM servers, only 4KB and 2MB granularities may be needed, in which case other tables can be disabled to save hardware resources.

[0023] S200: When an address translation response is received from the root complex, the virtual address, physical address, and address mapping entry size are parsed out, and the address mapping entry is stored in one or more corresponding address translation tables according to the address mapping entry size.

[0024] This step is the entry point for writing address mapping entries to the ATC. The Address Translation Response (ATS Response) contains three core elements: Virtual Address (VA), Physical Address (PA), and address mapping entry size (SIZE). Both VA and PA are starting addresses (base addresses). For example, when SIZE = 2MB, the lower 21 bits of VA are 0 (2MB aligned). After the hardware parses these three elements, it determines which table to store the data in based on the SIZE. If the SIZE is equal to the preset granularity of a table, it is stored directly; if the SIZE is not equal to any preset granularity, truncated storage is required (see subsequent steps).

[0025] S200, specifically includes: S210a: If the size of the address mapping entry is equal to the size of the preset address mapping entry in an address translation table, then the address mapping entry is directly stored in the address translation table.

[0026] This step handles cases where the SIZE perfectly matches the preset granularity. For example, when the ATS Response returns SIZE=2MB, the entry can be directly stored in the 2MB address translation table. During storage, the high 43 bits of the virtual address are extracted as the hash key (VA>>21), and the high 43 bits of the physical address are extracted as the physical address base address (PA_base). Here, ">>" is the right shift operator, indicating that the binary number is shifted to the right by a specified number of bits. For example, VA>>21 means removing the low 21 bits of VA and retaining the high 43 bits. For instance, if VA=0x18000000000 and PA=0x200000000000, then when storing in the 2MB table, the stored VA hash key is 0xC0000 (0x18000000000>>21), and the stored PA_base is 0x100000 (0x200000000000>>21). This direct storage method simplifies the processing flow and reduces storage overhead.

[0027] S210b: If the size of the address mapping entry is not equal to the preset address mapping entry size of any address translation table, then select the maximum value T that is less than or equal to the size of the address mapping entry from all preset address mapping entry sizes, and split the address mapping entry into multiple sub-address mapping entries of size T.

[0028] This step handles cases where the SIZE does not match the preset granularity. The PCIe protocol allows any SIZE value (e.g., 4MB, 8MB), while ATC's preset granularity is finite. To ensure that all SIZE entries can be stored, larger SIZE entries need to be split into multiple sub-entries conforming to the preset granularity. The splitting principle is: select the largest preset granularity T less than or equal to the original SIZE, and then split the original entry into multiple sub-entries of size T. For example, preset granularities include 4KB, 64KB, 2MB, and 1GB. If the original SIZE = 4MB, then the largest preset value less than or equal to 4MB is 2MB, therefore T = 2MB. 4MB = 2 × 2MB, so the original entry is split into two sub-entries of size 2MB. If the original SIZE = 8MB, then T = 2MB is still selected, splitting into four sub-entries. This backward-compatible splitting strategy ensures that address mapping entries of any SIZE can be correctly processed.

[0029] S220b: Based on the input virtual address corresponding to the currently received address translation response, determine which sub-address mapping entry the input virtual address falls within, and store the sub-address mapping entry into an address translation table with a preset address mapping entry size of T.

[0030] This step determines which sub-address mapping entry the input virtual address should correspond to. Since the original entry is split into multiple sub-entries, each covering a different address range, the hardware only needs to store the sub-entry that matches the currently requested virtual address, instead of storing all sub-entries. This on-demand storage strategy saves storage space. For example, the original VA = 0x10000000000, SIZE = 4MB, covering the address range [0x10000000000, 0x10000400000]. Assuming the input virtual address VA = 0x10000200000 (falling in the second 2MB interval), then the sub-entry index = floor((0x10000200000 - 0x10000000000) / 0x200000) = 1, where floor() is the floor function, rounding down to the largest integer not greater than the given value. Therefore, the hardware only stores the second sub-entry, not the first. If a subsequent access falls within the address range of the first sub-entry, an ATC miss will be triggered, and the first sub-entry will be stored again as needed.

[0031] S230b: The virtual address base address of this sub-address mapping entry is equal to the original virtual address base address plus an offset, which is an integer multiple of T, down-aligned to the low-order part of the input virtual address. The physical address base address of this sub-address mapping entry is equal to the original physical address base address plus the same offset.

[0032] This step is the core calculation for truncation storage. By calculating the VA base address and PA base address of the sub-entry, the entry that originally covered a large address range is converted into a sub-entry covering an address range of size T. The offset is calculated as: Offset = VA & ~(T-1) (that is, the low-order part of VA is aligned down to an integer multiple of T). Here, "&" is the bitwise AND operator, which means performing a bitwise AND operation on the binary bits of two numbers one by one. The result bit is 1 only when both corresponding bits are 1; "~" is the bitwise NOT operator, which means changing 0 to 1 and 1 to 0 in binary bits. For example, T = 2MB, T-1 = 0x1FFFFF, ~(T-1) means that the high 43 bits are all 1 and the low 21 bits are all 0. If VA = 0x10000200000, then the offset = VA & ~0x1FFFFF = 0x10000200000 & 0xFFFFFFFFFFE00000 = 0x00200000 (2MB aligned). Sub-entry VA base address = original VA base address + offset = 0x10000000000 + 0x00200000 = 0x10000200000. Sub-entry PA base address = original PA base address + offset. Assuming the original PA = 0x20000000000, then the sub-entry PA base address = 0x20000000000 + 0x00200000 = 0x20000200000. When storing data into a 2MB table, the stored VA hash key is the high 43 bits of the sub-entry VA base address (0x10000200000>>21 = 0x80010), and the stored PA_base is the high 43 bits of the sub-entry PA base address (0x20000200000>>21 = 0x100001).

[0033] This embodiment achieves efficient storage of address mapping entries of different sizes through a structure design of multiple fixed-granularity tables. Each table uses a fixed-length hash key, simplifying hardware design; a backward-compatible truncated storage strategy ensures that address mapping entries of any size can be processed correctly; and an on-demand storage strategy saves storage space and avoids unnecessary entry creation.

[0034] S300: When an input virtual address to be converted is received, a parallel hash lookup is performed in multiple address translation tables to determine whether there is an address mapping entry that matches the input virtual address.

[0035] This step introduces the core idea of ​​parallel hash lookup. Since multiple tables of different granularities exist simultaneously in the ATC, and the input virtual address may match an entry in any of these tables, the hardware needs to perform lookups in all tables concurrently. Parallel lookup fully utilizes hardware parallelism, completing multi-table queries without increasing critical path latency. For example, when a DMA request arrives carrying virtual address VA=0x18000000000, the hardware simultaneously initiates lookup operations in the 4KB, 64KB, 2MB, and 1GB tables. All table lookups are completed in parallel within one clock cycle.

[0036] Specifically, parallel hash lookup includes: S301: For each address translation table, determine the high-order bits used for hash calculation in the input virtual address based on the preset address mapping entry size of the address translation table.

[0037] This step defines the hash key extraction rules for each table during lookups. Each table has a different preset granularity, therefore different numbers of bits in the virtual address are needed as the hash key. This rule must be consistent with the rules used during storage to ensure that entries stored in a certain table during storage can be found in the same table during queries. For example: 4KB table: Uses the high 52 bits of the virtual address as the hash key, i.e., VA[63:52] (or VA>>12). VA[63:52] is a bit-field slice representation, representing the 63rd to 52nd bits (12 bits) of the virtual address VA.

[0038] 64KB table: Uses the high 48 bits of the virtual address as the hash key, i.e. VA[63:48] (or VA>>16).

[0039] 2MB table: Uses the high 43 bits of the virtual address as the hash key, i.e. VA[63:43] (or VA>>21).

[0040] 1GB table: Uses the high 34 bits of the virtual address as the hash key, i.e. VA[63:34] (or VA>>30).

[0041] Taking VA=0x18000000000 as an example: 4KB table hash key=0x18, 64KB table hash key=0x180, 2MB table hash key=0xC00, 1GB table hash key=0x1800.

[0042] S302: Input the high-order bits into the hash function to obtain the index in the table, and read the address mapping entry at that index position.

[0043] This step converts the hash key into its actual storage location in the address translation table. The hash function can use a simple modulo operation (e.g., hash key modulo table size) or a more complex hash algorithm to ensure uniform distribution. For example, if a 2MB table has 1024 entries and the hash key is 0xC00, then the index is 0xC00 mod 1024 = 768. Here, "mod" is the modulo operator, representing the remainder. The hardware reads the corresponding address mapping entry from the address translation table based on this index. If the index position is empty (invalid entry), the lookup in that table is not successful.

[0044] S303: Compare whether the base address of the virtual address stored in the address mapping entry is equal to the high-order part of the input virtual address. If they are equal, it is considered a match.

[0045] This step is the core verification process for address mapping entry matching. Due to hash collisions, the read entry may not match the query request. Therefore, it's necessary to compare whether the stored virtual address base address is equal to the high-order bits of the input virtual address. For example, in a 2MB table, the stored VA base address is 0xC00 (high 43 bits), and the high 43 bits of the input VA are also 0xC00. They are equal, so the verification passes. Furthermore, the physical address base address and valid bit range can be further verified to ensure a complete match. If all verifications pass, the entry is a match; otherwise, the entry does not match, and other tables are checked (but because of parallel lookups, the results of all tables are obtained simultaneously).

[0046] This embodiment achieves efficient querying of multiple fixed-granularity tables through a parallel hash lookup mechanism. Parallel lookup fully utilizes hardware parallelism, allowing queries on multiple tables to be performed simultaneously without increasing query latency. Furthermore, the hash key extraction rules are consistent with the storage rules, ensuring search accuracy. Truncated entries can also be correctly matched during queries, guaranteeing complete coordination between the storage and query mechanisms.

[0047] S400: If a matching address mapping entry is found, the final physical address is obtained by concatenating the physical address base address stored in the matching address mapping entry with the low-order offset of the input virtual address, and end-to-end access is performed directly through the physical address.

[0048] This step completes the final step of address translation. The matched address mapping entry stores the physical address base address (PA_base), while the input virtual address contains the low-order offset. The final physical address = PA_base + (VA & (SIZE - 1)). For example, for a 2MB entry, SIZE = 2MB, SIZE - 1 = 0x1FFFFF. If PA_base = 0x100000 (high 43 bits), the actual physical address base address is 0x100000 << 21 = 0x20000000000. The input VA = 0x18000000000, the low-order offset = VA & 0x1FFFFF = 0x00000 (because the low 21 bits of VA are 0), therefore the offset = 0. The final PA = 0x20000000000 + 0 = 0x20000000000. If VA = 0x180001000 and offset = 0x1000, then PA = 0x20000001000. After obtaining the final physical address, the endpoint device directly uses this address to initiate a DMA operation to access host memory or peer devices without going through the root complex. This achieves end-to-end direct memory access, significantly reducing access latency.

[0049] This embodiment fundamentally solves the problem of uncertain hash key length caused by the variable size of address mapping entries by providing multiple fixed-granularity address translation tables. Parallel hash lookup fully utilizes hardware parallelism, completing multiple table queries within a single cycle without increasing critical path latency. The truncated storage strategy is compatible with entries of arbitrary size, and on-demand storage saves hardware resources. This embodiment achieves efficient and unified management of address mapping entries of different granularities at extremely low hardware cost.

[0050] The multi-fixed-granularity table mechanism provided in the above embodiments solves the storage and retrieval problem of address mapping entries of different sizes by using parallel hash lookup and on-demand truncation storage. However, in actual PCIe devices, even with efficient multi-granularity tables, when the address translation cache misses, an address translation request (ATSRequest) still needs to be sent to the root complex. If multiple subsequent requests within the same 4KB address range send ATSRequests independently during the microsecond wait for a response, it will cause a large number of duplicate PCIe transactions, wasting bandwidth and increasing the load on the root complex. Therefore, another possible embodiment of the present invention, based on the previous embodiment, further introduces a pending request filter table and a Ready mechanism to aggregate duplicate requests within the same address range and reduce the response latency of subsequent requests. The newly introduced embodiment is described in detail below.

[0051] As another possible embodiment of the present invention, such as Figure 3As shown, a pending request filter table is maintained, which contains one or more entries, each corresponding to a 4KB address range, to record address translation requests that have been sent but for which no response has been received.

[0052] This embodiment, building upon the multi-granularity table of the previous embodiment, adds a pending request filtering table mechanism to handle request aggregation after a primary ATC miss. The pending request filtering table can be implemented using Content-Addressable Memory (CAM) or a hash table, with a 4KB base address as the lookup key. Each entry contains at least the following fields: 4KB base address (e.g., 48 bits), Request ID (e.g., 16 bits), Ready flag (1 bit), and wait queue pointer. 4KB is the default page size defined in the PCIe ATS protocol, aligned with the smallest mapping granularity of the IOMMU. Assigning each entry a 4KB range ensures that any virtual addresses falling within the same 4KB page are aggregated into the same entry.

[0053] Specifically, the capacity of the pending request filter table is a fixed value. When the table is full and a new entry needs to be created, the Least Recently Used (LRU) strategy or a random replacement strategy is used to evict existing entries.

[0054] The number of entries in the pending request filter table can be configured to 32, 64, or 128 to match the number of concurrent pending requests on a typical PCIe device. When all entries are in a valid state (i.e., waiting for a response) and a new entry needs to be created, one must be selected for eviction. When using a Least Recently Used (LRU) strategy, each entry can be appended with a timestamp or access counter; when using random replacement, a Linear Feedback Shift Register (LFSR) can be used to generate a random index. Before eviction, a failure status should be returned to all requests in the waiting queue corresponding to the entry, and the corresponding pending ATS Request should be canceled (if possible).

[0055] Upon receiving an input virtual address to be translated, after performing parallel hash lookups in multiple address translation tables to determine if an address mapping entry matching the input virtual address exists, the process also includes: S410: If no address mapping entry matching the input virtual address exists in multiple address translation tables, then the address translation request is treated as a new address translation request.

[0056] This step defines the triggering conditions for a "new address translation request". The pending request filtering process only proceeds if the primary ATC (i.e., multiple address translation tables) does not match the request. If the primary ATC matches, the physical address is returned directly, without subsequent filter table lookups and aggregation operations. This design avoids unnecessary filter table lookups, reducing power consumption and latency.

[0057] S420: Check if there is an entry in the pending request filter table that corresponds to the 4KB base address of the new address translation request.

[0058] The 4KB base address is calculated as follows: For a given virtual address VA, its 4KB base address = VA & ~0xFFF (i.e., the lower 12 bits are cleared). This calculation can be completed in a single clock cycle by hardware combinational logic. For example, VA = 0x180001000, 4KB base address = 0x180001000 & ~0xFFF = 0x180001000 & 0xFFFFFFFFFFFFF000 = 0x180001000. Here, ~0xFFF represents inverting 0xFFF (all 12 bits) to obtain 0xFFFFFFFFFFFFF000, with all high bits at 1 and all low 12 bits at 0. When querying the filter table, the 4KB base address is used to simultaneously index the CAM or calculate the hash value, obtaining the result of whether a matching entry exists within a single clock cycle.

[0059] S430: If an entry corresponding to the 4KB base address exists in the pending request filter table, no new address translation request is sent to the root complex, and the new address translation request is added to the waiting queue associated with the entry.

[0060] When a query in the filter table is matched, it indicates that there is already an pending request with the same 4KB address range awaiting a response. At this point, the hardware no longer sends a new ATS Request, but instead pushes the context of the current request (such as the DMA request pointer, request completion callback, etc.) to the tail of the wait queue for that entry. The entire operation does not involve PCIe link transactions and only consumes local clock cycles (typically 1-2 cycles). For example, assuming that within 2 microseconds after the first request is issued, 100 subsequent DMA requests access the same 4KB page (e.g., page 0x12345000), existing technology would issue 100 ATS Requests; while this method only issues 1, and the subsequent 99 requests are aggregated into the wait queue, reducing 99 table lookups to the root complex and 99 transaction packets on the PCIe link.

[0061] S440: If there is no entry in the pending request filter table corresponding to the 4KB base address, send an address translation request to the root complex, create a new entry in the pending request filter table corresponding to the 4KB base address, and initialize the wait queue associated with the entry.

[0062] When the query filter table fails to find a match, it means there are no pending requests within that 4KB address range. The hardware constructs an ATS Request message according to the PCIeATS protocol specification, which includes a request identifier (Request ID, generated from the device function number and tag), the virtual address, and the requested page size (typically 4KB). The hardware simultaneously stores the generated request identifier in the "Request Identifier" field of the newly created table entry for subsequent response matching. The wait queue can be implemented using a circular buffer (FIFO) with a configurable depth of 8, 16, or 32. The queue stores pointers to the original DMA request descriptors or request context information. Initializing the wait queue involves setting the head and tail pointers to zero.

[0063] In addition, each entry in the pending request filter table is associated with a Ready flag, which is initially invalid.

[0064] S450: When an address translation response is received for the 4KB base address corresponding to this entry, the Ready flag of this entry is set to valid.

[0065] The Ready flag is initially 0, and is set to 1 upon receiving an ATS Response. When an ATS Response arrives, the hardware parses the request identifier within it and compares it in parallel with the request identifier fields of all valid entries in the filter table to locate the corresponding entry. Once the entry is successfully located, the Ready flag for that entry is set to valid.

[0066] S460: Wake up all address translation requests in the waiting queue associated with this entry, so that these address translation requests can directly use the physical address carried in the address translation response to complete the direct memory access operation corresponding to the address translation request.

[0067] Once the ATS Response arrives and is located in the table using the request identifier, the hardware parses the physical address base (PA_base) and page size from the response. Then, it iterates through each request in the waiting queue, calculating the physical address for each request as PA_base + (the low-order offset of the requested virtual address). For example, if the ATS Response returns a physical address base of 0x80000000, and a request in the queue has a virtual address of 0x12345008 and a low-order offset of 0x008, the physical address would be 0x80000008. The calculated physical address is then filled into the DMA descriptor or a DMA operation is initiated directly. After the queue traversal is complete, the entry is marked for deletion.

[0068] This embodiment effectively aggregates duplicate address translation requests within the same 4KB address range using a pending request filter table mechanism. When the primary ATC misses, the first request creates a filter table entry, and subsequent requests falling within the same 4KB range are aggregated into a waiting queue, eliminating the need to send requests to the root complex again. This design significantly reduces the number of duplicate requests, lowers the root complex's table lookup load, and reduces communication overhead on the PCIe link.

[0069] Specifically, this also includes a timeout handling mechanism: S470: If an entry in the pending request filter table does not receive a corresponding address translation response within a preset time, the entry is marked as invalid, and all address translation requests in the waiting queue associated with the entry are notified to return an error or trigger a retry.

[0070] The timeout handling mechanism ensures system robustness: even if the root complex is unresponsive or the link fails, requests in the waiting queue will not be permanently blocked. The preset timeout can be configured to 10μs, 100μs, or a timeout value negotiated based on the PCIe link. The timeout counter starts when a request is sent and decrements every clock cycle. If no response is received within the timeout period, the hardware automatically marks the entry as invalid and iterates through its waiting queue, generating an error completion (such as a PCIe UR or CA status) for each request, or triggering a software retry mechanism.

[0071] This embodiment, building upon the multi-granularity table of the previous embodiment, aggregates multiple address translation requests within the same 4KB address range into a single request using a pending request filtering table. This significantly reduces the number of duplicate requests, lowering the root complex load and PCIe bandwidth usage. Through the Ready flag and waiting queue, subsequent requests do not need to be resent, reducing response latency from a full round-trip time to a very short queue wake-up time. A timeout handling mechanism ensures system robustness. This embodiment significantly improves the address translation performance and system stability of PCIe devices with extremely low hardware overhead (tens of KB of storage).

[0072] The two embodiments of this invention work together to form a complete ATC optimization scheme: the multi-granularity table of the first embodiment solves the problem of efficient storage and retrieval of address mapping entries of different sizes; the pending request filtering table and Ready mechanism of the second embodiment eliminate duplicate address translation requests within the same 4KB page and reduce the response latency of subsequent requests. Working together, the two comprehensively improve the address translation performance of PCIe devices from multiple dimensions such as storage, retrieval, request aggregation, and response latency. The three working together significantly improve the address translation performance and system stability of PCIe devices.

[0073] As another possible embodiment of the present invention, such as Figure 4 As shown, an address translation cache management system based on a multi-granularity hash table is provided, applied in endpoint devices, including: The translation table module provides multiple address translation tables. Each address translation table is configured to store address mapping entries of a fixed size, and the size of the address mapping entries in different address translation tables is different from each other.

[0074] The parsing module is used to parse the virtual address, physical address, and address mapping entry size when it receives an address translation response from the root complex, and store the address mapping entry into one or more corresponding address translation tables according to the address mapping entry size.

[0075] The lookup module performs a parallel hash lookup in multiple address translation tables when it receives an input virtual address to be translated, in order to determine whether there is an address mapping entry that matches the input virtual address.

[0076] The address concatenation module is used to, if a matching address mapping entry is found, concatenate the physical address base address stored in the matching address mapping entry with the low-order offset of the input virtual address to obtain the final physical address, and directly perform end-to-end access through the physical address.

[0077] Furthermore, although the steps of the method in this disclosure are described in a specific order in the accompanying drawings, this does not require or imply that the steps must be performed in that specific order, or that all the steps shown must be performed to achieve the desired result. Additional or alternative steps may be omitted, multiple steps may be combined into one step, and / or a step may be broken down into multiple steps.

[0078] From the above description of the embodiments, those skilled in the art will readily understand that the exemplary embodiments described herein can be implemented by software or by combining software with necessary hardware. Therefore, the technical solutions according to the embodiments of this disclosure can be embodied in the form of a software product, which can be stored in a non-volatile storage medium (such as a CD-ROM, USB flash drive, external hard drive, etc.) or on a network, including several instructions to cause a computing device (such as a personal computer, server, mobile terminal, or network device, etc.) to execute the methods according to the embodiments of this disclosure.

[0079] In an exemplary embodiment of this disclosure, an electronic device capable of implementing the above-described method is also provided.

[0080] Those skilled in the art will understand that various aspects of the present invention can be implemented as systems, methods, or program products. Therefore, various aspects of the present invention can be specifically implemented in the following forms: entirely in hardware, entirely in software (including firmware, microcode, etc.), or in a combination of hardware and software, collectively referred to herein as “circuit,” “module,” or “system.”

[0081] An electronic device according to this embodiment of the invention. The electronic device is merely an example and should not be construed as limiting the functionality or scope of the embodiments of the invention.

[0082] Electronic devices are manifested in the form of general-purpose computing devices. Components of an electronic device may include, but are not limited to: at least one processor, at least one memory, and buses connecting different system components (including memory and processor).

[0083] The memory stores program code that can be executed by a processor, causing the processor to perform the steps described in the "Exemplary Methods" section above, according to various exemplary embodiments of the present invention.

[0084] The storage may include readable media in the form of volatile storage, such as random access memory (RAM) and / or cache memory, and may further include read-only memory (ROM).

[0085] The storage may also include programs / utilities having a set (at least one) of program modules, including but not limited to: an operating system, one or more applications, other program modules, and program data, each or some combination of these examples may include an implementation of a network environment.

[0086] A bus can represent one or more of several bus architectures, including a memory bus or memory controller, a peripheral bus, a graphics acceleration port, a processor, or a local bus that uses any of the various bus architectures.

[0087] The electronic device can also communicate with one or more external devices (e.g., keyboards, pointing devices, Bluetooth devices, etc.), one or more devices that enable a user to interact with the electronic device, and / or any device that enables the electronic device to communicate with one or more other computing devices (e.g., routers, modems, etc.). This communication can be performed via input / output (I / O) interfaces. Furthermore, the electronic device can communicate with one or more networks (e.g., local area networks (LANs), wide area networks (WANs), and / or public networks, such as the Internet) via a network adapter. The network adapter communicates with other modules of the electronic device via a bus. It should be understood that, although not shown in the figures, other hardware and / or software modules can be used in conjunction with the electronic device, including but not limited to: microcode, device drivers, redundant processors, external disk drive arrays, RAID systems, tape drives, and data backup storage systems.

[0088] In exemplary embodiments of this disclosure, a computer-readable storage medium is also provided, on which a program product capable of implementing the methods described above is stored. In some possible embodiments, various aspects of the present invention may also be implemented as a program product comprising program code that, when the program product is run on a terminal device, causes the terminal device to perform the steps of the various exemplary embodiments of the present invention described in the "Exemplary Methods" section above.

[0089] The program product may employ any combination of one or more readable media. A readable medium may be a readable signal medium or a readable storage medium. A readable storage medium may be, for example, but not limited to, an electrical, magnetic, optical, electromagnetic, infrared, or semiconductor system, apparatus, or device, or any combination thereof. More specific examples of readable storage media (a non-exhaustive list) include: electrical connections having one or more wires, portable disks, hard disks, random access memory (RAM), read-only memory (ROM), erasable programmable read-only memory (EPROM or flash memory), optical fiber, portable compact disk read-only memory (CD-ROM), optical storage devices, magnetic storage devices, or any suitable combination thereof.

[0090] Computer-readable signal media may include data signals propagated in baseband or as part of a carrier wave, carrying readable program code. Such propagated data signals may take various forms, including but not limited to electromagnetic signals, optical signals, or any suitable combination thereof. A readable signal medium may also be any readable medium other than a readable storage medium, capable of sending, propagating, or transmitting programs for use by or in conjunction with an instruction execution system, apparatus, or device.

[0091] The program code contained on the readable medium may be transmitted using any suitable medium, including but not limited to wireless, wired, optical fiber, RF, etc., or any suitable combination thereof.

[0092] Program code for performing the operations of this invention can be written in any combination of one or more programming languages, including object-oriented programming languages ​​such as Java and C++, and conventional procedural programming languages ​​such as C or similar languages. The program code can execute entirely on the user's computing device, partially on the user's device, as a standalone software package, partially on the user's computing device and partially on a remote computing device, or entirely on a remote computing device or server. In cases involving remote computing devices, the remote computing device can be connected to the user's computing device via any type of network, including a local area network (LAN) or a wide area network (WAN), or it can be connected to an external computing device (e.g., via the Internet using an Internet service provider).

[0093] Furthermore, the accompanying drawings are merely illustrative of the processes included in the method according to exemplary embodiments of the present invention and are not intended to be limiting. It is readily understood that the processes shown in the above drawings do not indicate or limit the temporal order of these processes. Additionally, it is readily understood that these processes may be executed synchronously or asynchronously, for example, in multiple modules.

[0094] It should be noted that although several modules or units for the device used to perform actions have been mentioned in the detailed description above, this division is not mandatory. In fact, according to embodiments of this disclosure, the features and functions of two or more modules or units described above can be embodied in one module or unit. Conversely, the features and functions of one module or unit described above can be further divided and embodied by multiple modules or units.

[0095] The above are merely specific embodiments of the present invention, but the scope of protection of the present invention is not limited thereto. Any variations or substitutions that can be easily conceived by those skilled in the art within the technical scope disclosed in the present invention should be included within the scope of protection of the present invention. Therefore, the scope of protection of the present invention should be determined by the scope of the claims.

Claims

1. An address translation cache management method based on a multi-granularity hash table, applied in endpoint devices, characterized in that, Includes the following steps: Multiple address translation tables are provided, each configured to store address mapping entries of a fixed size, and the address mapping entry sizes of different address translation tables are different; When an address translation response is received from the root complex, the virtual address, physical address, and address mapping entry size are parsed out, and the address mapping entry is stored in one or more corresponding address translation tables according to the address mapping entry size. When an input virtual address to be converted is received, a parallel hash lookup is performed simultaneously in multiple address translation tables to determine whether there is an address mapping entry that matches the input virtual address. If a matching address mapping entry is found, the final physical address is obtained by concatenating the physical address base address stored in the matching address mapping entry with the low-order offset of the input virtual address, and end-to-end access is performed directly through this physical address.

2. The method according to claim 1, characterized in that, The step of storing address mapping entries into one or more corresponding address translation tables according to their size specifically includes: If the size of the address mapping entry is equal to the preset address mapping entry size of an address translation table, then the address mapping entry is directly stored in that address translation table.

3. The method according to claim 1, characterized in that, The step of storing address mapping entries into one or more corresponding address translation tables according to the size of the address mapping entry includes: If the size of the address mapping entry is not equal to the preset address mapping entry size of any address translation table, then select the maximum value T that is less than or equal to the size of the address mapping entry from all preset address mapping entry sizes, and split the address mapping entry into multiple sub-address mapping entries of size T. Based on the input virtual address corresponding to the currently received address translation response, determine which sub-address mapping entry the input virtual address falls within, and store the sub-address mapping entry into an address translation table with a preset address mapping entry size of T; The virtual address base address of the sub-address mapping entry is equal to the original virtual address base address plus an offset, which is an integer multiple of T that is down-aligned to the low-order part of the input virtual address; the physical address base address of the sub-address mapping entry is equal to the original physical address base address plus the same offset.

4. The method according to claim 1, characterized in that, The parallel hash lookup includes: For each address translation table, the number of high-order bits used for hash calculation in the input virtual address is determined according to the preset address mapping entry size of the address translation table; The high-order bits are input into a hash function to obtain the index in the table, and the address mapping entry at that index position is read. Compare the base address of the virtual address stored in the address mapping entry with the high-order part of the input virtual address. If they are equal, it is considered a match.

5. The method according to claim 1, characterized in that, The preset address mapping entry sizes of the multiple address translation tables include at least two of the following: 4KB, 64KB, 2MB, and 1GB, and the preset address mapping entry sizes are configurable.

6. The method according to claim 1, characterized in that, Maintain a pending request filter table, which contains one or more entries, each corresponding to a 4KB address range, to record address translation requests that have been sent but have not yet received a response. Upon receiving an input virtual address to be translated, after performing a parallel hash lookup in multiple address translation tables to determine if an address mapping entry matching the input virtual address exists, the process further includes: If no address mapping entry matching the input virtual address is found in any of the address translation tables, then the address translation request is treated as a new address translation request. Check if there is an entry in the pending request filter table that corresponds to the 4KB base address of the new address translation request; If an entry corresponding to the 4KB base address exists in the pending request filter table, no new address translation request will be sent to the root complex, and the new address translation request will be added to the waiting queue associated with the entry. If there is no entry in the pending request filter table corresponding to the 4KB base address, an address translation request is sent to the root complex, and a new entry corresponding to the 4KB base address is created in the pending request filter table. At the same time, the wait queue associated with the entry is initialized.

7. The method according to claim 6, characterized in that, Each entry in the pending request filtering table is associated with a Ready flag, which is initially invalid. When an address translation response for the 4KB base address corresponding to this entry is received, the Ready flag of this entry is set to valid; Wake up all address translation requests in the waiting queue associated with the entry, so that these address translation requests can directly use the physical address carried in the address translation response to complete the direct memory access operation corresponding to the address translation request.

8. The method according to claim 6, characterized in that, It also includes a timeout handling mechanism: If an entry in the pending request filter table does not receive a corresponding address translation response within a preset time, the entry is marked as invalid, and all address translation requests in the waiting queue associated with that entry are notified to return an error or trigger a retry.

9. The method according to claim 6, characterized in that, The capacity of the pending request filter table is a fixed value; when the number of entries in the pending request filter table is full and a new entry needs to be created, the existing entry is replaced by either the least recently used strategy or the random replacement strategy.

10. An address translation cache management system based on a multi-granularity hash table, applied in endpoint devices, characterized in that, include: The translation table module provides multiple address translation tables. Each address translation table is configured to store address mapping entries of a fixed size, and the address mapping entry sizes of different address translation tables are different. The parsing module is used to parse out the virtual address, physical address, and address mapping entry size when it receives an address translation response from the root complex, and store the address mapping entry into one or more corresponding address translation tables according to the address mapping entry size; The lookup module is used to perform a parallel hash lookup in multiple address translation tables simultaneously when an input virtual address to be converted is received, in order to determine whether there is an address mapping entry that matches the input virtual address. The address concatenation module is used to, if a matching address mapping entry is found, concatenate the physical address base address stored in the matching address mapping entry with the low-order offset of the input virtual address to obtain the final physical address, and directly perform end-to-end access through the physical address.

Images