Multi-process dma access method and device based on device end context recognition, chip

Abstract

The application relates to the field of data processing, and provides a multi-process DMA access method and device based on device end context recognition and a chip. The method comprises the following steps: when initiating a DMA operation, a target VF generates a DMA request containing a local virtual address of the target VF; a VFID corresponding to the target VF is extracted from the DMA request, a virtual function address conversion table in a terminal device is inquired according to the VFID, and an address mapping table is acquired; the local virtual address of the target VF is converted into a corresponding DVA through the address mapping table; a standard PCIe TLP is generated based on the converted DVA; and the TLP is sent to a host, so that an input / output memory management unit or an address conversion service on the host side converts the DVA into a host physical address HPA, and the DMA operation is completed. Through the front movement of the multi-process address conversion from the host side to the terminal device side, a more efficient DMA access path is realized without relying on a PASID.

Description

Technical Field

[0001] This application relates to the field of data processing, and more specifically, to a multi-process DMA access method, apparatus, and chip based on device-side context recognition. Background Technology

[0002] In modern computing systems, such as high-performance computing, cloud computing, and edge computing, Direct Memory Access (DMA) technology can improve data processing efficiency and reduce CPU overhead. DMA allows external devices (such as GPUs, smart network cards, and AI accelerators) to exchange data directly with host memory without continuous CPU involvement. As application scenarios become more complex, the need for a single terminal device to serve multiple user processes or virtual machines (VMs) simultaneously is becoming increasingly common, leading to the need for support for concurrent DMA access across multiple processes.

[0003] In such environments, a physical high-speed serial computer expansion bus standard (Peripheral Component Interconnect Express, PCIe) device (such as a GPU or smart network card) is often virtualized as multiple virtual functions (VFs) to simultaneously serve multiple user processes or virtual machines with independent address spaces. This raises a core issue: when a device initiates DMA, how can it accurately, safely, and efficiently translate and isolate virtual address requests from different processes, ultimately mapping them to the correct host physical address (HPA)? This process typically involves two key translation stages: first, mapping the process virtual address (VA) to a device-recognizable virtual address (DVA) to achieve process isolation; and second, translating the DVA into an HPA via the host IOMMU.

[0004] Currently, solutions to the aforementioned core problems primarily rely on the PCIe Process Address Space ID (PASID) mechanism. In related technologies, the host assigns a unique PASID to each process. When a device's virtual function initiates a DMA request, this PASID is appended to the Transaction Layer Packet (TLP). The TLP is the core transmission unit of the transaction layer in the PCIe protocol stack, responsible for transmitting data, configuration information, and control commands between devices. After the TLP is transmitted to the host, the Input-Output Memory Management Unit (IOMMU) uses the PASID to look up the corresponding process's page table, completing address translation and access isolation. However, the PASID field appended to the TLP introduces significant bandwidth overhead in small-granularity data transmission, increases processing latency and the IOMMU burden during high-frequency concurrent access, and the lack of address management autonomy on the device side restricts system scalability and flexibility. Therefore, a technical solution is urgently needed to address at least one of the aforementioned technical problems, achieving a more efficient DMA access path without relying on PASID. Summary of the Invention

[0005] In this context, the embodiments of this application aim to provide a multi-process DMA access method, apparatus, and chip based on device-side context recognition, which can achieve a more efficient DMA access path without relying on PASID by moving multi-process address translation from the host side to the terminal device side.

[0006] In a first aspect of the embodiments of this application, a multi-process DMA access method based on device-side context recognition is provided. This method is applied to a computing system supporting hardware virtualization, the computing system including a host and terminal devices, the terminal devices being virtualized into multiple Virtual Functions (VFs), each VF serving a user process or virtual machine. The method includes:

[0007] When any target VF of the terminal device initiates a direct memory access (DMA) operation, the target VF generates a DMA request containing the target VF's local virtual address;

[0008] Extract the Virtual Function Number (VFID) corresponding to the target VF from the DMA request, query the Virtual Function Address Translation Table in the terminal device according to the VFID, and obtain the address mapping table dedicated to the target VF. Each entry in the Virtual Function Address Translation Table corresponds one-to-one with each VF, and each entry points to the address mapping table dedicated to the corresponding VF. The address mapping table dedicated to the VF is used to define the translation relationship from the local virtual address of the corresponding VF to the device virtual address (DVA).

[0009] The target VF's local virtual address is translated into the corresponding device virtual address (DVA) through the target VF's dedicated address mapping table;

[0010] Based on the converted DVA, a standard PCIe transaction layer data packet TLP is generated, which includes a data payload and an address field carrying the DVA;

[0011] The TLP is sent to the host so that the host-side Input / Output Memory Management Unit (IOMMU) or Address Translation Service (ATS) can translate the DVA into a host physical address (HPA) to complete the DMA operation.

[0012] In a second aspect of the embodiments of this application, a multi-process DMA access device based on device-side context recognition is provided. The device is applied to a computing system supporting hardware virtualization. The computing system includes a host and terminal devices. The terminal devices are virtualized into multiple Virtual Functions (VFs), each VF serving a user process or virtual machine. The device includes the following units:

[0013] The request unit is used to generate a DMA request containing the local virtual address of the target VF when any target VF of the terminal device initiates a direct memory access DMA operation.

[0014] The lookup unit is used to extract the Virtual Function Number (VFID) corresponding to the target VF from the DMA request, query the Virtual Function Address Translation Table in the terminal device according to the VFID, and obtain the address mapping table dedicated to the target VF. Each entry in the Virtual Function Address Translation Table corresponds one-to-one with each VF, and each entry points to the address mapping table dedicated to the corresponding VF. The address mapping table dedicated to the VF is used to define the translation relationship from the local virtual address to the device virtual address (DVA) of the corresponding VF.

[0015] The translation unit is used to translate the local virtual address of the target VF into the corresponding device virtual address (DVA) through the target VF's dedicated address mapping table;

[0016] The access unit is used to generate a standard PCIe transaction layer data packet (TLP) based on the converted DVA. The TLP includes a data payload and an address field carrying the DVA. The TLP is then sent to the host so that the host-side input / output memory management unit (IOMMU) or address translation service (ATS) can convert the DVA into a host physical address (HPA) to complete the DMA operation.

[0017] In a third aspect of the embodiments of this application, a terminal device is provided, the terminal device comprising: at least one processor, a memory, and an input / output unit; wherein the memory is used to store a computer program, and the processor is used to invoke the computer program stored in the memory to execute the multi-process DMA access method based on device-side context identification as described in the first aspect.

[0018] In a fourth aspect of the embodiments of this application, a computer-readable storage medium is provided, which includes instructions that, when executed on a computer, cause the computer to perform the multi-process DMA access method based on device-side context identification as described in the first aspect.

[0019] In a fifth aspect of the embodiments of this application, a computer program product is provided, including a computer program that, when executed by a processor, implements the multi-process DMA access method based on device-side context identification as described in the first aspect.

[0020] In a sixth aspect of the embodiments of this application, a chip is provided that includes a computer program, which, when executed by a processor, implements the multi-process DMA access method based on device-side context recognition as described in the first aspect.

[0021] This application discloses a multi-process DMA access method, apparatus, and chip based on device-side context identification. The technical solution of this application is applied to a computing system supporting hardware virtualization. The computing system includes a host and terminal devices. The terminal devices are virtualized into multiple Virtual Functions (VFs), each serving a user process or virtual machine. First, when any target VF of the terminal device initiates a direct memory access (DMA) operation, the target VF generates a DMA request containing its local virtual address. Then, the Virtual Function ID (VFID) corresponding to the target VF is extracted from the DMA request. Based on the VFID, the Virtual Function Address Translation Table (VFID) within the terminal device is queried to obtain the target VF's dedicated address mapping table. Each entry in the VFID corresponds one-to-one with each VF, and each entry points to the corresponding VF's dedicated address mapping table. The VF-specific address mapping table defines the conversion relationship between the corresponding VF's local virtual address and its Device Virtual Address (DVA). Next, the target VF's local virtual address is converted to the corresponding DVA using the target VF-specific address mapping table. Furthermore, a standard PCIe transaction layer data packet (TLP) is generated based on the converted DVA. The TLP includes a data payload and an address field carrying the DVA. Finally, the TLP is sent to the host so that the host-side Input / Output Memory Management Unit (IOMMU) or Address Translation Service (ATS) can translate the DVA into a host physical address (HPA) to complete the DMA operation. This application's technical solution greatly simplifies the TLP structure and reduces the IOMMU load by moving the core logic of multi-process address translation from the host side to the terminal device side. Simultaneously, by enhancing device autonomy, it provides superior infrastructure support for the development of high-performance computing systems, fundamentally overcoming the limitations of the traditional PASID mechanism. Attached Figure Description

