An information processing method, apparatus, electronic device, storage medium, and product

Abstract

The application discloses an information processing method and device, electronic equipment, storage medium and product, comprising: calling an input-output address conversion cache module to receive a first address conversion request; the first address conversion request is used for requesting to translate a first input-output virtual address; calling the input-output address conversion cache module to respond to the first address conversion request, if a first translation result of the first input-output virtual address has been cached, sending the first translation result to an initiator of the first address conversion request; if not, calling an input-output address conversion service module to respond to the first address conversion request, and querying a plurality of blocks included in a tree-shaped page access cache module in parallel; the plurality of blocks are used for storing a starting address of a hierarchical page table and an index of the hierarchical page table; based on the starting address of the next level page table and the index of the current level queried according to the first input-output virtual address, querying a page table entry from a main memory to obtain a second translation result, and sending the second translation result to the initiator.

Description

Technical Field

[0001] This application relates to the field of storage technology, and in particular to an information processing method, apparatus, electronic device, storage medium and product. Background Technology

[0002] Virtualization technology is a crucial foundation for modern cloud computing and data centers. By abstracting physical resources into multiple logical units, it enables resource sharing and isolation. In input / output (I / O) virtualization, the input / output memory management unit (IOMMU) is used to implement address translation and security isolation for device access. Its core function is to translate the virtual addresses used by the device into corresponding physical addresses to ensure the security and correctness of data access.

[0003] However, traditional IOMMUs introduce a Translation Lookaside Buffer (TLB) when processing address translation requests. If the TLB is hit, the result is returned directly; otherwise, a multi-level Page Table Walk (PTW) is required. This method requires querying the page table level by level, resulting in low address translation efficiency. Summary of the Invention

[0004] This application provides an information processing method, apparatus, electronic device, storage medium, and product.

[0005] The technical solution of this application is implemented as follows:

[0006] An information processing method, the method comprising:

[0007] The input / output address translation cache module is invoked to receive a first address translation request; wherein, the first address translation request is used to request the translation of a first input / output virtual address;

[0008] The input / output address translation cache module is invoked in response to the first address translation request. If the first translation result of the first input / output virtual address has been cached, the first translation result is sent to the initiator of the first address translation request.

[0009] If not cached, the input / output address translation service module is invoked to respond to the first address translation request, and multiple blocks included in the tree page access cache module are queried in parallel; wherein, the multiple blocks are used to store the starting address of the hierarchical page table and the index of the hierarchical page table;

[0010] Based on the starting address of the next-level page table obtained from the first input / output virtual address and the index of the current level, the second translation result is obtained by querying the page table entry in main memory and then sent to the initiator.

[0011] An information processing apparatus, comprising:

[0012] The processing module is used to call the input / output address translation cache module to receive a first address translation request; wherein, the first address translation request is used to request the translation of a first input / output virtual address;

[0013] The processing module is used to call the input / output address translation cache module to respond to the first address translation request. If the first translation result of the first input / output virtual address has been cached, the first translation result is sent to the initiator of the first address translation request.

[0014] The processing module is configured to, if not cached, call the input / output address conversion service module to respond to the first address conversion request, and query multiple blocks included in the tree-structured page access cache module in parallel; wherein, the multiple blocks are used to store the starting address of the hierarchical page table and the index of the hierarchical page table;

[0015] The processing module is configured to retrieve the second translation result from the page table entry in main memory based on the starting address of the next-level page table obtained from the first input / output virtual address and the index of the current level, and then send the second translation result to the initiator.

[0016] An electronic device includes: a processor and a memory for storing a computer program capable of running on the processor.

[0017] When the processor runs the computer program, it executes the steps of any of the above methods.

[0018] A storage medium having a computer program stored thereon, which, when executed by a processor, implements the steps of any of the above methods.

[0019] A computer program product includes a computer program that, when executed by a processor, implements the steps of any of the above methods.

[0020] This application provides an information processing method, which includes: calling an input / output address translation cache module to receive a first address translation request; wherein the first address translation request is used to request the translation of a first input / output virtual address; calling the input / output address translation cache module to respond to the first address translation request, and if the first translation result of the first input / output virtual address has been cached, sending the first translation result to the initiator of the first address translation request; if it has not been cached, calling an input / output address translation service module to respond to the first address translation request, and querying multiple blocks included in the tree-structured page access cache module in parallel; wherein the multiple blocks are used to store the starting address of the hierarchical page table and the index of the hierarchical page table; based on the starting address of the next-level page table queried from the first input / output virtual address and the index of the current level, querying the page table entries from main memory to obtain a second translation result, and sending the second translation result to the initiator. This application introduces an I / O Address Translation Caches (IOATC) module and a Tree Structure Page Walk Cache (TSPWC) module architecture, combined with a parallel query mechanism. Upon receiving an address translation request from an I / O device, it first checks the IOATC module to see if the first translation result for that address is already cached. If a match is found, the result is returned quickly; otherwise, the I / O Address Translation Server (IOATS) module is invoked for further processing. At this point, by querying multiple blocks in the TSPWC module in parallel, the page table lookup process is accelerated, significantly reducing query latency and improving address translation efficiency. Attached Figure Description

[0021] Figure 1 A flowchart illustrating an information processing method provided in an embodiment of this application;

[0022] Figure 2 A schematic diagram of a RISC-V IOMMU architecture provided for an embodiment of this application;

[0023] Figure 3 A schematic diagram of a TSPWC structure provided in an embodiment of this application;

[0024] Figure 4 A schematic diagram of a TSPWC workflow provided in this application embodiment;

[0025] Figure 5 This is a schematic diagram of the structure of an information processing device provided in an embodiment of this application;

[0026] Figure 6 This is a schematic diagram of the structure of an electronic device provided in an embodiment of this application. Detailed Implementation

[0027] The technical solutions in the embodiments of this application will be clearly and completely described below with reference to the accompanying drawings.

[0028] It should be understood that the phrases "embodiments of this application" or "foreign embodiments" throughout the specification mean that a specific feature, structure, or characteristic related to an embodiment is included in at least one embodiment of this application. Therefore, "embodiments of this application" or "in the foreign embodiments" appearing throughout the specification do not necessarily refer to the same embodiment. Furthermore, these specific features, structures, or characteristics can be combined in any suitable manner in one or more embodiments. In the various embodiments of this application, the sequence numbers of the above-described processes do not imply a sequential order of execution; the execution order of each process should be determined by its function and internal logic, and should not constitute any limitation on the implementation process of the embodiments of this application. The sequence numbers of the above-described embodiments are merely descriptive and do not represent the superiority or inferiority of the embodiments.

[0029] It should be noted that the terms "first, second, and third" used in the embodiments of this application are merely to distinguish similar objects and do not represent a specific ordering of objects. It is understood that "first, second, and third" can be interchanged in a specific order or sequence where permitted, so that the embodiments of this application described herein can be implemented in an order other than that illustrated or described herein.

[0030] In related technologies, IOMMUs typically employ page tables for address translation and introduce structures such as Translation Lookaside Buffer (TLB) and Page Walk Cache (PWC) to reduce the overhead of frequent page table lookups. For example, upon receiving an address translation request, if the TLB hits, the result is returned directly; otherwise, a multi-level page table walk (PTW) is performed, and partial index information recorded in the PWC is used to accelerate the lookup. However, this method still requires querying page tables level by level, and the cache structure design is complex, making it difficult to efficiently handle high-concurrency, multi-level address translation needs.

[0031] This application relates to the design of an Input / Output Memory Management Unit (IOMMU) based on a RISC-V architecture, aiming to solve problems such as low I / O virtualization efficiency in related technologies. Traditional IOMMUs suffer from high serial lookup latency and severe information redundancy when processing address translation requests. This application, by introducing a distributed IOATC module and a TSPWC structure, achieves parallel lookup of multi-level page tables and reduces redundancy, significantly improving address translation efficiency and I / O device performance.

[0032] To address the aforementioned issues, this application proposes an information processing method. This method includes invoking an input / output address translation cache module to receive a first address translation request and determining whether the first translation result for the virtual address has been cached. If the cache hits, the result is returned directly; if not, the input / output address translation service module is invoked for further processing. In the service module, multiple blocks in the tree-structured page access cache module are queried in parallel, extracting partial bits of the virtual address to generate an index, and selecting the query result according to a priority arbitration strategy. If the query is successful, the page table entry is retrieved from main memory based on the starting address of the next-level page table and the current-level index to complete the translation. Through this technical solution, the application achieves an efficient address translation process, improves the memory access efficiency of I / O devices, reduces latency, and enhances security and isolation.

[0033] Here, the following modules introduced in this application are explained:

[0034] (1) Input / output address translation cache (IOATC) module: used to cache the translation results (also known as translation results) of address translation requests initiated by I / O devices, including device context (DC), process context (PC) and page table entries, thereby speeding up the address translation process and reducing the number of accesses to main memory.

[0035] (2) Input / Output Address Translation Server (IOATS) module: responsible for handling address translation requests that are not cached by IOATC, performing Page Table Walk (PTW), and accelerating the lookup process through the Tree Page Access Cache (TSPWC) module to improve overall translation efficiency.

[0036] (3) Tree Page Access Cache Module (TSPWC): The traditional PWC structure is optimized into three independent blocks. The three blocks are used to store the starting address and index of the hierarchical page table. Furthermore, the three blocks store the page table index and starting address of different levels respectively, and support parallel query and priority determination, effectively reducing redundant data and improving hit rate and query efficiency.

[0037] The information processing method provided in the embodiments of this application can be executed by an Input / Output Storage Management Unit (IOMMU). The IOMMU can be applied to a bare metal server (BMS). The role of the IOMMU in a BMS includes: address translation and Direct Memory Access (DMA) security: The IOMMU translates the virtual address (IOVA) of a device into a physical address (PA), ensuring that I / O devices on the BMS (such as graphics processing units (GPUs) and network interface cards) can securely access main memory and avoid DMA attacks; for example, the BMS uses the IOMMU to isolate DMA access permissions for different devices, preventing out-of-bounds operations. The role of the IOMMU in a BMS also includes: virtualization: Although the BMS is a physical machine, it can support nested virtualization through the IOMMU, allowing virtual machines to directly access hardware resources (such as GPU passthrough).

[0038] BMS (Building Management System) is a service model that enables high-performance computing by directly accessing physical hardware resources. Its architecture retains the performance advantages of traditional physical servers while integrating the elastic deployment capabilities of cloud services. BMS provides users with dedicated physical machines in the cloud, offering exclusive computing resources and zero virtualization overhead. It enables traditional physical machines to possess cloud capabilities such as self-deployment, self-maintenance, Virtual Private Cloud (VPC) interconnection, and shared storage, allowing for flexible deployment and use like virtual machines, while offering superior computing, storage, and networking capabilities. It inherently possesses all the advantages of physical machines, offering secure isolation and outstanding performance, making it suitable for high-performance computing, core databases, game streaming, and other business scenarios. It is fully compatible with VPC, cloud disks, file storage, and other related products, enabling flexible construction of enterprise applications and services.

[0039] Preferably, the core application scenarios of BMS can be summarized into the following categories:

[0040] 1. High-performance computing (HPC) scenarios

[0041] BMS demonstrates significant advantages in high-performance computing scenarios, particularly in fields such as gene sequencing, graphics rendering, and virtualization platforms where zero tolerance for computational performance loss is possible. Flexible bare metal, with its inherent advantage of no virtualization loss, provides users with hardware-level product services.

[0042] 2. Core Database Scenarios

[0043] In core database scenarios (such as Oracle, SAP HANA, etc.), BMS (Basic Management System) effectively safeguards the security of users' core database operations through dedicated resources, network isolation, and performance advantages, providing enterprise-level security for critical business data. For example, in core database deployments within the financial industry, BMS's high-performance storage achieves the following: in Oracle scenarios, inter-node storage synchronization latency is less than 1ms, ensuring transaction consistency; in SAP HANA scenarios, memory computing performance is significantly improved through optimized memory access architecture in multi-processor systems and local solid-state drive caching.

[0044] 3. Video live streaming scenario

[0045] In live video streaming scenarios, BMS provides stable support for high-concurrency bullet screen interaction through dedicated physical resources and a low-latency network architecture. In live video streaming, bullet screen comments place extremely high demands on network bandwidth and server performance, as each comment needs to be presented in real-time to all users watching the same live stream. During peak periods, there may be hundreds of millions of long connections, with single-server bandwidth reaching tens of gigabits.

[0046] 4. Key Database Business Scenarios

[0047] In critical database business scenarios, BMS provides enterprise-level solutions for users with high security requirements through three core technologies: dedicated physical resources, hardware-level security isolation, and Software Guard Extensions (SGX) encrypted computing. In these scenarios, users require that their critical database operations (such as those in the financial industry, public utilities, and healthcare) cannot be deployed on cloud servers but must be hosted on physical machines with dedicated resources, network isolation, and guaranteed performance. Furthermore, solutions based on SGX encrypted computing and encrypted cloud disks can provide high-level services to specific users.

[0048] 5. Applications of Artificial Intelligence (AI)

[0049] In artificial intelligence (AI) applications, BMS provides high-performance computing support for AI training and inference through dedicated physical resources and GPU acceleration capabilities. In AI applications, the development of AI relies on GPU capabilities, and intelligent computing bare metal systems, by incorporating various types of GPU cards, can meet the training and inference needs of AI applications.

[0050] Figure 1 This is a flowchart illustrating the information processing method provided in the embodiments of this application. The following will be combined with... Figure 1 The steps shown are explained below, such as Figure 1 As shown, the method includes the following steps 101 to 103:

[0051] Step 101: Call the input / output address translation cache module to receive the first address translation request; wherein, the first address translation request is used to request the translation of the first input / output virtual address.

[0052] In practical applications, IOATC is deployed close to the I / O devices to reduce access latency. An independent IOATC module is configured for each I / O device or interface. These IOATC modules run in parallel and can independently respond to address translation requests from different I / O devices. The main functions of the IOATC module include: caching address translation results initiated by I / O devices, maintaining context information during the address translation process, and executing operations in the command queue. Through its own caching mechanism, the IOATC module can significantly reduce the number of accesses to main memory, improving overall performance and efficiency.

[0053] In practical applications, the first address translation request is typically initiated by the I / O device and includes both device and process contexts. The device context identifies the device and its permissions, while the process context describes the process's environment. Both device and process context information are crucial for subsequent address translation. Furthermore, the first address translation request also contains the first IOVA to be translated, which is the memory address the I / O device wants to access. The first IOVA needs to be translated into its corresponding physical address so that the I / O device can correctly access memory.

[0054] In practical applications, after receiving the first address translation request, the IOATC module first checks its internal cache for a first translation result corresponding to the first IOVA. If it exists, the IOATC module directly returns the translated physical address or device context without further querying main memory or the TSPWC module. This hit-based processing method adopted by the IOATC module greatly improves the efficiency of address translation and reduces latency.

[0055] Step 102: Call the input / output address translation cache module to respond to the first address translation request. If the first translation result of the first input / output virtual address has been cached, send the first translation result to the initiator of the first address translation request.

[0056] In practical applications, the IOATC module's cache structure typically comprises two levels: a fully associative first-level translation lookup buffer and a set-associative second-level translation lookup buffer with set-configurable settings. The first-level buffer primarily caches the most frequently accessed address translation results, such as the frequently used mapping from IOVA to I / O physical addresses. The second-level buffer caches more translation entries, supporting a wider range of address space access. When the IOATC module receives an address translation request, it first checks the first-level buffer for a match. If no match is found, it continues searching the second-level buffer. If a match is found, the first translation result (the address translation result) in the IOATC module's cache is directly returned, avoiding access to main memory or the TSPWC module, thus reducing latency and improving efficiency.

[0057] In practical applications, the IOATC module not only caches address translation results but also related context information, such as device context in the device directory table and process context in the process directory table. The context information cached by the IOATC module is crucial for the address translation process because it determines whether an I / O device has permission to access a specific memory region. By caching the context information, the IOATC module can complete address translation without relying on main memory, further improving response speed.

[0058] In practical applications, when the IOATC module successfully hits and returns the first translation result, the entire address translation process can be completed smoothly, and there is no need to call the IOATS or TSPWC modules again. This approach can greatly optimize the address translation path, thereby reducing unnecessary hardware resource consumption and improving overall performance.

[0059] Step 103: If not cached, call the input / output address translation service module to respond to the first address translation request, and query multiple blocks included in the tree page access cache module in parallel; wherein, multiple blocks are used to store the starting address of the hierarchical page table and the index of the hierarchical page table.

[0060] In practical applications, the IOATS module is a key module in the IOMMU responsible for handling complex address translation requests. This module includes a Tree Page Access Cache (TSPWC) to reduce page table redundancy issues present in traditional PWC structures and supports parallel table lookup operations. The IOATS module can handle multiple address translation requests from the distributed IOATC module simultaneously, significantly improving overall efficiency.

[0061] In practical applications, the IOATS module also integrates an address translation server function, which can respond to ATS and Page Request Interface (PRI) requests from high-speed serial computer expansion bus standard (PCI Express, PCIe) devices.

[0062] Step 104: Based on the starting address of the next-level page table obtained from the first input / output virtual address and the index of the current level, query the page table entry in main memory to obtain the second translation result, and send the second translation result to the initiator.

[0063] In practical applications, if the IOATS module fails to find the address, it forwards the address translation request to the IOATS module for processing. The IOATS module is responsible for performing the page table walkthrough process, which involves searching through the page tables at each level based on the virtual address until the final physical address is found. To accelerate the page table walkthrough process, the IOATS module introduces the TSPWC module. The TSPWC module optimizes the traditional PWC structure into multiple (e.g., three) independent blocks, each storing page table indexes and starting addresses at different levels, supporting parallel queries and priority determination.

[0064] In practical applications, if the TSPWC module's query is successful, it can obtain the starting address of the next-level page table and the index of the current level. Based on the starting address of the next-level page table and the index of the current level, the IOATS module can query the page table entries from main memory to complete the final address translation. Due to the parallel query capability of the TSPWC module, the entire translation process can be completed within a few clock cycles, significantly improving the access efficiency of I / O devices.

[0065] In practical applications, the IOATS module can directly interact with main memory via the APB bus or ACE-Lite bus to load the required page table entries. This direct interaction with main memory via the APB bus or ACE-Lite bus avoids the high latency issues associated with serial lookups in traditional IOMMUs, enabling I / O devices to quickly obtain the required physical addresses and accelerating data transfer. Furthermore, the IOATS module supports multiple modes of MSI address translation, PCIe ATS and PRI services, and other functions, further enhancing compatibility and scalability.