[0022] Figure 1 This application illustrates a flowchart of a multi-process DMA access method based on device-side context recognition.

[0023] Figure 2 A flowchart illustrating the hardware virtualization address allocation method supported by the existing Pasid technology;

[0024] Figure 3 This application illustrates a real-world scenario example of a multi-process DMA access method based on device-side context recognition. Detailed Implementation

[0025] The following is for reference. Figure 1 , Figure 1This is a flowchart illustrating a multi-process DMA access method, apparatus, and chip based on device-side context recognition, provided in one embodiment of this application. It should be noted that the implementation methods of this application can be applied to scenarios such as chip design, multi-process DMA access based on device-side context recognition, and chip optimization.

[0026] In related technologies, the host assigns a unique PASID to each process. When a device's virtual function initiates a DMA request, this PASID is appended to the Transaction Layer Packet (TLP). After the TLP is transmitted to the host, the IOMMU uses the PASID to look up the corresponding process's page table, completing address translation and access isolation. However, in the above scheme, the PASID field appended to the TLP (usually 4DW) introduces significant bandwidth overhead in small-granularity data transmission, severely impacting PCIe link utilization. In high-frequency small-packet DMA scenarios, the appended PASID prefix increases decoding complexity and bus transmission latency, resulting in low request efficiency, easily forming a performance bottleneck, and reducing the system's concurrent processing capabilities. Furthermore, in the above scheme, address translation for all process contexts is centralized on the host side, requiring the IOMMU to maintain a large number of PASID contexts and page table entries. This will also become a performance bottleneck in multi-tenant or ultra-large-scale concurrent access scenarios, reducing the system's concurrent processing capabilities. Furthermore, the lack of autonomy in address management on the device side means that the configuration, modification, and synchronization of the address space must be controlled by the host. The lack of autonomy of the device itself limits the evolution of system architecture for intelligent devices (such as DPUs and AI chips).

[0027] In existing technologies, such as Figure 2 As shown, to support DMA access for multi-process virtualization at the hardware level, the host typically assigns a unique PASID to each user process and maintains a context table indexed by the PASID in the host-side IOMMU. Each virtual function runs independently within the terminal device. When a virtual function needs to initiate DMA access to the host, it constructs a PCIe Transaction Layer Packet (TLP) locally based on the virtual address in the process address space, and appends the corresponding process's PASID to the TLP prefix. This ensures that each TLP sent to the host carries the process address space ID and virtual address information. Figure 2 The diagram below illustrates multiple virtual functions on the terminal device side, namely virtual functions #1 to #N, and the TLPs output by these virtual functions. Taking one of the TLPs as an example, the TLP is sent to the host side through the device's PCIe controller. Figure 2 The middle section provides an example structure for TLP. Figure 2The TLP structure illustrated in the diagram includes a TLP prefix field, a TLP header, a data payload, and a TLP digest, where the PASID is encapsulated in the TLP prefix. After the TLP arrives at the host, it first enters the host-side PCIe root port and is handed over to the IOMMU or an equivalent address translation module for processing. Figure 2 The upper part also illustrates the hierarchical structure of the host-side PASID context table and the device virtual address to physical address mapping table. Specifically, the IOMMU uses the PASID carried in the TLP as an index to query the PASID context table. The corresponding context table entry provides the process's address space identifier, the base address of the process's page table, the specific mapping method control information, and an index pointing to the device virtual address to physical address mapping table. Subsequently, the IOMMU maps the virtual address carried in the TLP to a device virtual address or directly to a host virtual address based on the context information. Then, it further uses the device's virtual address to physical address mapping table to complete the final virtual address to host physical address translation. After obtaining the physical address, the memory controller performs the actual memory read / write operation, completing the DMA access.

[0028] While PASID-based hardware virtualization address allocation can achieve process-level address space isolation, it also introduces several technical challenges. First, because each DMA request's TLP must carry a PASID prefix, and the PASID extension field typically occupies an additional 4DW header length, the data ratio between the additional header and the payload becomes severely unbalanced in small-granularity data transmission scenarios. When the single packet data size is only 64B to 256B, a significant amount of bandwidth is consumed in carrying the PASID prefix, reducing the effective utilization of the PCIe link. Second, with a larger TLP structure, both the host and device sides need to handle variable-length prefixes when parsing the TLP at the link and transaction layers. This makes decoding and routing logic more complex. In high-frequency small-packet DMA scenarios, the additional prefix parsing and context lookup introduce considerable processing latency, increasing the round-trip latency of a single request, leading to a decrease in overall request throughput, easily creating a performance bottleneck on the bus side, and weakening the system's concurrent processing capabilities. Third, Figure 2The proposed scheme centralizes address translation for all process contexts on the host side. The IOMMU needs to maintain a massive number of PASID contexts and associated large-scale page tables or mapping entries. As the number of tenants and concurrent processes increases, the lookup, updating, and cache consistency maintenance of the PASID context table and page tables consume significant hardware resources and time. The IOMMU itself becomes a centralized bottleneck, limiting the system's scalability in cloud computing, multi-tenant, and ultra-large-scale concurrent environments. Finally, under this architecture, devices lack autonomy in managing their address space. The configuration, modification, and synchronization of the virtual address space rely entirely on unified control by the host-side software and the IOMMU. Terminal devices can only passively accept the host's address management policies. This is not ideal for new intelligent devices that emphasize autonomous scheduling and local resource management capabilities, such as DPUs, AI chips, and programmable network cards, thus limiting the evolution of system architectures towards device intelligence and decentralized resource management.

[0029] To address at least one of the aforementioned technical problems, embodiments of this application provide a multi-process DMA access method, apparatus, and chip based on device-side context recognition.

[0030] Specifically, this application eliminates the need to carry PASID in the TLP through device-side autonomous address translation. Specifically, the terminal device integrates a Virtual Function Address Translation Table (VF) and a VF-specific address mapping table. When the VF initiates a DMA request, the device hardware first identifies the process context based on the VFID and uses the locally stored mapping table to complete the translation from the VF's local virtual address to the device virtual address (DVA). This crucial step ensures that the TLP ultimately sent to the host only needs to contain the standard address field (DVA) and data payload, without any additional PASID extension fields. Therefore, the additional bandwidth overhead caused by the PASID field is fundamentally eliminated, significantly improving the effective data transmission efficiency of the PCIe link, especially suitable for high-frequency scenarios with small-granularity data transmission of 64B~256B. This application's embodiment has undergone architectural restructuring of the address translation responsibilities, offloading the process context identification and the first-stage address translation (VA→DVA) tasks from the host IOMMU to the terminal device for execution. The host-side IOMMU no longer needs to maintain independent PASID contexts and page table entries for each process. Instead, the IOMMU now only needs to handle a unified, process-independent mapping between the DVA address space and the HPA. This shift greatly simplifies the management burden and query complexity of the IOMMU, freeing it from the bottleneck of maintaining a large number of fine-grained contexts, thereby improving the system's scalability in multi-tenant, high-concurrency access scenarios. The core of this application's embodiments lies in endowing terminal devices with context awareness and autonomous address management capabilities. The device is no longer an endpoint passively dependent on host configuration and management, but can proactively and quickly identify the request source (VF) and independently complete critical address mapping operations through a built-in address translation table structure. This reduces frequent control signaling interactions between the device and the host, lowers access latency, and improves processing efficiency and concurrency capabilities on the device side. This enhanced device autonomy provides greater flexibility for the architectural design of intelligent edge devices such as DPUs and AI accelerators, supporting them to handle complex multi-tasking workloads more efficiently. In summary, the embodiments of this application, while maintaining DMA security isolation, significantly reduce PCIe request overhead, decrease dependence on host resources, improve system throughput and flexibility, and provide a more efficient DMA access path for high-performance computing and edge intelligent devices.