[0066] In practical applications, the IOATC module only caches frequently accessed device contexts and I / O physical addresses, without directly accessing main memory. This makes it a front-end cache, focusing on quickly responding to frequently accessed address translation requests and reducing the burden on main memory.

[0067] In practical applications, the first translation result includes the physical address obtained by address translation of the first IOVA, or the device context associated with the first IOVA. The device context is used to identify the device's identity and permissions, while the physical address is the memory address actually accessed by the I / O device. The first translation result serves as the basis for the I / O device to perform DMA operations.

[0068] In practical applications, IOATC module hit processing refers to the successful hit of an IOATC module. This indicates that the virtual address translation result already exists in the IOATC module's cache, allowing it to return the device context and I / O physical address without further querying the TSPWC module or main memory. This approach significantly reduces address translation time and improves response speed.

[0069] In practical applications, the first address translation request is initiated by the I / O device. This request carries the device context and process context, used to identify the device and the current process environment. The first address translation request also contains the first IOVA to be translated. The I / O device translates these virtual addresses into physical addresses so that it can correctly access memory.

[0070] In practical applications, the first IOVA is a virtual address used by the I / O device to identify the memory location that the first IOVA needs to access. The first IOVA needs to be translated into a physical address by the IOMMU's address translation mechanism before it can be recognized and accessed.

[0071] In practical applications, the IOATS module is responsible for handling address translation requests that are not cached by the IOATC module. The IOATS module performs a page table walkthrough and accelerates the lookup through the TSPWC module. The IOATS module can directly interact with main memory via the APB bus or ACE-Lite bus to load the required page table entries and complete the final address translation.

[0072] In summary, in practical applications, the information processing method of this application achieves fast address translation caching through the IOATC module, improving response speed; in the event of a miss, the TSPWC module accelerates the PTW process, and the IOATS module accesses main memory to obtain the final page table entry, completing the full address translation. Throughout the process, the modules work together, ensuring the accuracy of address translation while significantly reducing latency and improving the overall performance of the I / O device.

[0073] This application provides an information processing method, which includes: calling an input / output address translation cache module to receive a first address translation request; wherein the first address translation request is used to request the translation of a first input / output virtual address; calling the input / output address translation cache module to respond to the first address translation request, and if the first translation result of the first input / output virtual address has been cached, sending the first translation result to the initiator of the first address translation request; if not cached, calling an input / output address translation service module to respond to the first address translation request, and querying multiple blocks included in the tree-structured page access cache module in parallel; wherein the multiple blocks are used to store the starting address of the hierarchical page table and the index of the hierarchical page table; based on the starting address of the next-level page table queried from the first input / output virtual address and the index of the current level, querying the page table entries from main memory to obtain a second translation result, and sending the second translation result to the initiator. This application, by introducing an IOATC module and a TSPWC module architecture, combined with a parallel query mechanism, prioritizes checking in the IOATC module whether the first translation result of the address has been cached when receiving an address translation request from an I / O device. If a hit occurs, the result is returned quickly; if a miss occurs, the IOATS module is invoked for further processing. At this point, multiple blocks in the TSPWC module are queried in parallel, accelerating the page table lookup process. Compared to the serial query method in related technologies, this application significantly reduces query latency and improves overall address translation efficiency. Furthermore, traditional PWC suffers from information redundancy issues, while this application eliminates redundancy through a tree-structure design, improving the hit rate and reducing the number of memory accesses, thereby effectively improving I / O performance.

[0074] In some embodiments, the above method further includes: if not found, calling the input / output address translation service module to query the page table from the main memory level by level to obtain the second translation result, and sending the second translation result to the initiator.

[0075] In practical applications, the TSPWC module, as a secondary cache of main memory data, only caches the base address and index of the next-level page table. The TSPWC module still needs to access main memory through the APB bus or ACE-Lite bus to obtain the final page table entry in order to complete the complete address translation process.

[0076] Main memory refers to the memory area that stores complete page table information. This memory area serves as an indispensable data source during address translation. Since page tables typically employ a multi-level structure, the IOATS module needs to access main memory level by level to retrieve the required page table entries. The IOATS module constructs the complete virtual-to-physical address mapping path in this way. The page table data in main memory is maintained by the operating system, which dynamically updates this data as needed to ensure the accuracy and security of the address translation process.

[0077] Page tables are multi-level table structures used to record the mapping relationship between virtual addresses and physical addresses. Each page table entry (PTE) includes the starting address of the next-level page table, access control information, and other metadata. The design of the page table determines the efficiency and flexibility of address translation. In this application, the IOATS module optimizes the page table access process through the TSPWC caching mechanism, reducing unnecessary memory accesses and improving the speed of address translation.

[0078] The second translation result refers to the final physical address generated after address translation. This address is the one actually used by the I / O device to access memory. When address translation fails, the IOATS module queries the page tables in main memory level by level to generate the correct translation result and returns it to the initiator. The process of generating the correct translation result by querying the page tables in main memory level by level by the IOATS module ensures that address translation can still be completed correctly even if the TLB or TSPWC is not hit, and will not affect the normal operation of the I / O device.

[0079] The initiator of this application issues an address translation request, and the initiator includes I / O peripherals.

[0080] In summary, by introducing the TSPWC structure from the distributed IOATC and IOATS modules, a parallel query and page table lookup mechanism without information redundancy is achieved. Introducing the TSPWC structure from the distributed IOATC and IOATS modules reduces latency during address translation, improves the access efficiency of I / O devices, and meets the high memory access requirements of high-performance peripherals.

[0081] In some embodiments, invoking the IOATS module to query multiple blocks included in the TSPWC module in parallel can be achieved through the following steps:

[0082] First: Extract a portion of bits from the first input / output virtual address to generate an index for each block;

[0083] Here, the index refers to the value calculated using a portion of the virtual address to locate the data position within the cache block. In the TSPWC module structure, the first IOVA is divided into several segments, each corresponding to the index value of a block. For example, for the RISC-V SV48 address format, the first IOVA [47:39] is used to generate the index for the 4th level page table, the first IOVA [38:30] is used to generate the index for the 3rd level page table, and the first IOVA [29:21] is used to generate the index for the 2nd level page table. Each block stores only the index information of a specific level, thus avoiding the information redundancy problem that occurs in the traditional PWC structure. In this way, multiple blocks can be searched in parallel efficiently, improving address translation efficiency.

[0084] Secondly, queries are performed in parallel within each of the multiple blocks, and the query results are selected from the results of the multiple blocks, including the starting address of the next-level page table and the index of the current level, based on the priority arbitration strategy and the index of each block; wherein, the query results include the starting address of the next-level page table and the index of the current level.

[0085] In practical applications, parallel querying refers to the ability of three blocks within the TSPWC module to simultaneously search for the first IOVA using their respective indexes, without needing to execute sequentially. The priority arbitration strategy means that when multiple blocks are hit, one is selected as the final query result according to a set priority. Typically, the third block has the highest priority, followed by the second block, and lastly the first block. This is because the third block stores the starting address of the lowest-level page table, reducing subsequent memory accesses and improving overall performance.

[0086] The query results include the starting address of the next-level page table and the index of the current level, indicating that a record matching the current virtual address was found in a certain block, and containing the starting address of the next-level page table and the index of the current level. If multiple blocks match, the best result is selected as the final query result based on a priority arbitration strategy. This priority arbitration strategy ensures that the system makes a quick decision when multiple possible results exist, thereby further improving the efficiency of address translation.

[0087] In this embodiment, a tree-structured TSPWC module is introduced to enable parallel queries of multiple blocks, eliminating page table information redundancy. By introducing the tree-structured TSPWC module, the number of memory accesses can be reduced, thereby accelerating the address translation process and significantly improving the DMA access efficiency of I / O devices to memory.

[0088] In some embodiments, TSPWC adopts a three-level block architecture. The TSPWC module includes three blocks. The first block stores the fourth-level index of the virtual address and the starting address of the third-level page table. The second block stores the third-level index of the virtual address and the starting address of the second-level page table. The third block stores the second-level index of the virtual address and the starting address of the first-level page table. The indexes of the virtual addresses stored in the first, second, and third blocks are different, and the priority of the hit results in the first, second, and third blocks increases sequentially.

[0089] Here, the TSPWC module improves the traditional serial lookup method of Page Walk Cache to parallel lookup, and eliminates information redundancy through block design, thereby improving hit rate and performance.

[0090] In practical applications, the TSPWC module is divided into three independent blocks, each corresponding to a different level of virtual address index and page table start address.

[0091] The first block, Block 1, stores the fourth-level index of the virtual address and the starting address of the third-level page table. The fourth-level index is typically used to quickly locate the starting address of the third-level page table.

[0092] The second block, Block 2, stores the third-level index of the virtual address and the starting address of the second-level page table. This second block can further reduce the number of accesses to main memory.

[0093] The third block, Block 3, stores the second-level index of the virtual address and the starting address of the first-level page table. Since the first-level page table is closest to the final physical address, it has the highest hit priority.

[0094] In practical applications, each block of the TSPWC module stores only the page table index and starting address for the corresponding level. For example, Block1 stores the index and starting address of the fourth-level page table, Block2 stores the index and starting address of the third-level page table, and Block3 stores the index and starting address of the second-level page table. In this way, the TSPWC module can query these three blocks simultaneously in parallel, significantly reducing query time. Furthermore, the TSPWC module employs a priority arbitration strategy, meaning that the result from Block3 has the highest priority, followed by Block2, and finally Block1. This ensures that when multiple blocks are hit, the optimal query result is selected, further improving query efficiency.

[0095] In practical applications, different index levels are stored in each block, avoiding the information redundancy problem caused by repeated storage of multi-level indexes in traditional page table traversal caches. For example, in a traditional page table traversal cache structure, multiple entries may reuse the fourth-level index, resulting in a waste of storage resources; while in this application, each block stores only one specific level index and the corresponding starting address of the next-level page table, thereby improving overall storage efficiency.

[0096] In addition, to improve the accuracy of hit determination, the TSPWC module defines a hit priority mechanism. When multiple blocks hit simultaneously, the final result is selected according to priority order.

[0097] This priority mechanism ensures that the memory block closest to the actual physical address translation path takes effect first, and it also improves the accuracy and efficiency of address translation.

[0098] In practical applications, when the IOMMU receives an IOVA (Input / Output Virtual Address), it generates three different index bit combinations based on the IOVA and queries these three blocks respectively. If any block is hit, the subsequent page table access process continues based on the starting address of the page table stored in the hit block until the final input / output physical address is obtained. If no block is hit, the page table walk process is entered, and page table data is read from main memory to complete the address translation.

[0099] By using the parallel lookup mechanism of the TSPWC module, the TSPWC module can achieve efficient parallel lookup when multiple I / O requests are processed concurrently, significantly shortening address translation time, reducing latency, and thus improving overall I / O performance and resource utilization.

[0100] In this embodiment, by introducing a block-based tree-structured TSPWC module, parallel lookup of virtual address indexes at all levels is achieved, and information redundancy is eliminated. This reduces the number of page table lookups, thereby reducing I / O device access latency and ultimately improving operational efficiency and reliability.

[0101] In summary, the TSPWC module effectively improves I / O address translation efficiency by replacing the traditional serial lookup method of page table traversal cache with parallel lookup, combined with a block design and a hit priority mechanism. In practical applications, the cooperation between blocks is reflected in the fact that each block is responsible for different levels of index matching and storing the starting address of the page table, without overlap or conflict, and the priority mechanism adopted by the system ensures the selection of the optimal path. When the IOMMU receives the IOVA, the TSPWC module immediately begins to execute the address translation task, completing the task autonomously without waiting for external instructions, thereby significantly improving system response speed and resource utilization.

[0102] In some embodiments, the IOATC module described above determines the cached first translation result of the first IOVA by calling the input / output address translation cache module in response to the first address translation request, finding the first translation result in the first-level address translation cache module, and determining that it has been cached; wherein, the first translation result includes the device context;

[0103] In practical applications, the first-stage address translation cache module includes the Unified Translation Lookaside Buffer for Stage 1 (uTLB), which employs a fully associative architecture. It is primarily responsible for caching frequently accessed address translation entries (such as device context DC, process context PC, etc.). Its fully associative design is suitable for quickly matching high-priority data. Physical memory attribute checks (such as caching policies and sharing characteristics) are typically performed by the uTLB module, as its fully associative architecture allows for rapid response to attribute query requests.

[0104] In practical applications, the Device Context (DC) is one of the important data structures that the IOMMU relies on during address translation. The Device Context (DC) contains configuration information, access permissions, and memory protection policies related to a specific I / O device. The role of the Device Context (DC) is to provide a secure access environment for I / O devices, ensuring that I / O devices can only access authorized memory areas and preventing unauthorized access and out-of-bounds operations.

[0105] In practical applications, the device context, as part of the address translation result, is cached in the first-level address translation cache module. This allows for the rapid reuse of existing translation results when multiple identical or similar address translation requests occur, without having to re-access the page table in main memory each time. This not only improves address translation efficiency but also reduces bus bandwidth usage, thereby enhancing overall performance.

[0106] By caching the device context in the first-level address translation cache module, fast address translation responses can be achieved while ensuring the safety of I / O device access to memory. Caching the device context in the first-level address translation cache module effectively reduces I / O access latency, thereby improving the data transfer efficiency of I / O devices and further enhancing operational performance and stability.

[0107] In summary, caching device context operations in the first-level address translation cache module can ensure security and stability while meeting I / O device access requirements and improving overall performance. This method achieves the aforementioned effects.

[0108] In some embodiments, if the first translation result is not found in the first-level address translation cache module, the first translation result is found in the second-level address translation cache module, and it is determined that it has been cached; wherein, the first translation result includes the physical address.

[0109] In practical applications, the second-stage address translation cache module includes the Master Translation Bypass Buffer (MTLB) for Stage 2, which employs a set-associative structure to cache more complex translation data (such as multi-level page table entries, MSI page table entries, etc.) and balances capacity and hit rate through a configurable number of sets. Memory protection checks (such as access permissions) are handled by the MTLB module. The set-associative structure supports more complex permission verification logic, and the configurable number of sets can adapt to scenarios with different security levels.

[0110] This application employs a two-level TLB system with division of labor and cooperation. The uTLB prioritizes handling high-frequency and simple translation requests, while the MTLB handles low-frequency but complex checking tasks, thereby improving the overall address translation efficiency of the IOMMU.

[0111] A physical address is an identifier of the actual storage location in memory, directly recognized and accessed by the hardware. The physical address is the final address obtained after virtual address translation and can be directly used for DMA operations or CPU access.

[0112] In practical applications, by finding and matching the first translation result in the second-level address translation cache module, further access to main memory to perform page table walk (PTW) can be avoided, significantly reducing address translation latency. Simultaneously, due to the higher hit rate and lower memory access overhead of the second-level address translation cache module, overall performance is improved, especially in scenarios with concurrent access to large-scale I / O devices, effectively reducing resource contention and processing latency.

[0113] In some embodiments, if the first translation result is not found in the second-level address translation cache module, it is determined that it is not cached.

[0114] When the second-level address translation cache module also fails to find the cached value, it indicates that the translation result corresponding to the current virtual address has not yet been cached. Further address translation processes will then begin, such as initiating a page table walk (PTW) to obtain the necessary page table entries. This ensures that even in the event of a cache miss, address translation can be completed through a step-by-step lookup process, avoiding a standstill due to cache absence. Although the address translation efficiency is relatively low at this point, this mechanism serves as a fault tolerance measure, ensuring the stability and reliability of the entire IOMMU.

[0115] In some embodiments, the DTI-ATS protocol can also be used to process the PRI request process from a PCIe device that supports the ATS service, and to invoke IOATS for address translation, including the following steps 11 to 12:

[0116] Step 11: Call the Input / Output Address Translation Service module to receive the second address translation request; wherein, the second address translation request is used to request the translation of the second input / output virtual address, and the second address translation request includes a page request interface request from a high-speed serial computer extended bus standard device that supports address translation service.

[0117] Here, high-speed serial computer expansion bus standard devices refer to I / O devices based on the PCI Express (PCIe) protocol, such as high-performance peripherals like GPUs and network cards. These high-speed serial computer expansion bus standard devices typically communicate with the system main memory via a high-speed serial bus and have Address Translation Services (ATS) functionality, allowing them to directly participate in the virtual-to-physical address translation process, thereby improving data access efficiency and reducing latency.

[0118] Furthermore, the page request interface request is a key component of the ATS mechanism. When a high-speed serial computer extended bus standard device needs to access a virtual address but cannot find a corresponding physical address mapping, it initiates a page request interface request to the IOMMU via PRI to obtain the required page table entry information. The page request interface request mechanism helps achieve efficient memory management and enhances security and isolation.

[0119] This application improves the Input / Output Memory Management Unit's (IOMMU) support for various input / output (I / O) devices by introducing an address translation request processing flow for standard devices on high-speed serial computer extended buses. In particular, it implements a more flexible address translation mechanism under the RISC-V instruction set architecture, thereby improving the overall system performance and compatibility.

[0120] Step 12: Call the input / output address translation service module to respond to the second address translation request.

[0121] Here, after receiving a page request interface request initiated by a high-speed serial computer extended bus standard device, the IOMMU will quickly look up or perform a page table walk (PTW) operation based on the page table cache structure inside the IOMMU (such as the TSPWC module mentioned above) to complete the translation from virtual address to physical address, and return the translation result to the high-speed serial computer extended bus standard device that initiated the request. This address translation process significantly reduces the latency caused by the traditional serial polling method and improves the response speed of I / O access.

[0122] This application enables efficient processing of address translation requests initiated by various types of I / O devices, which not only optimizes resource utilization but also enhances system stability and security, making it particularly suitable for high-concurrency scenarios such as cloud computing and big data centers.

[0123] In this embodiment, the IOATS module is invoked to receive and respond to address translation requests from ATS-enabled high-speed serial computer extended bus standard devices. This process of invoking the IOATS module to receive and respond to address translation requests from ATS-enabled high-speed serial computer extended bus standard devices improves the compatibility of the IOMMU with different types of I / O devices, thereby accelerating address translation efficiency and ultimately enhancing the overall system's I / O performance and data processing capabilities.

[0124] In practical applications, there is a close relationship between page request interface requests and high-speed serial computer expansion bus standard devices, because only high-speed serial computer expansion bus standard devices that support ATS functionality will initiate address translation requests through the page request interface. Therefore, when designing a system, it is necessary to ensure that the IOMMU can recognize and process requests from high-speed serial computer expansion bus standard devices to guarantee the integrity and effectiveness of the address translation mechanism.