[0031] like Figure 3As shown, the hardware virtualization address allocation process proposed in this application introduces a virtual function address translation table and a hierarchical mapping structure of device virtual address to physical address mapping table between the terminal device and the host. This enables virtualized management of DMA access in multi-virtual-function and multi-process scenarios without relying on the PASID extended field. On the terminal device side, multiple virtual functions (virtual function #1 to virtual function #N) correspond to different user processes or virtual machines. Each virtual function is assigned a unique virtual function number (VFID) by the host during the configuration phase. The device internally sets up a virtual function address translation table. When a virtual function initiates a DMA request, the device first queries the translation table based on the VFID carried in the request, thereby locating the dedicated address mapping table corresponding to that virtual function (e.g., ...). Figure 3 (e.g., the virtual function #1 mapping table). Each virtual function's mapping table pre-records the translation relationship between the local virtual address and the device virtual address for that virtual function. The terminal device uses this mapping relationship to convert the local virtual address in the DMA request into a virtual address with a unified meaning, i.e. Figure 3 The virtual address is marked in the code, and the PCIe transaction layer data packet TLP is constructed based on it.

[0032] During the TLP construction phase, the terminal device only writes the converted virtual address into the standard address field of the TLP header and encapsulates the data to be transmitted into the TLP payload, thus forming a standard TLP structure that contains only the TLP header and the data payload. Figure 3 The diagram illustrates the structure of the TLP, specifically the arrangement of the TLP header and the data payload. It can be seen that, compared to... Figure 2 The structure contains the TLP prefix and the PASID field. Figure 3 The TLP in the illustrated scheme no longer carries additional PASID prefix information; the standard TLP transmitting the virtual address and data payload on the link is used instead. This TLP is sent by the PCIe controller of the terminal device to the PCIe root port on the host side, where it is then delivered to the address translation module in the host. On the host side, as... Figure 3 The upper part shows a mapping table between device virtual addresses and physical addresses (i.e., Figure 3The device's virtual address page table (based on an address-to-physical address mapping table) is used to translate the virtual address in the TLP header into the final physical address. An address space context table can also be configured to record information such as the address space identifier, page table base address, mapping mode control, and device address mapping table index. On the host side, based on the device identifier or a pre-configured address space identifier, the appropriate address space context is selected. Using the page table base address or mapping table index, the host searches for the physical address corresponding to the TLP virtual address in the device's virtual address-to-physical address mapping table, ultimately outputting the physical address and driving the memory controller to complete DMA read / write operations. Figure 3 As shown in the flowchart, this application decentralizes process-level context identification and mapping from local virtual address to device virtual address to the terminal device side. The TLP transmitted on the PCIe link does not need to carry extended fields such as PASID. The host side focuses on the unified translation and management of device virtual address to physical address. While maintaining the PCIe standard TLP format unchanged, it realizes hardware virtualization support for multiple virtual functions and multi-process DMA access, reduces link bandwidth overhead and address translation overhead, and provides a foundation for further implementation examples.

[0033] Figure 1 The flowchart of a multi-process DMA access method based on device-side context identification provided in one embodiment of this application includes:

[0034] In step S101, when any target VF of the terminal device initiates a direct memory access (DMA) operation, the target VF generates a DMA request containing the target VF's local virtual address.

[0035] This application applies to computing systems that support hardware virtualization. The computing system includes a host and terminal devices. The terminal devices are virtualized into multiple virtual functions (VFs), each VF serving a user process or virtual machine.

[0036] As an optional embodiment, in step S101, before any target VF of the terminal device initiates a direct memory access (DMA) operation and before the target VF generates a DMA request containing the target VF's local virtual address, the method further includes: during the host initialization phase, assigning a unique VFID to each VF of the terminal device; generating a dedicated address mapping table for each VF's process address space; setting the virtual function address translation table within the terminal device, and storing the address mapping tables of all VFs into the virtual function address translation table using the VFID as an index, and dynamically maintaining the virtual function address translation table.

[0037] Each entry in the virtual function address translation table points to the address mapping table specific to the corresponding VF, and each entry stores at least the address context information of the corresponding VF.

[0038] Optionally, the address context information includes at least the address mapping method of the corresponding VF, the base address of the mapping table, and an access control field. It is understood that the address context information contains at least three key fields: First, the base address of the mapping table, which, as a pointer or physical offset, precisely points to the starting position of the address mapping table specific to the target VF in the device memory. Second, the address mapping method, which controls the behavior of the device address translation unit (ATU), indicating which algorithm (e.g., a hierarchical indexing mode using multi-level page tables or a direct mapping mode based on offsets) should be used to resolve subsequent address translations. Finally, the access control field defines the VF's read and write permissions to the target memory region (e.g., read-only, read-write, etc.), thereby achieving hardware-level security isolation at the device end. By reading the indexed table entries, the terminal device can successfully locate and obtain the target VF's specific address mapping table, which specifically defines the translation logic from the VF's internal local virtual address to the device unified virtual address (DVA). This step enables terminal devices to autonomously identify and define permissions for different process or virtual machine contexts without relying on the PASID (Process Address Space ID) field in the PCIe protocol or querying the host IOMMU, laying the foundation for subsequently generating streamlined TLP packets and reducing PCIe bandwidth overhead.

[0039] In this optional embodiment, before step S101, the virtual function (VF) context allocation and address space modeling are completed by the host side during the system initialization phase. During the runtime phase, the terminal device autonomously completes address identification and DMA address translation based on VF identity, thereby achieving efficient isolated DMA access in multi-process or multi-virtual function environments. This application does not rely on protocol extension mechanisms such as PCIe PASID, but instead distinguishes and manages the address contexts of different VFs through a virtual function address translation table maintained on the device side, thus delegating address translation capabilities to the terminal device.

[0040] Specifically, during the host initialization phase, the host first performs virtualization configuration on the terminal device, assigning a unique Virtual Function Identifier (VFID) to each virtual function. This VFID serves as a unique index within the device to identify different VF contexts, distinguishing DMA access requests from different VFs. Subsequently, for each VF's corresponding process address space, the host generates a dedicated address mapping table based on the process's virtual memory layout and access requirements. This address mapping table describes the mapping relationship between the VF's local virtual addresses and the device's unified virtual address space. The mapping method can be page table mapping, segment mapping, or direct mapping, as indicated by the address mapping method field. After completing the above configuration, the host sends the address mapping table information for each VF to the terminal device, which then internally constructs and initializes the virtual function address translation table.

[0041] The Virtual Function Address Translation Table (VFID) is a key data structure within the terminal device. Indexed by the VFID, each entry corresponds to the address context of a VF. Each entry stores at least the VF's address mapping method, the base address of the corresponding address mapping table, and access control fields. The base address indicates the location of the VF's dedicated address mapping table within the device's internal storage, while the access control fields limit the range and types of addresses accessible to the VF, thus achieving hardware-level access isolation between different VFs. In this way, the terminal device can dynamically maintain the VFID during operation, updating the corresponding entries when a VF is created, destroyed, or its address space is adjusted, without frequent host-side intervention.

[0042] During operation, when any target Virtual Function (VF) in the terminal device needs to initiate a DMA operation, the VF only generates a DMA request containing its own local virtual address, without attaching additional process identification information to the request. Upon receiving the DMA request, the terminal device quickly locates the corresponding entry in the Virtual Function Address Translation Table (VFCAD) based on the VFID implicitly carried or implied in the request source, and reads the VF's address context information. Subsequently, the terminal device performs address translation on the target VF's local virtual address, starting from the base address of the mapping table, according to the address mapping method indicated in the entry, to obtain a unified virtual address on the device side. Only after completing this internal address translation does the terminal device generate a standard-format DMA access request and send it to the host side, thus initiating the subsequent device virtual address to host physical address translation process.

[0043] Using the above implementation, assume the terminal devices are virtualized as VF0 and VF1, serving two different user processes respectively. During system initialization, the host assigns VFID=0 to VF0 and VFID=1 to VF1, and generates two non-overlapping address mapping tables for each. During operation, DMA requests initiated by VF0 can only be resolved through the address mapping table indexed by VFID=0, and cannot access VF1's mapping table or address space, thus achieving address isolation and security control within the device.

[0044] Thus, by introducing a virtual function address translation table indexed by VFID within the terminal device, rapid address context identification and localized address translation in multi-VF scenarios are achieved. On one hand, DMA requests do not need to carry additional protocol fields such as PASID during the generation phase, reducing the bandwidth overhead of PCIe transaction layer messages and improving link utilization in small-granularity, high-frequency DMA scenarios. On the other hand, address isolation and access control for multiple VFs can be completed at the device end, significantly reducing the context management pressure on the host IOMMU and improving the overall system throughput and scalability. Simultaneously, this solution enhances the terminal device's autonomous capability for multi-process access, providing a more flexible and efficient DMA access foundation for system architectures targeting new device form factors such as intelligent accelerators and DPUs.

[0045] Optionally, in the above embodiment of step S101, generating a dedicated address mapping table for each VF's process address space includes: obtaining the virtual address space layout allocated by the host for the corresponding process; and constructing an independent address mapping structure for each VF within the terminal device based on the virtual address space layout. The address mapping structure is configured to map the process virtual address space of each VF to a global and contiguous DVA space.

[0046] For the process of generating a dedicated address mapping table for each VF as described in step S101, an address mapping construction mechanism based on process virtual address space reorganization is adopted. The host side perceives and obtains the original virtual address space layout information of the process, while the terminal device constructs an independent address mapping structure for each VF internally, unifying the originally discrete and non-contiguous process virtual address space into a global and contiguous device virtual address (DVA) space, thereby simplifying the device-side DMA address processing logic and improving access efficiency.

[0047] Specifically, during system initialization or VF binding, the host first obtains and parses the virtual address space layout information of the corresponding process. This layout information includes at least the virtual address ranges available for DMA access by the process, the starting address of each range, its length, and access attributes. This virtual address space is typically represented on the host side as multiple non-contiguous virtual memory segments, reflecting the operating system's dynamic allocation of process memory. After obtaining this layout information, the host sends it as part of the address context to the terminal device to guide the construction of the device-side address mapping structure.

[0048] After receiving the virtual address space layout, the terminal device constructs an independent address mapping structure for the corresponding VF within the device. This structure can be implemented using multi-level page tables, segment mapping tables, or mapping tables based on range descriptors. During construction, the terminal device does not require the original virtual address ranges of the process to maintain their original relative positions in the DVA space. Instead, it sequentially maps the virtual address spaces of all processes corresponding to the VF to a continuous range of DVA addresses according to a preset mapping strategy. For example, the device can allocate a continuous DVA space of sufficient length to cover all its accessible virtual address ranges for a VF, and sequentially map multiple scattered virtual address ranges in the process to different sub-ranges of this continuous DVA space, thereby forming a virtual continuous access view on the device side.

[0049] The mapping process described above essentially performs an address space rearrangement and abstraction. For the VF, its local virtual address still follows the original virtual address semantics of the process. For the DMA engine inside the terminal device, all access requests from the VF ultimately fall within a contiguous DVA address range. When processing DMA requests, the device only needs to locate the corresponding address mapping structure based on the VFID and convert the VF's process virtual address to the corresponding DVA address according to the range mapping relationship recorded in the structure, without needing to handle complex cross-VF address fragmentation issues.

[0050] For example, suppose a process has three virtual address ranges (VA1, VA2, and VA3) available for DMA in its virtual address space, and these ranges are not contiguous within the process's address space. When constructing the address mapping structure for the corresponding VF, the terminal device can map VA1, VA2, and VA3 sequentially to a contiguous DVA range (DVA). base To DVA end Different sub-ranges within VA2. When the VF initiates a DMA access to an address in VA2, the device can quickly convert it to a target address located in the contiguous DVA space by looking up a table, thereby generating subsequent DMA access requests.

[0051] Therefore, by mapping the process virtual address space of each VF to a contiguous DVA space on the device side, the management overhead of complex address fragmentation during DMA processing is reduced, making the internal address calculation, boundary checking, and permission verification logic of the device simpler and more efficient. Simultaneously, the natural isolation of the DVA spaces between different VFs avoids the security risks caused by address overlap, which is beneficial for achieving stable and scalable DMA access control in multi-process, multi-virtual-function concurrent scenarios. Furthermore, this contiguous DVA mapping method also provides a good foundation for subsequent address caching, prefetching, and batch DMA transfer optimization, improving the overall DMA access performance and system throughput of the terminal device.

[0052] Optionally, in the above embodiment of step S101, setting the Virtual Function Address Translation Table (VFID) internally within the terminal device and storing the address mapping tables of all VFs in the VFID using VFID as an index, and dynamically maintaining the VFID, includes: configuring the VFID as a hardware lookup table based on direct addressing via VFID, an index structure based on Content Addressable Memory (CAM), or a hardware lookup table. Each table entry stores address context information that constitutes the address translation context for the corresponding VF. When performing address translation, the terminal device directly indexes the corresponding table entry based on the VFID using hardware circuitry and loads the address translation context to complete the translation of the VF's local virtual address to the DVA.

[0053] In this optional embodiment, the virtual function address translation table is implemented within the terminal device as a hardware-level high-speed index and lookup structure. This is to achieve fast address context location and loading based on VFID without introducing additional protocol interactions or software intervention, thereby ensuring the determinism and real-time performance of address translation in multi-virtual-function concurrent DMA scenarios. From an implementation perspective, the virtual function address translation table can be configured as a hardware lookup table based on direct VFID addressing, or it can adopt a matching structure based on Content Addressable Memory (CAM), or an index structure implemented by combining a hardware lookup table with index logic. The specific implementation can be selected according to the hardware scale, number of VFs, and performance requirements of the terminal device.

[0054] In one implementation, the terminal device internally sets up a dedicated address translation context storage area. This area is organized according to the value range of VFIDs, with each VFID corresponding to a table entry at a fixed or predictable location. When the virtual function address translation table is implemented using a hardware lookup table based on direct VFID addressing, the VFID is directly input to the addressing port of the lookup table as a hardware address or index signal. The hardware circuit can read the corresponding table entry within one or a few clock cycles. The address context information stored in this table entry constitutes the address translation context of the VF, describing the complete address translation semantics of the VF, including the address mapping method, the base address of the address mapping table, the address space size, access permissions, and control attributes. In this way, the terminal device can directly load the address translation context of the target VF without performing complex software lookups or multi-level judgments when performing address translation.

[0055] In another implementation, when the VFID encoding method is more flexible or needs to support dynamic allocation and reclamation, the Virtual Function Address Translation Table (VFID) can be implemented using a CAM or CAM-like hardware structure. In this case, each entry explicitly stores the VFID and its corresponding address translation context. The hardware uses parallel comparison circuits to match the input VFID with the VFID field in each entry. Once a match is found, the corresponding entry is selected and its address context information is output. This implementation is particularly suitable for applications where the number of VFIDs changes frequently or where non-contiguous VFID encoding needs to be supported, while still maintaining low lookup latency.

[0056] During the operation of the terminal device, when any Virtual Function (VF) initiates a DMA operation and generates an access request containing a local virtual address, the VFID, as an inherent attribute of the request, is synchronously sent to the address translation logic. The terminal device's address translation hardware first indexes or matches the Virtual Function Address Translation Table based on the VFID, directly locating the corresponding entry, and then loads the address translation context stored in that entry at the hardware level. Subsequently, the address translation unit uses the address translation context as input parameters to perform address mapping calculations on the target VF's local virtual address, converting it into the corresponding DVA address. Because the entire process is completed by dedicated hardware circuitry, and the address translation context can be pipelined after a single lookup, it can meet the requirements of high-concurrency, low-latency DMA access.

[0057] For example, suppose the terminal device supports 64 Virtual Functions (VFs) and assigns them VFIDs 0 to 63. When a virtual function with VFID 5 initiates a DMA request, the hardware address translation logic directly inputs VFID=5 as an index into the virtual function address translation table. Within one clock cycle, it reads the 5th entry and obtains the base address and mapping method information for that VF's address mapping table. Subsequently, the device uses this context information to translate the local virtual address in the request, generating the corresponding DVA address and continuing the subsequent DMA process without any host-side involvement.

[0058] By implementing the virtual function address translation table as a hardware-level index structure based on VFID, the address translation contexts of different VFs can be accessed and loaded quickly and deterministically, significantly reducing the latency and complexity of address translation paths. Simultaneously, the address translation contexts of each VF are independent at the hardware level, facilitating strict address space isolation and access control, thus enhancing system security. Furthermore, this hardware-based context lookup and loading mechanism effectively supports concurrent DMA access scenarios across multiple VFs, avoiding performance bottlenecks introduced by software lookups or contention for shared data structures, thereby improving the overall DMA throughput of the terminal device and the system's scalability.

[0059] Further optionally, in the above embodiment of step S101, when the host side modifies the address space mapping relationship of a specific VF, the host sends a corresponding configuration update instruction to the terminal device; the terminal device responds to the received configuration update instruction, locates the corresponding entry in the Virtual Function Address Translation Table according to the VFID carried in the configuration update instruction, and updates the address context information stored in the corresponding entry according to the instruction content of the configuration update instruction; through the configuration update instruction and response operation, the consistency of the VF address mapping status between the device and the host is maintained.

[0060] In this embodiment, to implement a collaborative update mechanism when the host-side address mapping relationship changes, step S101 further introduces a dynamic address context maintenance principle that ensures consistency between the host and the device. Although the address translation and context identification logic is executed internally by the terminal device, the address space ownership and mapping strategy of each VF are still uniformly managed and adjudicated by the host. Therefore, when the host modifies the address space mapping relationship of a specific VF, it must synchronize the latest address context to the terminal device through an explicit configuration update interaction mechanism to ensure that the device-side address translation behavior is always consistent with the host-side address view, thereby avoiding DMA access mismatch or security risks, and enabling the host to centrally allocate address context and the device to autonomously perform address translation.

[0061] In the specific implementation, when the host needs to modify the address mapping relationship of a specific VF due to reasons such as process address space adjustment, memory remapping, permission changes, or VF lifecycle changes, the host generates and sends a configuration update instruction to the terminal device. This configuration update instruction carries at least the VFID corresponding to the target VF and updated address context information, such as the new address mapping method, the updated address mapping table base address, address range, or access permission attributes. Upon receiving the configuration update instruction, the terminal device first parses the instruction and extracts the VFID from it. Then, it uses the VFID as an index to input it into the virtual function address translation table maintained internally by the device.

[0062] Based on the VFID, the terminal device directly locates the target entry in the Virtual Function Address Translation (VF) that corresponds one-to-one with the VF, and updates the address context information stored in that entry under the coordination of hardware or firmware control logic. The update process can be an overwrite of the original address context field, or a context switch can be performed while ensuring atomicity, to ensure that the update process does not affect the DMA operations of other VFs currently in progress. After the update is completed, the address mapping table pointed to by the entry or its description reflects the latest address mapping state on the host side, thus enabling the terminal device to automatically adopt the updated address context when performing address translation for that VF subsequently.

[0063] For example, suppose the host reallocates a new process virtual address space for the virtual function with VFID 7 and generates a new address mapping table accordingly. After completing this configuration, the host sends a configuration update command to the terminal device containing VFID=7 and the new mapping table base address. Upon receiving this command, the terminal device immediately locates the entry corresponding to VFID=7 in the Virtual Function Address Translation Table and updates the stored mapping table base address to the new value. Thereafter, all DMA requests initiated by VFID=7 will complete the translation from local virtual address to DVA based on the new address mapping relationship, without requiring a device restart or reinitialization of other VFs.

[0064] In this way, through an explicit host-device synchronization mechanism, the virtual function address translation table maintained internally by the terminal device can reflect the host's adjustments to the address mapping status of each VF in real time, ensuring the consistency and correctness of address translation semantics across the entire system. Simultaneously, this mechanism updates only specific VF entries that have changed, without affecting the normal operation of other VFs, which is beneficial for achieving fine-grained, low-overhead dynamic address context management in multi-VF concurrent operation environments. Therefore, while maintaining the high performance and low latency of device-side address translation, it also considers the flexibility and controllability of host-side address space management, further enhancing its practicality and reliability in complex virtualized DMA scenarios.

[0065] Step S102: Extract the Virtual Function ID (VFID) corresponding to the target VF from the DMA request, and query the Virtual Function Address Translation Table in the terminal device according to the VFID to obtain the address mapping table exclusive to the target VF.

[0066] In this embodiment, each entry in the Virtual Function Address Translation (VF) corresponds one-to-one with each Virtual Function (VF), and each entry points to the VF's dedicated address mapping table. A VF is set up inside the terminal device as a first-level directory for managing the address spaces of each VF on the device side. This table uses the VFID as an index, with each entry corresponding one-to-one with a VF, preventing overlap or reuse, thus achieving VF-level granular isolation structurally. Each entry does not directly store specific address mapping entries, but rather points to relevant information in the corresponding VF's dedicated address mapping table, such as the table's base address, size, validity flag, and permission flag in the device's internal storage unit, for subsequent access. When the device receives a DMA request initiated by a VF, it first queries the VFID carried in the request in the VF's VF address translation table to quickly locate the address mapping context entry corresponding to that VF, and then enters the VF's dedicated address mapping table for finer-grained address translation. Through this structure of VFID to Virtual Function Address Translation Table to VF-specific Address Mapping Table, the embodiments of this application achieve unified management and strict isolation of multiple VFs on the device side, which is beneficial for supporting SR. DMA access control in scenarios such as IOV, multiple virtual machines, and multi-tenancy.

[0067] In this embodiment of the application, the VF-specific address mapping table is used to define the translation relationship between the local virtual address of the corresponding VF and the device virtual address (DVA).

[0068] For each Virtual Function (VF), a dedicated address mapping table is configured within the terminal device. This table serves only that VF and is uniquely pointed to by the corresponding entry in the aforementioned Virtual Function Address Translation (VFA) table. In this embodiment, the dedicated mapping table records the mapping relationship between the local virtual addresses seen by the VF (e.g., the address identifier used by the process, virtual machine, or container hosted by the VF when initiating DMA) and the Device Virtual Address (DVA) uniformly used within the terminal device. The entries are typically granular at address ranges or pages and include at least: the local virtual address range, the corresponding DVA range, and optional access attributes (such as read / write permissions, caching policies, whether DMA is allowed, etc.), thus fully describing which addresses the VF can access on the device side and how they are mapped. When the device finds the dedicated mapping table for the target VF according to the VFA address translation table, it uses the local virtual address carried in the DMA request as an index to look up the corresponding DVA in the mapping table and initiates the actual DMA read / write based on the DVA-driven internal storage or bus interface. The VF-specific address mapping table can also be associated with information from different processes or contexts. Under the same VF, different processes can correspond to different local virtual address ranges and mapping entries, but these entries are always limited to the dedicated mapping table of that VF, which further ensures the address space isolation and access security in a multi-process, multi-VF environment.

[0069] In step S102, when a Virtual Function (VF) of the terminal device initiates a Direct Memory Access (DMA) request, the device's hardware logic first parses the request to determine the source of the request. Specifically, the terminal device extracts the unique identifier of the target VF, namely the Virtual Function ID (VFID), from the metadata or header information of the DMA request. This VFID is a unique index configured by the host and assigned to each VF during the system initialization phase, used to distinguish different business processes or virtual machine contexts.

[0070] Subsequently, the terminal device uses the extracted VFID as an index key to perform a lookup operation in the Virtual Function Address Mapping Table (VFMapping Table) stored internally. This VFMapping Table is a key data structure residing within the terminal device, as proposed in this application, which maintains the context index relationship of all active VFs. In the specific hardware implementation, each entry in this table corresponds one-to-one with a specific VFID. Each entry not only contains access control fields to ensure access security, but more importantly, it stores a base address pointer to the VF's dedicated address mapping table and mapping mode control information (such as indicating whether page table mode or direct mapping mode is used).

[0071] By consulting the aforementioned translation table, the device can accurately locate and obtain the address mapping table specific to the current target Virtual Function (VF). This dedicated address mapping table is a core component for achieving address space isolation, specifically defining the translation logic between the local virtual address (VF Virtual Address) within that particular VF and the device unified virtual address (DVA). For example, when VF1 and VF2 initiate access requests respectively, the device uses their respective VFIDs to point to two completely independent dedicated mapping tables in the global translation table, thereby ensuring that the address spaces of different processes or virtual machines are physically isolated on the device side, without interference. This step not only completes the crucial transition from identity recognition to context positioning but also lays the foundation for subsequently converting the VF local address to the device virtual address (DVA) and generating standard TLP packets without relying on the PCIePASID field, thus effectively reducing the burden on the host IOMMU and lowering the bandwidth overhead of TLP transmission.

[0072] Step S103: Through the address mapping table specific to the target VF, the local virtual address of the target VF is converted into the corresponding device virtual address (DVA).

[0073] As an optional embodiment, in step S103, the address mapping method configured in the address mapping table specific to the target VF is obtained. The address mapping method is either page table mapping or direct mapping. If the address mapping method is direct mapping, the local virtual address of the target VF is directly converted into the corresponding DVA based on a preset address offset rule or fixed mapping relationship. The fixed mapping relationship is used to clarify the one-to-one correspondence between the local virtual address and the DVA. If the address mapping method is page table mapping, the local virtual address of the target VF is split into a page index and an intra-page offset. The page table entry in the address mapping table specific to the target VF is queried based on the page index to obtain the corresponding DVA page base address. The DVA page base address and the intra-page offset are concatenated to obtain the target DVA.

[0074] Step S103 is the core step in realizing autonomous address translation on the device side in this embodiment of the application. After locating the address mapping table specific to the target VF, the address translation unit (ATU) inside the terminal device immediately starts resolving the local virtual address of the VF carried in the DMA request.

[0075] This conversion process can be implemented using a pre-configured address mapping method field in the VF's dedicated address mapping table. This field explicitly indicates whether page table mapping or direct mapping should be used. If the mapping method is configured as direct mapping, the ATU will directly convert the target VF's local virtual address into the corresponding DVA based on preset address offset rules or fixed mapping relationships. This mode is suitable for simple scenarios with contiguous address spaces and clear mapping relationships. By explicitly associating local addresses with DVAs, it achieves extremely fast address conversion, thereby optimizing the processing path for high-frequency, small-packet DMA requests. If the mapping method is configured as the more flexible page table mapping, the ATU will follow a standard hierarchical lookup algorithm. First, the target VF's local virtual address is split into a high-order page index and a low-order page offset. Then, the ATU uses this page index, combined with the mapping table base address in the dedicated address mapping table, to query the page table entry and obtain the corresponding DVA page base address. Finally, the DVA page base address and the page offset are logically concatenated to obtain the final Device Virtual Address (DVA) of the target DMA request. By completing this autonomous translation from VF address to DVA, address isolation and context management between multiple processes or multiple virtual functions (VFs) are achieved within the terminal device. This is a key prerequisite for generating simplified TLPs that do not require the addition of a PASID prefix, which in turn helps to further save PCIe TLP bandwidth, reduce the pressure on the host IOMMU, and improve system throughput.

[0076] Optionally, before step S103, the access permissions of the DMA request can be verified based on the permission control field; if the permission verification fails, the DMA operation is terminated. Before executing step S103, the terminal device can also perform device-side verification of the access permissions of the current DMA request based on the permission control field contained in the aforementioned VF dedicated address mapping table, thereby completing the filtering of access legitimacy before address translation.

[0077] Specifically, when the terminal device receives a DMA request from the host side, it first parses the Virtual Function Number (VFID) corresponding to the target VF from the request message according to step S102, and then queries the Virtual Function Address Translation Table based on the VFID to obtain the VF-specific address mapping table corresponding to the VF. In this embodiment, each entry in the VF-specific address mapping table, in addition to recording the mapping relationship between the local virtual address and the device virtual address (DVA), also includes an access control field to describe the access permissions of the address range within the VF and its internal context. For example, it indicates whether the allowed access direction is read or write, a combination of read and write permissions, the accessible context type or process identifier range, whether cross-process shared access is allowed, and whether the range is allowed as a DMA target. After obtaining the dedicated address mapping table for the corresponding Virtual Function (VF), the terminal device can locate the entry for the target address range in the mapping table based on the local virtual address, access direction, and optional context identifier carried in the current DMA request. It then reads the permission control field in that entry and compares the permission configuration with the access attributes of the DMA request. If any of the following conditions are not met, such as the requested access direction exceeding the pre-configured permissions, the requested context identifier being outside the allowed range, or the local virtual address being outside the legal address range of the VF, the permission verification is deemed to have failed, the corresponding DMA operation is terminated, and an abnormal status is optionally reported to the host. If all comparison conditions are met, the permission verification is considered successful. Subsequently, step S103 and subsequent processing flows continue, converting the local virtual address to a device virtual address (DVA) based on the mapping relationship recorded in the VF dedicated address mapping table. The access control unit inside the device then drives the actual DMA read / write operation based on this DVA.

[0078] For example, in the dedicated address mapping table of a virtual function (VF1), an entry corresponding to local virtual address range A is configured in the permission control field to allow only read access. When a process on the host side initiates a DMA write request for range A through VF1, the terminal device, after completing VFID resolution and obtaining the dedicated address mapping table, will look up the entry covering range A in the table, read the read-only permission control information from it, compare it with the write access attribute of the current DMA request, and if it finds that the permission constraint is not met, it will determine that the request is an illegal access, terminate the DMA operation, and thus prevent unauthorized modification of the device resources corresponding to range A. In another scenario, the permission control field of a mapping table entry can restrict access to only processes with a specific context identifier through the corresponding VF. If the context identifier of the current DMA request is inconsistent with the configuration of this field, it will also be rejected during the permission verification stage and will not proceed to the subsequent address translation and data transmission stages. By introducing access permission verification based on permission control fields before step S103, this embodiment forms a hardware-level security protection mechanism on the device side that is tightly integrated with VF granularity and process context granularity. This effectively blocks unauthorized DMA access and cross-process / cross-tenant unauthorized memory access in scenarios where multiple processes and virtual functions concurrently share the same terminal device, preventing damage to internal device resources and host memory caused by misconfigurations or malicious requests. Simultaneously, since permission verification is completed locally on the device side, it does not rely on frequent intervention from host-side software and does not introduce significant software processing overhead for legitimate requests. This ensures both security and high DMA access efficiency, achieving a balance between security and performance, and improving availability and reliability in actual deployments.

[0079] Step S104: Generate a standard PCIe transaction layer data packet (TLP) based on the DVA obtained from the conversion.

[0080] In this embodiment, the TLP includes a data payload and an address field carrying the DVA. The TLP structure includes a header and a data payload. The TLP does not require additional extended fields for process context identification, reducing the bandwidth overhead of PCIe bus transmission.

[0081] Specifically, the device-side control logic first obtains the Data Transaction Object (DVA) corresponding to the current DMA request from the preceding steps. Then, it determines the transaction type and TLP header format according to the PCIe protocol specification. For example, when performing a memory write operation, it selects the standard memory write type TLP header format and writes the aforementioned DVA into the address field of the header, ensuring that the address field fully carries the DVA for addressing by the host or peer device. Simultaneously, the device reads the data content corresponding to the DMA request from its local cache or collection module and encapsulates this data content into the data payload portion of the TLP. Subsequently, the header and data payload are encoded and concatenated according to the PCIe protocol to form a standard PCIe TLP containing both a header and data payload, which is then sent to the PCIe bus via the physical layer. In this embodiment, since the terminal device has completed the context differentiation and address space isolation of multiple processes and multiple virtual functions locally through the aforementioned VF dedicated address mapping table and device-side context identification mechanism, the DVA itself can uniquely identify the target address space and resources. Therefore, in the process of constructing TLP, there is no need to add an additional extended field for process address space identification to TLP. For example, there is no need to add the process address space identifier PASID extended field and the prefix information related to PASID, thereby maintaining the TLP structure compatible with the existing standard PCIe controller and reducing the bandwidth overhead of PCIe bus transmission.

[0082] As an optional embodiment, in step S104, the converted DVA is encapsulated into the address field of the TLP header, so that the address field carries the DVA for host-side addressing; the data content corresponding to the DMA request is encapsulated into the data payload of the TLP; the header and data payload of the TLP are concatenated according to the PCIe protocol specification to form the standard PCIe TLP, wherein the TLP does not have the process address space identifier PASID extension field and PASID-related prefix information attached.

[0083] For example, a process on the host side initiates a DMA write operation through a Virtual Function (VF) bound to it, requesting to write a buffer of data into the internal storage resources of the terminal device. In the method of this application, the local virtual address where the buffer is located is first mapped to a DVA value on the device side, assuming it is a continuous range of device virtual addresses. In step S104, the terminal device generates a TLP of the memory write type based on this value, fills the starting address of the DVA into the address field of the TLP header, directly uses the data sequence in the buffer as the data payload of the TLP, and concatenates and encodes it according to the PCIe protocol requirements before sending it to the bus. Throughout the process, the TLP only carries the standard header fields and the data payload, without carrying any extended fields of process identification, and there is no need to propagate process context information on the PCIe link. Through this design where the context identification and address translation are completed in advance on the device side, and the link side only transmits the standard TLP identified by the DVA address, this embodiment of the application avoids the problems of packet header bloat and reduced effective payload ratio caused by extending the PASID field in the TLP, reduces the bus bandwidth occupied by a unit of effective data, and improves the transmission efficiency of the PCIe link. On the other hand, it fully leverages the extensive support of the existing PCIe protocol for the standard TLP, enabling terminal devices to achieve fine-grained control and security isolation of multi-process, multi-virtual-function DMA access without modifying the host-side PCIe controller and protocol stack. This approach offers advantages such as ease of engineering implementation and minimal invasiveness to existing systems. Furthermore, since it no longer relies on the host side resolving process identifiers in the TLP for context differentiation, but instead uses the DVA and the device's internal address mapping structure for addressing and access control, it also reduces the burden on the host-side IOMMU and related software for multi-context management, thereby improving overall system performance and reliability.

[0084] Step S105: The TLP is sent to the host so that the host-side Input / Output Memory Management Unit (IOMMU) or Address Translation Service (ATS) can convert the DVA into a host physical address (HPA) to complete the DMA operation.

[0085] As an optional embodiment, after generating the standard PCIe Transaction Layer Packet (TLP) carrying the Virtual Device Address (DVA) and data payload in step S104, in step S105, the terminal device sends the TLP to the host side via the PCIe bus. The host-side Input / Output Memory Management Unit (IOMMU) or Address Translation Service (ATS) performs secondary address translation on the DVA in the TLP header, mapping it to the host physical address (HPA), and completes the final DMA read / write operation accordingly. Specifically, after constructing the TLP header and data payload, the transmission control module inside the terminal device encodes the TLP according to the link layer and physical layer protocols and sends it to the host. When the host receives the TLP, it submits the request to the IOMMU or the ATS unit working with the device for processing according to the configured PCIe routing rules and device identifier. In this embodiment, the host side pre-configures a mapping relationship from DVA to HPA for the terminal device. This mapping can be divided and managed by device, by VF, or even by security domain or address space dimension. When the IOMMU or ATS parses the DVA carried in the TLP header, it uses the locally maintained mapping table structure to find the corresponding HPA, and then initiates a real physical memory access to the host memory controller based on the HPA, thereby writing the data payload from the terminal device to the host physical memory, or reading data from the host physical memory and returning it to the terminal device through PCIe, thus completing a complete DMA transaction.

[0086] For example, in a DMA write scenario, the terminal device, based on the aforementioned steps, has already converted the local virtual address corresponding to a process buffer into a device virtual address (DVA1), filled the address field in the TLP header with DVA1, filled the buffer data into the TLP's data payload, and sent it to the host. Upon receiving the TLP, the host-side IOMMU uses the address translation context corresponding to the current device or VF to look up the host physical address (HPA1) corresponding to DVA1 in its internal mapping table. It then initiates a write operation to the memory subsystem with HPA1 as the destination address, storing the TLP's data payload in the specified location in physical memory. For DMA read operations, the process is similar, except that the IOMMU or ATS locates the HPA based on the DVA, reads data from the host memory according to the HPA, and encapsulates it into a PCIe TLP returned to the terminal device. In this embodiment, since the DVA has already undergone normalization processing at the device level in conjunction with the VF and process context, the host-side IOMMU or ATS can perform efficient address translation solely based on the DVA without being aware of the specific process context, thus maintaining the simplicity and universality of the host-side address translation logic.

[0087] By employing a hierarchical address mapping mechanism in step S105—where the terminal device sends a standard TLP carrying the DVA and the host-side IOMMU or ATS completes the DVA-to-HPA translation—this embodiment of the application achieves a reasonable division of labor in address management between the device and host sides while ensuring compatibility with existing PCIe and IOMMU architectures. On one hand, the device side is responsible for identifying VFs and process contexts and generating DVAs, ensuring isolation and fine-grained control of multi-process and multi-virtual function access. On the other hand, the host side uses existing IOMMU or ATS hardware to complete the final physical addressing from DVA to HPA, avoiding significant modifications to the host physical address management system. This embodiment can achieve secure DMA access across devices and virtual functions without introducing additional PASID fields and complex extended protocols. It optimizes the DMA path in three stages: context identification, address translation, and bus transmission. While improving overall system security and resource isolation capabilities, it reduces the implementation complexity and bandwidth overhead on the host and bus sides, offering advantages such as ease of engineering deployment, good scalability, and low performance loss.

[0088] In one embodiment, the terminal device is a PCIe terminal device, which can be any one of a graphics processing unit (GPU), a smart network interface card, a hardware accelerator, a data processing unit (DPU), or an artificial intelligence (AI) chip. The host assigns a unique Virtual Function ID (VFID) to each Virtual Function (VF). The VFID can be a non-repeating integer or character identifier, with its length matching the maximum number of VFs supported by the terminal device, ensuring that each VF is uniquely identifiable within the device and that there are no identifier conflicts. The allocation of VFIDs can be configured by the host according to the creation order of the VFs, the priority of the corresponding process, or a preset encoding rule, thereby forming a VF identification system on the device side consistent with the virtualization management on the host side. In this embodiment, the local virtual address of the target VF is the address allocated to the user process or virtual machine corresponding to that VF in its own independent virtual address space. The local virtual address spaces of different VFs do not overlap, thus achieving physical isolation across VFs in the address space partitioning dimension, providing an independent address context basis for subsequent multi-process DMA access based on device-side context identification.

[0089] In another embodiment, for each Virtual Function (VF), the host constructs a corresponding VF-specific address mapping table and stores these address mapping tables in the local storage unit of the terminal device. This local storage unit can be the terminal device's on-chip memory, dedicated cache, or local flash memory. The storage areas of each address mapping table are physically isolated to avoid mutual interference between different VFs through hardware storage resources. Address mapping methods can include page table mapping or direct mapping. In page table mapping, multi-level or single-level page tables are used to achieve page-granular mapping from local virtual addresses to device virtual addresses (DVA). In direct mapping, address ranges plus offsets are used to quickly convert consecutive address segments. The Virtual Function Address Translation Table (VFC) serves as a first-level index table on the device side. Each entry stores not only the base address or handle of the corresponding VF-specific address mapping table but also the address mapping method used by the VF. This mapping method can be a pre-configured fixed mapping method or dynamically configured as an adaptive mapping method based on the access requirements of the VF's corresponding process. When the process address space corresponding to a Virtual Function (VF) expands, shrinks, or its address range changes, the host updates the dedicated address mapping table for that VF and simultaneously updates the address context information, the base address of the mapping table, and the association with the dedicated address mapping table for the corresponding entry in the Virtual Function Address Translation (DVA) table. When a new VF is added or an existing VF is deregistered, the host adds or deletes the corresponding entry in the DVA table. To further reduce address lookup latency, in this embodiment, the DVA table is preferably stored in the on-chip high-speed memory unit or dedicated hardware register of the terminal device to shorten the entry lookup path and improve the overall efficiency of local virtual address to DVA translation.

[0090] In another embodiment, each entry in the VF-specific address mapping table, in addition to recording the mapping information from the local virtual address to the DVA, also has an access control field. This field includes at least one or more of the following: readable access identifier, writable access identifier, and executable access identifier. After receiving a DMA request initiated by a VF and completing VFID resolution, the terminal device locates the entry for the target address range in the corresponding VF's dedicated address mapping table, reads the access control field therein, and compares it with the access type of the current DMA request. This restricts the access range of the DMA request initiated by the VF to the host's physical address space and the types of operations such as read, write, and execute. If the access type, target address, or context attributes of the DMA request exceed the authorized range described by the access control field, the terminal device can directly reject the DMA request to avoid unauthorized access. Only when the access control field matches the access attributes of the DMA request is the local virtual address to DVA translation allowed to continue and subsequent data transmission driven. Through this mechanism of fine-grained access control at the device level, combining VF and process context, the security and isolation of multi-process, multi-virtual-function shared terminal devices can be significantly improved at the hardware level.

[0091] In another embodiment, after the terminal device completes the local virtual address to DVA translation, it generates a standard PCIe Transaction Layer Data Packet (TLP) based on the translated DVA and communicates with the host via the PCIe bus. This standard PCIe TLP consists only of a header and a data payload, excluding the optional TLP Digest field. Its header includes a dedicated address field to carry the translated device virtual address (DVA). In this embodiment, the TLP does not include the process address space ID (PASID) extension field, nor does it require additional PASID-related prefix information, thus maintaining a concise TLP header and compatibility with existing PCIe controllers. When generating the TLP, the terminal device encapsulates the DVA into the address field of the TLP header for host-side addressing. Simultaneously, it encapsulates the data content corresponding to the DMA request into the TLP's data payload, splices the header and data payload according to the PCIe protocol specification to form a complete TLP, and sends it to the host via the PCIe link. The host can use at least one of the following mechanisms to translate the DVA carried in the TLP address field into the host physical address HPA: Address Translation Service (ATS), Input / Output Memory Management Unit (IOMMU), or static mapping. When using static mapping, the host pre-stores a fixed mapping table between DVA and HPA. Upon receiving a TLP, it directly queries this table to complete the DVA-to-HPA address translation, without needing to additionally parse process context information. When using ATS or IOMMU, the hardware-maintained translation cache or page table structure completes the DVA-to-HPA mapping, also without relying on the PASID field. This ensures address translation flexibility while avoiding dependence on PCIe protocol extension fields, simplifying the link protocol and host-side implementation complexity.

[0092] In another embodiment, for high-frequency, small-granularity data access scenarios, the multi-process DMA access method based on device-side context recognition in this application can effectively improve the actual transmission efficiency of the PCIe bus. The terminal device communicates with the host via the PCIe bus, and the transmitted TLP is used to carry small-granularity data in the range of 64B to 256B. When a large number of such high-frequency small-packet DMA requests exist in parallel, the device avoids the additional transmission overhead caused by redundant extended fields through the aforementioned simplified TLP structure and the mechanism of locally completing context recognition. This allows more payload data to be carried within a unit bandwidth, thereby meeting the performance requirements of high-frequency small-packet DMA access. Simultaneously, when multiple VFs initiate DMA requests at the same time, the address translation module in the terminal device can perform parallel queries on the Virtual Function Address Translation Table and their respective VF-specific address mapping tables, independently completing the translation of each VF's local virtual address to DVA, and generating corresponding TLPs to send to the host side, realizing true concurrent DMA access across multiple processes and multiple VFs. During the parallel access process described above, since the virtual function address translation table and the dedicated address mapping table of each VF are physically isolated from each other and the access path is clear, combined with the unique design of VFID, resource contention and access overlap between different VFs during address translation and DMA can be avoided, further improving the overall throughput and access stability of the system.

[0093] This application embodiment greatly simplifies the TLP structure and reduces the IOMMU load by moving the core logic of multi-process address translation from the host side to the terminal device side. At the same time, it provides better infrastructure support for the development of high-performance computing systems by improving device autonomy, fundamentally overcoming the limitations of the traditional PASID mechanism.

[0094] After introducing the method of the exemplary embodiments of this application, the following describes a multi-process DMA access device based on device-side context identification according to an exemplary embodiment of this application. This device is applied to a computing system supporting hardware virtualization, the computing system including a host and terminal devices. The terminal devices are virtualized into multiple virtual function (VF) operations, each VF serving a user process or virtual machine. The device includes: a request unit, configured to generate a DMA request containing the target VF's local virtual address when any target VF of the terminal device initiates a direct memory access (DMA) operation; and a lookup unit, configured to extract the virtual function ID (VFID) corresponding to the target VF from the DMA request, query the virtual function address translation table within the terminal device based on the VFID, and obtain the target VF's dedicated address mapping table. Each entry in the virtual function address translation table corresponds one-to-one with each VF, and each entry points to the corresponding VF's dedicated address mapping table. The VF's dedicated address mapping table is used to define the corresponding... The device implements the following steps: a local virtual address (VF) to device virtual address (DVA) translation relationship; a translation unit, used to translate the target VF's local virtual address into the corresponding device virtual address (DVA) using a target VF-specific address mapping table; an access unit, used to generate a standard PCIe transaction layer data packet (TLP) based on the translated DVA, the TLP including a data payload and an address field carrying the DVA; and sending the TLP to the host so that the host-side input / output memory management unit (IOMMU) or address translation service (ATS) can translate the DVA into a host physical address (HPA) to complete the DMA operation. The above apparatus can implement the steps described in the above method embodiments, and the specific implementation methods of each step will not be repeated here.

[0095] After introducing the methods and apparatus of the exemplary embodiments of this application, a terminal device of the exemplary embodiments of this application will be described next. The terminal device can implement the steps described in the above method embodiments, and the specific implementation of each step will not be repeated here.

[0096] After introducing the methods, apparatus, and terminal devices of exemplary embodiments of this application, the computer-readable storage medium of exemplary embodiments of this application will now be described. The computer-readable storage medium is an optical disc, on which a computer program (i.e., a program product) is stored. When the computer program is run by a processor, it implements the steps described in the above method embodiments. The specific implementation methods of each step will not be repeated here. It should be noted that the above embodiments are merely specific embodiments of this application, used to illustrate the technical solutions of this application, and not to limit it. The protection scope of this application is not limited thereto. Although this application has been described in detail with reference to the foregoing embodiments, those skilled in the art should understand that any person skilled in the art can still modify or easily conceive of changes to the technical solutions described in the foregoing embodiments within the scope of the technology disclosed in this application, or make equivalent substitutions for some of the technical features. Therefore, the protection scope of this application should be determined by the scope of the claims.

Claims

1. A multi-process DMA access method based on device-side context recognition, characterized in that, The method is applied to a computing system that supports hardware virtualization. The computing system includes a host and terminal devices. The terminal devices are virtualized into multiple Virtual Functions (VFs), each VF serving a user process or virtual machine. The method includes: When any target VF of the terminal device initiates a direct memory access (DMA) operation, the target VF generates a DMA request containing the target VF's local virtual address; Extract the Virtual Function Number (VFID) corresponding to the target VF from the DMA request, query the Virtual Function Address Translation Table in the terminal device according to the VFID, and obtain the address mapping table dedicated to the target VF. Each entry in the Virtual Function Address Translation Table corresponds one-to-one with each VF, and each entry points to the address mapping table dedicated to the corresponding VF. The address mapping table dedicated to the VF is used to define the translation relationship from the local virtual address of the corresponding VF to the device virtual address (DVA). The target VF's local virtual address is translated into the corresponding DVA through the target VF's dedicated address mapping table; Based on the converted DVA, a standard PCIe transaction layer data packet TLP is generated, which includes a data payload and an address field carrying the DVA; The TLP is sent to the host so that the host-side Input / Output Memory Management Unit (IOMMU) or Address Translation Service (ATS) can translate the DVA into a host physical address (HPA) to complete the DMA operation.

2. The multi-process DMA access method based on device-side context recognition according to claim 1, characterized in that, When any target VF of the terminal device initiates a direct memory access (DMA) operation, before the target VF generates a DMA request containing the target VF's local virtual address, the following steps are also included: During the host initialization phase, a unique VFID is assigned to each VF of the terminal device; For each VF's process address space, generate a unique address mapping table for each VF; The virtual function address translation table is set up inside the terminal device, and the address mapping tables of all VFs are stored in the virtual function address translation table using VFID as the index, and the virtual function address translation table is dynamically maintained. In this table, each entry in the virtual function address translation table points to the address mapping table specific to the corresponding VF, and each entry stores at least the address context information of the corresponding VF. The address context information includes at least the address mapping method of the corresponding VF, the base address of the mapping table, and the access control field.

3. The multi-process DMA access method based on device-side context recognition according to claim 2, characterized in that, The process address space for each VF is configured to generate a dedicated address mapping table for each VF, including: Obtain the virtual address space layout allocated by the host for the corresponding process; Based on the virtual address space layout, an independent address mapping structure is constructed for each VF within the terminal device; The address mapping structure is configured to map the process virtual address space of each VF to a global and contiguous DVA space.

4. The multi-process DMA access method based on device-side context recognition according to claim 2, characterized in that, The step of setting up the Virtual Function Address Translation Table (VFID) within the terminal device, using VFID as an index, storing the address mapping tables of all VFs in the VFID, and dynamically maintaining the VFID includes: The virtual function address translation table is configured as a hardware lookup table based on VFID direct addressing, an index structure based on content addressable memory (CAM) or a hardware lookup table. Each table entry stores address context information that constitutes the address translation context of the corresponding VF. When performing address translation, the terminal device directly indexes the corresponding table entry based on the VFID through hardware circuitry and loads the address translation context to complete the translation of the VF's local virtual address to the DVA.

5. The multi-process DMA access method based on device-side context recognition according to claim 2, characterized in that, Before the step of translating the target VF's local virtual address into the corresponding DVA using the target VF's dedicated address mapping table, the following steps are also included: Based on the permission control field, the access permissions of the DMA request are verified; If the permission verification fails, the DMA operation will be terminated.

6. The multi-process DMA access method based on device-side context recognition according to claim 1, characterized in that, The step of converting the target VF's local virtual address to the corresponding DVA through the target VF's dedicated address mapping table includes: Obtain the address mapping method configured in the address mapping table specific to the target VF, wherein the address mapping method is page table mapping or direct mapping; If the address mapping method is direct mapping, the local virtual address of the target VF is directly converted into the corresponding DVA based on the preset address offset rules or fixed mapping relationship. The fixed mapping relationship is used to clarify the one-to-one correspondence between the local virtual address and the DVA. If the address mapping method is page table mapping, the local virtual address of the target VF is split into a page index and an intra-page offset; based on the page index, the page table entry in the address mapping table dedicated to the target VF is queried to obtain the corresponding DVA page base address; the DVA page base address is concatenated with the intra-page offset to obtain the target DVA.

7. The multi-process DMA access method based on device-side context recognition according to claim 1, characterized in that, The generation of TLP based on the transformed DVA includes: The converted DVA is encapsulated into the address field of the TLP header, so that the address field carries the DVA for host-side addressing; The data content corresponding to the DMA request is encapsulated into a TLP data payload; The TLP header and data payload are assembled according to the PCIe protocol specification to form the standard PCIe TLP. The TLP does not include the process address space identifier PASID extension field or PASID-related prefix information.

8. A multi-process DMA access device based on device-side context recognition, characterized in that, The device is applied to a computing system that supports hardware virtualization. The computing system includes a host and terminal devices. The terminal devices are virtualized into multiple Virtual Functions (VFs), each VF serving a user process or virtual machine. The device includes the following units: The request unit is used to generate a DMA request containing the local virtual address of the target VF when any target VF of the terminal device initiates a direct memory access DMA operation. The lookup unit is used to extract the Virtual Function Number (VFID) corresponding to the target VF from the DMA request, query the Virtual Function Address Translation Table in the terminal device according to the VFID, and obtain the address mapping table dedicated to the target VF. Each entry in the Virtual Function Address Translation Table corresponds one-to-one with each VF, and each entry points to the address mapping table dedicated to the corresponding VF. The address mapping table dedicated to the VF is used to define the translation relationship from the local virtual address to the device virtual address (DVA) of the corresponding VF. The translation unit is used to translate the local virtual address of the target VF into the corresponding device virtual address (DVA) through the target VF's dedicated address mapping table; The access unit is used to generate a standard PCIe transaction layer data packet (TLP) based on the converted DVA. The TLP includes a data payload and an address field carrying the DVA. The TLP is then sent to the host so that the host-side input / output memory management unit (IOMMU) or address translation service (ATS) can convert the DVA into a host physical address (HPA) to complete the DMA operation.

9. An electronic device, characterized in that, include: Memory, used to store computer software programs; A processor is configured to read and execute the computer software program to implement the multi-process DMA access method based on device-side context identification as described in any one of claims 1-7.

10. A chip, characterized in that, The chip stores a computer software program, which, when executed, implements the multi-process DMA access method based on device-side context recognition as described in any one of claims 1-7.

Images