[0125] In summary, the relationship between the entire process in practical applications is as follows: First, when a high-speed serial computer expansion bus standard device supporting ATS needs to access a virtual address, it sends a page request interface request to the IOMMU through the page request interface. Next, the IOMMU completes the address translation based on its own page table cache or by performing a PTW operation, and returns the virtual-to-physical address translation result to the high-speed serial computer expansion bus standard device. Finally, the high-speed serial computer expansion bus standard device uses the virtual-to-physical address translation result to continue subsequent data access operations. This address translation mechanism, completed collaboratively by the high-speed serial computer expansion bus standard device supporting ATS and the IOMMU, effectively improves the access efficiency of I / O devices and the overall system performance.

[0126] In some embodiments, DMA requests or MSI writes from the device may also be processed, and IOATS may be invoked for address translation, including the following steps 21 to 22:

[0127] Step 21: Call the input / output address translation service module to receive the third address translation request; wherein, the third address translation request is used to request the translation of the third input / output virtual address, and the third address translation request includes a direct memory access request or message signal interrupt write from a high-speed serial computer expansion bus standard device.

[0128] In practice, requests initiated by I / O peripherals to convert a specific IOVA to a physical address (IOPA) are typically issued by high-speed serial computer expansion bus standard devices (such as PCIe devices) to perform data transfer or interrupt handling operations. For example, when a high-speed serial computer expansion bus standard device receives a data packet, it can write the data to host memory via a direct memory access request (DMA request) or send an interrupt signal to the host via a message signal interrupt write (MSI write).

[0129] Direct Memory Access (DMA) requests refer to operations where I / O devices access the system's main memory directly without going through the CPU. For example, when a high-speed serial computer expansion bus standard device receives a data packet, it can use DMA to write the received data directly into the host's DRAM, eliminating the need for the CPU to move the data byte by byte. This improves data transfer efficiency and reduces the CPU's workload.

[0130] Message Signal Interrupt (MSI) write is a method of triggering an interrupt by writing to a specific register. Unlike traditional level / edge triggered interrupts, MSI write generates an interrupt signal by writing to a memory-mapped register. Message signal interrupt write is more flexible, configurable, and supports the differentiation of multiple interrupt sources. For example, a high-speed serial computer expansion bus standard device can be configured with multiple MSI write interrupt vectors, each corresponding to a different event type.

[0131] In practical applications, DMA requests and MSI writes are two common I / O communication methods. DMA requests are mainly used for efficient data transfer, while MSI writes are used for fast and flexible interrupt notification. Both DMA requests and MSI writes require the support of the IOATS module to ensure the correctness and security of address translation.

[0132] The technical advantage of calling the IOATS module to receive third-party address translation requests is that by introducing an address translation request processing mechanism for DMA requests and MSI writes, the IOATS module can support various types of I / O access scenarios, thereby improving system compatibility and flexibility. Simultaneously, since DMA requests and MSI writes are high-performance I / O communication methods, applying them to the system helps accelerate the data exchange process between I / O devices and memory, reducing latency and improving overall performance.

[0133] Step 22: Call the input / output address translation service module to respond to the third address translation request.

[0134] Here, the IOATS module internally employs a Tree-based Parallel Query Cache (TSPWC) structure. This structure uses a tree-based index to achieve parallel queries across multiple page tables, avoiding information redundancy issues in traditional PWC caches and significantly improving address translation efficiency. Furthermore, the IOATS module supports MSI write address translation and ATS service functions, ensuring that interrupt signals are correctly mapped to the target address space.

[0135] During system operation, when processing MSI write requests, the IOATS module needs to perform address translation and ensure that the interrupt register is written to the correct physical address space to prevent incorrect interrupt routing. When processing DMA requests, the IOATS module needs to ensure that data is written to the correct physical address to avoid data loss or out-of-bounds access issues.

[0136] The advantage of invoking the IOATS module to respond to third-party address translation requests is that, through an efficient address translation mechanism, high-speed serial computer extended bus standard devices can quickly obtain the correct physical address, thereby completing data access or interrupt transfer tasks. This technology not only reduces I / O access latency but also improves the stability and security of the entire system. In a multi-virtual machine environment, the IOATS module can effectively isolate I / O resources between virtual machines, thus preventing unauthorized access and other problems.

[0137] In summary, by introducing a third address translation request processing mechanism for DMA requests and MSI writes, and by utilizing the IOATS module to efficiently respond to such requests, the high-performance access requirements of various I / O devices can be supported. This improves the overall data throughput of the system and enhances the security and stability of the I / O virtualization environment.

[0138] In some embodiments, the PCIe device and the IOATS module communicate with each other through a Distributed Translation Interface Interconnet (DTI Interconnet) module.

[0139] Here, the DTI Interconnet module is a communication mechanism used to connect high-speed serial computer expansion bus standard devices (such as PCIe devices) to the IOATS module (IOATS). The DTI Interconnet module's role is to achieve efficient, low-latency data transmission and address translation request processing between I / O devices and the Input / Output Memory Management Unit (IOMMU). DTI Interconnet supports multi-channel parallel communication, capable of simultaneously processing address translation requests initiated by multiple I / O devices and distributing these requests to the IOATS module for further processing. Furthermore, the DTI Interconnet module also has protocol conversion capabilities, adapting to different I / O device interface standards, thereby ensuring that different types of peripherals can uniformly access the IOATS system.

[0140] High-speed serial computer expansion bus standard devices typically refer to I / O devices that use high-speed serial bus protocols such as PCIe. These devices are characterized by high bandwidth and low latency and are widely used in high-performance computing, storage, and networking. When performing DMA operations, high-speed serial computer expansion bus standard devices need to frequently submit address translation requests to the IOMMU to ensure that data is correctly mapped to the physical memory address space.

[0141] The IOATS module is one of the core logical units in the IOMMU, responsible for performing the virtual address to physical address translation process. The IOATS module integrates innovative structures such as TSPWC, enabling parallel processing of multiple address translation requests and significantly improving I / O performance. Through the DTI Interconnet module, the IOATS module can quickly receive concurrent requests from multiple I / O devices and efficiently complete the address translation task using its internal parallel page table lookup mechanism.

[0142] In practical applications, when a high-speed I / O device (such as a Solid State Disk (SSD) controller or network interface card) initiates a DMA operation, it sends an address translation request to the IOATS module via the Distributed Translation Interface Interconnect (DTI) module. Upon receiving the address translation request, the IOATS module determines, based on the current address translation strategy (such as single-stage or two-stage translation) and cache hit status, whether to directly return the address translation result or initiate a Page Table Transition (PTW) process. Throughout the address translation process, the DTI module acts as a bridge, ensuring data transmission stability and reducing overall system communication latency.

[0143] The DTI Interconnet module can be configured according to the specific hardware platform architecture requirements of the Distributed Translation Interface Interconnect module. For example, in multi-core processors or distributed systems, the Distributed Translation Interface Interconnect module can support address translation request passing across chips or slots, thereby enhancing the scalability and flexibility of the system.

[0144] By designing a distributed conversion interface interconnect module between the high-speed serial computer extended bus standard devices and the IOATS module, the system enables parallel access requests from multiple I / O devices. This approach reduces overall communication latency and improves the response speed of I / O devices. Furthermore, it significantly enhances the overall system performance and resource utilization.

[0145] In practical applications, there is a close working relationship between the various steps of the distributed address translation interface interconnection module, I / O devices, and the IOATS module. The distributed address translation interface interconnection module acts as a communication bridge between the I / O devices and the IOATS module, responsible for concurrently sending address translation requests from multiple I / O devices to the IOATS module. The IOATS module processes these requests based on its current cache state and translation strategy, and returns the results to the corresponding I / O devices. This application achieves efficient parallel processing of I / O address translation through this implementation method, effectively improving the overall system performance.

[0146] In summary, by introducing the DTI Interconnet module, a highly efficient I / O address translation mechanism was constructed. This mechanism can significantly reduce communication latency and improve system throughput and resource utilization.

[0147] In some embodiments, when IOATS interacts with the system main memory and executes the query based on the starting address of the next-level page table and the index of the current level, and queries the page table entries in the main memory to obtain the second translation result, it can be achieved through the following steps: accessing the main memory through the advanced peripheral bus or advanced coherence extension bus, loading the page table entries in the main memory, and querying the page table entries based on the starting address of the next-level page table and the index of the current level to obtain the second translation result.

[0148] In this embodiment, by employing the Advanced Peripheral Bus (APB) or the Advanced Coherency Extensions Lite (ACE-Lite) to access main memory, a more efficient and flexible page table entry loading and lookup process can be achieved. Using the APB or ACE-Lite improves the efficiency of I / O devices accessing memory, thereby reducing address translation latency and enhancing overall system performance.

[0149] The Advanced Peripheral Bus (APB) is a typical bus interface used for low-bandwidth applications such as control register configuration. APB features simple structure, low power consumption, and suitability for infrequent data transfer scenarios. For example, in the RISC-VIOMMU architecture, APB can be used for communication between the IOATC module and system main memory. When processing control information such as device context (DC) and process context (PC), APB can complete data read and write operations with relatively low resource consumption.

[0150] Advanced Coherence Extension Bus (ACE) is a bus protocol for non-coherent memory access in multi-core systems. ACE supports data sharing among multiple processors or accelerators and allows for partial cache coherency. In this application, ACE connects the distributed IOATC module and the IOATS module, ensuring that multiple I / O requests can be executed in parallel without conflicts, thus significantly improving address translation efficiency.

[0151] In this embodiment, by selectively using the Advanced Peripheral Bus (APB) or the Advanced Coherence Extension Bus (ECB), the performance of the IOMMU can be optimized according to different application scenarios and data access requirements. This reduces unnecessary hardware overhead while maintaining high system throughput. Consequently, it meets the needs of data center-level I / O virtualization and effectively supports high-performance computing tasks in large-scale cloud computing environments.

[0152] In practical applications, Advanced Peripheral Bus (APB) refers to a bus interface specifically designed for low-bandwidth, low-frequency communication. APB is commonly used for control operations such as register reading and writing. For example, in embedded systems, APB can connect microcontrollers and peripheral modules to implement basic control functions. Due to its streamlined structure and short response time, APB is ideally suited for scenarios that do not require large amounts of data transmission.

[0153] In practical applications, Advanced Peripheral Bus (APB) is a widely used component of the AMBA bus protocol in SoC design to connect peripheral devices to the system core. Key features of APB include a simple handshake mechanism, low power consumption, and suitability for infrequent data exchange. For example, in the IOMMU architecture, APB can be used for communication between the IOMMU's context management unit and system main memory.

[0154] In practical applications, the Advanced Peripheral Bus (APB) is primarily used for the access and control of peripheral devices. Its technical implementation typically includes address, data, and control signal lines, and supports various types of read and write operations. For example, in the RISC-V architecture, the APB can be used for communication between the IOMMU's context management unit and the system main memory to read and update device and process contexts.

[0155] In practical applications, Advanced Coherence Extension Bus (ADEB) refers to a bus protocol for Non-Unified Memory Access (NUMA) in multi-core systems. This protocol provides a limited degree of cache coherence across different computing nodes. ADEB is particularly suitable for scenarios where GPUs and CPUs work together, such as graphics rendering and deep learning training. For example, in distributed computing environments, ADEB can be used to coordinate data access between multiple I / O devices and main memory, avoiding data conflicts and improving system efficiency.

[0156] In practical applications, Advanced Coherency Extensions Lite (ACE) is part of the ARM AMBA protocol suite, designed to support lightweight coherency maintenance in multi-core systems. Compared to the full ACE protocol, ACE is simpler and suitable for applications requiring partial coherency guarantees while conserving hardware resources. For example, in an IOMMU system, ACE can connect multiple IOATC and IOATS modules to achieve efficient data sharing and synchronization.

[0157] In summary, this embodiment introduces two different bus protocols, Advanced Peripheral Bus and Advanced Coherence Extension Bus, enabling the IOMMU system to achieve efficient access to main memory. This access method further improves the overall efficiency of address translation and system performance.

[0158] In some embodiments, the IOATC module and the IOATS module communicate with each other through the DTI Interconnet module.

[0159] In practical applications, unifying communication requests between IOATC and IOATS through the DTI Interconnet module significantly reduces coupling between modules, making the entire system more flexible and scalable. Furthermore, since the distributed translation interface interconnect module supports parallel processing of multiple I / O requests, it effectively reduces latency during address translation and improves I / O access efficiency.

[0160] In summary, this embodiment of the application achieves efficient communication between IOATC and IOATS by introducing a DTI Interconnet module. Introducing the DTI Interconnet module improves the memory access performance of I / O devices, thereby accelerating data processing capabilities in virtualized environments and meeting the challenges of high-performance I / O requirements in data centers.

[0161] In a feasible scenario, such as Figure 2 As shown in the diagram, this application provides a RISC-V IOMMU architecture. This application places the IOATC module close to the input / output peripherals, with multiple device I / O access requests having independent IOATC modules. This distributed structure requires only one IOATS to manage and serve multiple IOATCs, offering significant resource advantages. Addressing the issue in related technologies where multiple IOATC I / O requests undergo a complex and lengthy queue process from the device to the client system, prolonging I / O access time and resulting in significant performance loss for I / O devices, this application designs a TSPWC module within the shared IOATS module that enables parallel page table lookups and eliminates information redundancy. This significantly improves address translation efficiency, reduces address translation latency, and more effectively utilizes system resources, meeting the needs of high-performance peripherals accessing system main memory.

[0162] like Figure 2 As shown, the IOMMU architecture mainly includes the following functional modules:

[0163] 1. IOATC module, including the following functions: (1) It has two-level TLB modules. The first-level uTLB module adopts a fully associative structure, and the second-level MTLB module adopts a group-configurable group-associative structure to cache the data types that the IOMMU needs to access during the address translation process, including the device context DC in the device directory table, the process context PC in the process directory table, the page table entries of the first or second stage address translation, the page table entries of MSI, etc., to accelerate DMA conversion; (2) It replaces and updates the cached entries to improve the hit rate; (3) It executes the commands in the command queue to maintain cache consistency.

[0164] 2. The IOATS module includes the following functions: (1) It has a built-in TSPWC module to reduce page table information redundancy, significantly improve the number of page table entries and hit rate that TSPWC can accommodate, and can be configured with direct mapping or group associative structure to perform page table retrieval in parallel and synchronously process address translation requests from the IOATS module, thereby improving the virtual machine transmission efficiency; (2) It locates parameters and data translation structures based on the device context (DC) of memory; (3) It performs single-stage or two-stage address translation on input / output virtual addresses (IOVA); (4) It performs MSI address translation in two modes; (5) It provides address translation services (ATS) and page request interface (PRI) services for the high-speed serial computer extended bus standard (PCIExpress, PCIe); (6) It parses commands from the software and passes them to IOATS.

[0165] 3. Distributed Translation Interface Interconnect (DTI Interconnet) module, including the following functions: (1) Processing DMA requests or MSI writes from devices and calling IOATS for address translation; (2) Processing PRI requests from PCIe devices with supported ATS services using the DTI-ATS protocol and calling IOATS for address translation.

[0166] In this embodiment, the overall workflow of the IOMMU is as follows:

[0167] First, the physical memory attributes and physical memory protection of the address to be translated are checked.

[0168] Secondly, the I / O peripherals transmit the device context (DC) and process context (PC) information attached to the address translation request to the IOATC module via the ACE-Lite bus. If the IOATC hits, the DC is obtained directly; if the IOATC module misses, the information is transmitted to the IOATS module for querying via the DTI bus interconnect module.

[0169] Then, after obtaining the corresponding device and process context, the I / O peripheral transmits IOVA to the IOATC submodule via the ACE-Lite bus. If IOATC hits, it directly translates IOVA into IOPA; if the IOATC module misses, it transmits IOVA to the IOATS module via the DTI bus interconnect module.

[0170] Finally, the TSPWC module uses the PTW process to query the level 3 page table entries recorded in the TSPWC for comparison. If a match is found, it only needs to query the page table entries in main memory to find the final IOPA, and then interact with the system main memory through the APB bus or ACE-Lite bus.

[0171] In addition, the process of issuing PRI requests to the PCIe internal ATS can be directly passed to the IOATS module through the DTI bus interconnect module for further address translation.

[0172] In this embodiment, the TSPWC module can perform parallel lookups for multiple address translation requests initiated by the distributed IOATC module. This differs from the traditional PWC cache page table data mode, where the traditional PWC hybrid cache multi-level page table queries the page table sequentially. When faced with multiple address translation requests, this leads to a significant increase in query latency, which inevitably affects the address translation efficiency of the entire program and drags down the performance of the entire IOMMU system.

[0173] like Figure 3 As shown, the TSPWC module divides the cache into three blocks. Block 1 stores only the fourth-level index of the virtual address (VA) and the starting address of the third-level page table; Block 2 stores only the third-level index of the virtual address and the starting address of the second-level page table; and Block 3 stores only the second-level index of the virtual address and the starting address of the first-level page table. Each entry stores a different index to avoid information redundancy. In traditional PWC mode, cache page table data redundancy is concentrated in the second, third, and fourth-level indexes. Taking the RISC-VSV48 mapping process as an example, the virtual address is translated into a physical address.

[0174] This application uses a subset of bits from each level of the virtual address index (the number of bits is adjustable in specific implementations to regulate the number of page table entries for different blocks, thus achieving TSPWC extension) to generate an index corresponding to each sub-memory. This index is then used to simultaneously query the corresponding three blocks in parallel, selecting the hit results from these three blocks as the final result of the query directly mapping the Walk cache. The hit result from Block 3 has the highest priority, while the hit result from Block 1 has the lowest priority.

[0175] Furthermore, this application uses the last bit of the virtual address index at each level, and the direct mapping TSPWC consisting of Block 1 (containing 2 entries), Block 2 (containing 4 entries), and Block 3 (containing 8 entries) as an example for explanation.

[0176] Taking the RISC-V SV48 mapping process as an example, the address translation PTW access to TSPWC process is as follows: Figure 4 The TSPWC workflow shown below:

[0177] If the IOATC module hits, the physical address is obtained. If the IOATC module misses, the IOATS TSPWC module receives multiple address translation requests from the distributed IOATC module, each carrying a virtual address.

[0178] In parallel execution, the TSPWC module obtains the low-order bits of different levels of the virtual address index, including: obtaining the low-order bits of the fourth-level index of the virtual address; obtaining the low-order bits of the fourth-level index of the virtual address and the low-order bits of the third-level index of the virtual address; obtaining the low-order bits of the fourth-level index of the virtual address, the low-order bits of the third-level index of the virtual address, and the low-order bits of the second-level index of the virtual address; and then performs parallel queries.

[0179] Here, the three Block indexes can be generated simultaneously and distributed in parallel as soon as the virtual address arrives at the TSPWC.

[0180] Parallel lookup includes: Parallel 1: Block1 uses 39 bits of IOVA[47:39] as the index of the 4th level page table, and searches for the page table entry in the TSPWCP cache based on this index. If a match is found, the base address of the 3rd level page table is obtained, and the result is fed back to the match result determination module. If a match is not found, the PTW process is directly entered, accessing main memory 4 times to complete the virtual address translation.

[0181] Parallelism 2: Block2 uses the 39th bit of IOVA[47:39] concatenated with the 30th bit of IOVA[38:30] as the index of the level 3 page table to search for the page table entry in the TSPWCP cache. If a match is found, the base address of the level 2 page table is obtained, and the result is fed back to the match result determination module.

[0182] Parallelism 3: Block3 uses the 39th bit of IOVA[47:39], the 30th bit of IOVA[38:30], and the 21st bit of IOVA[29:21] as the index of the second-level page table to search for the page table entry in the TSPWCP cache. If a match is found, the base address of the first-level page table is obtained, and the result is fed back to the match result determination module.

[0183] Hit determination module: According to the priority of Block1, Block2, and Block3 (Block3>Block2>Block1), the hit results of these three sub-storages are selected as the final result (i.e., the final physical address) of querying the direct mapping TSPWC.

[0184] PTW process: If Block 3 hits, the base address of the first-level page table is found, and the physical address of the data can be obtained by accessing memory only once. If Block 2 hits, the base address of the second-level page table is found, and the physical address of the data can be obtained by accessing memory twice, and so on.

[0185] The advantage of this mechanism is that it eliminates redundant information and enables parallel lookup of virtual address indexes, which greatly improves the efficiency of virtual address translation and avoids excessive resource consumption.

[0186] As described above, the RISC-V architecture-based distributed IOATC module design places the physical distance closer to the device port. Multiple IOATC modules correspond to one IOATS module, reducing the coupling between modules within the IOMMU system. This allows multiple virtual machines to share the same physical resources, significantly improving resource utilization efficiency. The TSPWC module structure solves the problem of insufficient space utilization caused by excessive redundant information in the traditional PWC structure. It can store more effective information, reduce memory access frequency, and thus improve I / O performance. Traditional PWC structures require sequential lookups of the PWC for the high-level index of virtual addresses. Multiple I / O access requests significantly increase lookup latency, prolonging I / O access time and resulting in a significant performance loss for the I / O device. The TSPWC module provided in this application, through a tree-structure design, enables parallel access to I / O requests, accelerating the I / O access process. It can quickly complete the DMA request for memory from the I / O device in just a few clock cycles.

[0187] This application also provides an information processing device, such as... Figure 5 As shown, the device includes:

[0188] Processing unit 501 is used to call input / output address translation cache module to receive first address translation request; wherein, the first address translation request is used to request translation of first input / output virtual address;

[0189] Processing unit 501 is used to call the input / output address translation cache module to respond to the first address translation request. If the first translation result of the first input / output virtual address has been cached, the first translation result is sent to the initiator of the first address translation request.

[0190] The processing unit 501 is used to, if not cached, call the input / output address translation service module to respond to the first address translation request, and query multiple blocks included in the tree-structured page access cache module in parallel; wherein, the multiple blocks are used to store the starting address and index of the hierarchical page table; based on the starting address of the next-level page table queried from the first input / output virtual address and the index of the current level, query the page table entries from the main memory to obtain the second translation result, and send the second translation result to the initiator.

[0191] In some embodiments, the processing unit 501 is configured to, if not found, call the input / output address translation service module to query the page table from the main memory level by level to obtain the second translation result, and send the second translation result to the initiator.

[0192] In some embodiments, the processing unit 501 is configured to extract a portion of bits from the first input / output virtual address to generate an index for each block; to perform parallel queries in each of the multiple blocks, and to select a query result from the hit results of the multiple blocks based on a priority arbitration strategy and the index of each block; wherein the query result includes the starting address of the next-level page table and the index of the current level.

[0193] In some embodiments, the tree-structured page access cache module includes three blocks. The first block stores the fourth-level index of the virtual address and the starting address of the third-level page table. The second block stores the third-level index of the virtual address and the starting address of the second-level page table. The third block stores the second-level index of the virtual address and the starting address of the first-level page table. The indexes of the virtual addresses stored in the first, second, and third blocks are different, and the priority of the hit results in the first, second, and third blocks increases sequentially.

[0194] In some embodiments, the processing unit 501 is used to call the input / output address translation cache module to respond to the first address translation request, find the first translation result in the first-level address translation cache module, and determine that it has been cached; wherein, the first translation result includes the device context.

[0195] In some embodiments, the processing unit 501 is configured to find a first translation result in the second-level address translation cache module when no translation result is found in the first-level address translation cache module, and determine that it has been cached; wherein the first translation result includes a physical address; and if the first translation result is not found in the second-level address translation cache module, determine that it has not been cached.

[0196] In some embodiments, the processing unit 501 is configured to call the input / output address translation service module to receive a second address translation request; wherein the second address translation request is used to request the translation of a second input / output virtual address, and the second address translation request includes a page request interface request from a high-speed serial computer extended bus standard device that supports address translation service; and the input / output address translation service module is called to respond to the second address translation request.

[0197] In some embodiments, the processing unit 501 is configured to call the input / output address translation service module to receive a third address translation request; wherein, the third address translation request is used to request the translation of a third input / output virtual address, and the third address translation request includes a direct memory access request or message signal interrupt write from a high-speed serial computer extended bus standard device; and the input / output address translation service module is called to respond to the third address translation request.

[0198] In some embodiments, the high-speed serial computer extended bus standard device and the input / output address translation service module are connected to each other via a distributed conversion interface interconnect module.

[0199] In some embodiments, the processing unit 501 is configured to access main memory via an advanced peripheral bus or an advanced coherence extension bus, load page table entries in main memory, and query page table entries based on the starting address of the next-level page table and the index of the current level to obtain a second translation result.

[0200] In some embodiments, the input / output address translation cache module and the input / output address translation service module are connected to each other through a distributed conversion interface interconnect module.

[0201] Embodiments of this application provide an electronic device that can be applied to... Figure 1 In a corresponding embodiment of an information processing method, referring to Figure 6 As shown, the electronic device 600 includes: a processor 601, a memory 602, and a communication bus 603, wherein:

[0202] The communication bus 603 is used to realize the communication connection between the processor 601 and the memory 602.

[0203] The memory 602 is used to store computer programs that can run on the processor 601;

[0204] The processor 601, when running a computer program, performs the following steps:

[0205] The input / output address translation cache module is invoked to receive the first address translation request; wherein, the first address translation request is used to request the translation of the first input / output virtual address;

[0206] The input / output address translation cache module is invoked to respond to the first address translation request. If the first translation result of the first input / output virtual address has been cached, the first translation result is sent to the initiator of the first address translation request.

[0207] If not cached, the input / output address translation service module is invoked to respond to the first address translation request, and multiple blocks included in the tree-structured page access cache module are queried in parallel; among them, multiple blocks are used to store the starting address of the hierarchical page table and the index of the hierarchical page table;

[0208] Based on the starting address of the next-level page table obtained from the first input / output virtual address and the index of the current level, the second translation result is obtained by querying the page table entry in main memory and then sent to the initiator.

[0209] In some embodiments, the processor 601, when running a computer program, performs the following steps: if not found, it calls the input / output address translation service module to query the page table from main memory level by level to obtain the second translation result, and sends the second translation result to the initiator.

[0210] In some embodiments, the processor 601, when running a computer program, performs the following steps: extracting a portion of bits from a first input / output virtual address to generate an index for each block; querying in parallel within each of the multiple blocks, and selecting a query result from the hit results of the multiple blocks based on a priority arbitration strategy and the index of each block; wherein the query result includes the starting address of the next-level page table and the index of the current level.

[0211] In some embodiments, the tree-structured page access cache module includes three blocks. The first block stores the fourth-level index of the virtual address and the starting address of the third-level page table. The second block stores the third-level index of the virtual address and the starting address of the second-level page table. The third block stores the second-level index of the virtual address and the starting address of the first-level page table. The indexes of the virtual addresses stored in the first, second, and third blocks are different, and the priority of the hit results in the first, second, and third blocks increases sequentially.

[0212] In some embodiments, when the processor 601 is running a computer program, it performs the following steps: calling an input / output address translation cache module in response to a first address translation request, finding a first translation result in a first-level address translation cache module, and determining that it has been cached; wherein the first translation result includes a device context.

[0213] In some embodiments, when the processor 601 is running a computer program, it performs the following steps: if a translation result is not found in the first-level address translation cache module, a first translation result is found in the second-level address translation cache module, and it is determined that the result has been cached; wherein the first translation result includes a physical address; if the first translation result is not found in the second-level address translation cache module, it is determined that the result has not been cached.

[0214] In some embodiments, when the processor 601 is running a computer program, it performs the following steps: calling an input / output address translation service module to receive a second address translation request; wherein the second address translation request is used to request the translation of a second input / output virtual address, and the second address translation request includes a page request interface request from a high-speed serial computer extended bus standard device that supports address translation services; and calling the input / output address translation service module to respond to the second address translation request.

[0215] In some embodiments, when the processor 601 is running a computer program, it performs the following steps: calling an input / output address translation service module to receive a third address translation request; wherein the third address translation request is used to request the translation of a third input / output virtual address, and the third address translation request includes a direct memory access request or message signal interrupt write from a high-speed serial computer extended bus standard device; and calling the input / output address translation service module to respond to the third address translation request.

[0216] In some embodiments, the high-speed serial computer extended bus standard device and the input / output address translation service module are connected to each other via a distributed conversion interface interconnect module.

[0217] In some embodiments, when running a computer program, the processor 601 performs the following steps: accessing main memory via an advanced peripheral bus or an advanced coherence extension bus, loading page table entries in main memory, and querying page table entries based on the starting address of the next-level page table and the index of the current level to obtain a second translation result.

[0218] In some embodiments, the input / output address translation cache module and the input / output address translation service module are connected to each other through a distributed conversion interface interconnect module.

[0219] A processor can be an integrated circuit chip with signal processing capabilities, such as a general-purpose processor, a digital signal processor (DSP), or other programmable logic devices, discrete gate or transistor logic devices, discrete hardware components, etc. Among them, a general-purpose processor can be a microprocessor or any conventional processor.

[0220] It should be noted that the descriptions of the same steps and contents as in other embodiments in this embodiment can be found in the descriptions in other embodiments, and will not be repeated here.

[0221] Embodiments of this application provide a computer storage medium storing one or more programs, which can be executed by one or more processors to achieve, for example... Figure 1 The steps are shown.

[0222] It should be noted that the descriptions of the same steps and contents as in other embodiments in this embodiment can be found in the descriptions in other embodiments, and will not be repeated here.

[0223] It should be noted that the aforementioned computer storage media / memory can be read-only memory (ROM), programmable read-only memory (PROM), erasable programmable read-only memory (EPROM), electrically erasable programmable read-only memory (EEPROM), magnetic random access memory (FRAM), flash memory, magnetic surface memory, optical disc, or compact disc read-only memory (CD-ROM), etc.; it can also be various terminals that include one or any combination of the above-mentioned memory, such as mobile phones, computers, tablet devices, personal digital assistants, etc.

[0224] Embodiments of this application provide a computer program product, including a computer program that can be executed by a processor 601 of an electronic device 600 to perform tasks such as... Figure 1 The steps are shown.

[0225] In the several embodiments provided in this application, it should be understood that the disclosed devices and methods can be implemented in other ways. The device embodiments described above are merely illustrative. For example, the division of units is only a logical functional division, and in actual implementation, there may be other division methods, such as: multiple units or components can be combined, or integrated into another system, or some features can be ignored or not executed. In addition, the coupling, direct coupling, or communication connection between the various components shown or discussed can be through some interfaces, and the indirect coupling or communication connection between devices or units can be electrical, mechanical, or other forms.

[0226] The units described above as separate components may or may not be physically separate. The components shown as units may or may not be physical units, that is, they may be located in one place or distributed across multiple network units. Some or all of the units may be selected to achieve the purpose of this embodiment according to actual needs.

[0227] Furthermore, in the various embodiments of this application, all functional units can be integrated into one processing module, or each unit can be a separate unit, or two or more units can be integrated into one unit. The integrated unit can be implemented in hardware or in a combination of hardware and software functional units. Those skilled in the art will understand that all or part of the steps of the above method embodiments can be implemented by hardware related to program instructions. The aforementioned program can be stored in a computer-readable storage medium. When the program is executed, it performs the steps of the above method embodiments. The aforementioned storage medium includes various media capable of storing program code, such as mobile storage devices, read-only memory (ROM), random access memory (RAM), magnetic disks, or optical disks.

[0228] The methods disclosed in the several method embodiments provided in this application can be arbitrarily combined without conflict to obtain new method embodiments.

[0229] The features disclosed in the several product embodiments provided in this application can be arbitrarily combined without conflict to obtain new product embodiments.

[0230] The features disclosed in the several method or device embodiments provided in this application can be arbitrarily combined without conflict to obtain new method or device embodiments.

[0231] The above are merely specific embodiments of this application, but the scope of protection of this application is not limited thereto. Any changes or substitutions that can be easily conceived by those skilled in the art within the scope of the technology disclosed in this application should be included within the scope of protection of this application.

Claims

1. An information processing method characterized by comprising: The method comprises: calling an input-output address translation cache module to receive a first address translation request; wherein the first address translation request is used to request translation of a first input-output virtual address; calling the input-output address translation cache module to respond to the first address translation request, and if a first translation result of the first input-output virtual address has been cached, sending the first translation result to an initiator of the first address translation request; if not cached, calling an input-output address translation service module to respond to the first address translation request, and querying a plurality of blocks included in a tree-shaped page access cache module in parallel; wherein the plurality of blocks are used to store a starting address of a hierarchical page table and an index of a current level of the hierarchical page table; based on the starting address of the next level page table and the index of the current level queried from the first input-output virtual address, querying a page table item from a main memory to obtain a second translation result, and sending the second translation result to the initiator; wherein the plurality of blocks included in the tree-shaped page access cache module comprises: extracting part of the bits from the first input-output virtual address to generate an index of each of the blocks; querying in parallel in each of the plurality of blocks, and based on a priority arbitration strategy and the index of each of the blocks, selecting a query result from hit results of the plurality of blocks; wherein the query result comprises the starting address of the next level page table and the index of the current level.

2. The method of claim 1, wherein, The method further comprises: if not queried, calling the input-output address translation service module to query the page table from the main memory level by level to obtain the second translation result, and sending the second translation result to the initiator.

3. The method according to claim 1 or 2, characterized in that, The tree-shaped page access cache module comprises three blocks, a first block of the three blocks stores a fourth level index of a virtual address and a third level page table starting address, a second block of the three blocks stores a third level index of a virtual address and a second level page table starting address, and a third block of the three blocks stores a second level index of a virtual address and a first level page table starting address, the indexes of the virtual addresses stored in the first block, the second block and the third block are different, and the priority of the hit results of the first block, the second block and the third block increases in turn.

4. The method of claim 1, wherein, The method further comprises: calling the input-output address translation cache module to respond to the first address translation request, finding the first translation result in a first level address translation cache module, and determining that the first translation result has been cached; wherein the first translation result comprises a device context.

5. The method of claim 4, wherein, The method further comprises: if the first translation result is not found in the first level address translation cache module, finding the first translation result in a second level address translation cache module, and determining that the first translation result has been cached; wherein the first translation result comprises a physical address; if the first translation result is not found in the second level address translation cache module, determining that the first translation result has not been cached.

6. The method of claim 1, wherein, The method further comprises: The input / output address translation service module is invoked to receive a second address translation request; wherein the second address translation request is used to request translation of a second input / output virtual address, and the second address translation request includes a page request interface request from a high-speed serial computer expansion bus standard device supporting address translation services; The input / output address translation service module is invoked to respond to the second address translation request.

7. The method of claim 1, wherein, The method further comprises: The input / output address translation service module is invoked to receive a third address translation request; wherein the third address translation request is used to request translation of a third input / output virtual address, and the third address translation request includes a direct memory access request or a message signal interrupt write from a high-speed serial computer expansion bus standard device; The input / output address translation service module is invoked to respond to the third address translation request.

8. The method according to claim 6 or 7, characterized in that, The high-speed serial computer expansion bus standard device and the input / output address translation service module are connected in communication through a distributed translation interface interconnection module.

9. The method of any one of claims 1-2, 4-7, wherein, The start address of the next level page table and the index of the current level queried based on the first input / output virtual address are used to query a page table entry from a main memory to obtain the second translation result, which comprises: The main memory is accessed through an advanced peripheral bus or an advanced coherent expansion bus, the page table entry in the main memory is loaded, and the second translation result is queried based on the start address of the next level page table and the index of the current level.

10. The method of any one of claims 1-2, 4-7, wherein, The input / output address translation cache module and the input / output address translation service module are connected in communication through a distributed translation interface interconnection module.

11. An information processing apparatus comprising: It comprises: A processing module is configured to invoke an input / output address translation cache module to receive a first address translation request; wherein the first address translation request is used to request translation of a first input / output virtual address; The processing module is configured to invoke the input / output address translation cache module to respond to the first address translation request, and if a first translation result of the first input / output virtual address has been cached, send the first translation result to an initiator of the first address translation request; The processing module is configured to invoke an input / output address translation service module to respond to the first address translation request if it is not cached, and query a plurality of blocks included in a tree-shaped page access cache module in parallel; wherein the plurality of blocks are used to store start addresses of hierarchical page tables and indexes of hierarchical page tables; The processing module is configured to query a page table entry from a main memory based on a start address of a next level page table and an index of a current level queried based on the first input / output virtual address to obtain a second translation result, and send the second translation result to the initiator; The processing module is configured to extract part of bits from the first input / output virtual address to generate an index of each of the blocks, query each of the blocks included in the plurality of blocks in parallel, and select a query result from hit results of the plurality of blocks based on a priority arbitration strategy and the index of each of the blocks; wherein the query result includes the start address of the next level page table and the index of the current level.

12. An electronic device, comprising: It comprises: a processor and memory for storing a computer program capable of running on the processor, wherein the processor is configured to execute the steps of any of the methods of claims 1 to 10 when running the computer program.

13. A storage medium having stored thereon a computer program, characterized in that The computer program, which when executed by a processor, carries out the steps of any of the methods of claims 1 to 10.

14. A computer program product comprising a computer program, characterized in that, The computer program, which when executed by a processor, carries out the steps of any of the methods of claims 1 to 10. The computer program, which when executed by a processor, carries out the steps of any of the methods of claims 1 to 10.

Images