A Zero-Copy Acceleration Method for Virtual Machine Network I / O Based on Pass-Through Drivers of Domestic Operating Systems

Abstract

This invention relates to a zero-copy acceleration method for virtual machine network I / O based on a passthrough driver of a domestic operating system. The method includes: customizing the kernel of the domestic operating system to introduce a dedicated passthrough driver module; expanding the virtual machine's virtual network device to provide a passthrough mode; receiving passthrough enable requests from virtualization components and performing security authentication and resource pre-checks; upon successful pre-check, creating a virtual machine-specific protection domain based on the IOMMU, locking memory pages used for network transmission and reception and establishing a mapping to the IOVA, recording the mapping relationship to restrict the physical network card to only access the mapped virtual machine memory; configuring the physical network card's passthrough transmission and reception queue and establishing a control channel, sending configuration information to initialize the descriptor ring; and executing a zero-copy transmission and reception process, enabling the physical network card's DMA to directly access the virtual machine's network buffer to complete data transmission. This method reduces host-side data copying and protocol stack processing overhead, lowers latency, and improves throughput.

Description

Technical Field

[0001] This invention relates to the field of virtualization technology, and in particular to a zero-copy acceleration method for virtual machine network I / O based on a pass-through driver of a domestic operating system. Background Technology

[0002] In the field of virtualization technology, the network I / O performance of virtual machines (VMs) directly affects the overall operating efficiency of virtualization systems, especially in high-speed network scenarios (such as 10GbE and above), where the need for performance optimization is particularly urgent.

[0003] The closest existing technology to this invention is a virtual machine network I / O processing scheme based on the host kernel protocol stack, commonly found in virtualization platforms such as KVM (Kernel-based Virtual Machine) or Xen. The specific processing flow of this scheme is as follows: 1. Applications within the virtual machine generate network data, which is then sent to virtual network devices (such as virtio-net devices) via the virtual machine's kernel protocol stack. 2. Virtual devices transmit data to the host machine's user space via front-end and back-end driver mechanisms (such as virtio) and virtualization components (such as QEMU). 3. QEMU forwards the data to the host kernel protocol stack, where it undergoes complete network protocol processing (such as the TCP / IP stack) and is finally sent to the physical network via the physical network card driver.

[0004] This approach relies on the general processing of the host kernel protocol stack, ensuring compatibility and security. It is also applicable to domestic Linux-based operating systems (such as OpenEuler or AliOS). However, it has not been deeply optimized for virtualization scenarios and has the following objective drawbacks: 1. High data copy overhead: Data undergoes multiple copies during transmission. For example, from a virtual machine to a physical network card, data may pass through the virtual machine kernel buffer, the QEMU user space buffer, the host kernel protocol stack buffer, and finally the network card's DMA buffer. Each copy consumes CPU cycles and memory bandwidth, increasing latency. Mathematically, copy overhead can be modeled as the total time... Where n is the number of copies, S is the data size, and B is the memory bandwidth. For a standard 1500-byte Ethernet frame in a 10Gb / s network, multiple copies can increase latency by tens of microseconds.

[0005] 2. Kernel Protocol Stack Processing Latency: The host kernel protocol stack involves complex layered processing (such as TCP / IP checksum calculation and segmentation reassembly), which introduces unpredictable latency. Protocol stack processing time

[0006] Related to packet size and protocol complexity, this latency typically accounts for 30%-50% of the total I / O path time. In virtualized environments, this latency is amplified because the protocol stack needs to serve multiple virtual machines simultaneously, leading to resource contention.

[0007] 3. High CPU utilization: Frequent context switching (such as from virtual machine to host machine, from user space to kernel space) and interrupt handling consume significant CPU resources. In high-speed networks, the CPU can become a bottleneck, leading to decreased throughput. For example, in traditional solutions, handling 10Gb / s traffic may require multiple CPU cores, while a physical machine may only need one core.

[0008] 4. Poor scalability: As the number of virtual machines increases, the host kernel protocol stack becomes a shared resource, easily leading to lock contention and cache invalidation, limiting system expansion. Experiments show that when the number of virtual machines exceeds 10, network throughput may decrease by more than 50%.

[0009] 5. Specific issues with domestic OS: Domestic OS (such as OpenEuler) are usually based on the general Linux kernel. Their protocol stack is not optimized for virtualization and lacks a zero-copy mechanism, which leads to a more obvious performance gap in domestic environments.

[0010] 6. Security and Stability Risks: In the current solution, all virtual machine network data flows converge on the host machine's kernel protocol stack for processing. This shared and complex core software layer not only increases the attack surface (e.g., vulnerabilities in the kernel network protocol stack could affect all virtual machines) but also becomes a stability bottleneck. Any protocol stack anomaly (such as memory overflow or deadlock) or driver failure caused by any virtual machine can affect other virtual machines and even the entire host machine, lacking effective fault isolation. Furthermore, frequent data copying and context switching increase the probability of exhausting overall system resources, impacting stable operation.

[0011] While existing technologies include network acceleration solutions such as SR-IOV (Single Root I / O Virtualization) and DPDK (Data Plane Development Kit), SR-IOV requires hardware support and is complex to configure, making it unsuitable for domestic environments. DPDK bypasses the kernel but requires user-space drivers and lacks virtual machine integration, thus failing to fundamentally address the aforementioned technical shortcomings. Therefore, for domestic operating system environments, there is an urgent need for a virtual machine network I / O optimization solution that balances high performance, security, compatibility, and scalability to overcome the bottlenecks of traditional technologies. Summary of the Invention

[0012] The purpose of this invention is to overcome the problems caused by the path dependence of existing virtual machine network I / O processing on the host kernel protocol stack, such as multiple data copies, protocol stack processing latency, high CPU overhead due to frequent context switching, shared resource contention when the virtual machine scales up, and the performance gap becoming more obvious due to the lack of deep virtualization optimization in the domestic operating system environment. It also reduces the security and stability risks caused by the convergence of complex host protocol stacks. This invention provides a zero-copy acceleration method for virtual machine network I / O based on a domestic operating system pass-through driver. By customizing and optimizing the domestic OS kernel, introducing a dedicated "pass-through" driver module, and extending the virtual machine's virtual network devices through pass-through, a direct memory mapping is established between the virtual machine memory and the host physical network card DMA, bypassing the host kernel protocol stack and achieving zero-copy transmission of network data on the host side. Combined with the design of memory isolation and access control in the IOMMU protection domain, pass-through start / stop and rollback mechanisms, health checks and fault isolation recovery, and hot migration support, it improves system compatibility, maintainability, and operational stability while maintaining high performance.

[0013] To achieve the above objectives, the technical solution adopted by this invention is: a zero-copy acceleration method for virtual machine network I / O based on a domestic operating system pass-through driver, characterized by comprising: S1: Customize and modify the kernel of the domestic operating system, and introduce a dedicated pass-through driver module. The pass-through driver module is used to directly manage the mapping relationship between virtual machine memory and host physical network card DMA access, and bypass the host kernel network protocol stack processing path in the data plane. S2: Extend the virtual network device of the virtual machine and provide it with a pass-through mode, so that the virtual network device can establish a cooperative working relationship with the pass-through driver module when the pass-through mode is enabled, so that network data can be sent and received on the host side without being forwarded by the host user space; S3: Receives the pass-through mode enable request initiated by the virtualization component and performs security authentication and resource pre-check. When the pre-check passes, it creates an independent IOMMU protection domain for the target virtual machine based on the IOMMU. S4: Lock the memory pages used for network transmission and reception of the target virtual machine, and establish a mapping from the memory pages to the IOVA within the IOMMU protection domain. Record the mapping relationship in the mapping table to restrict the physical network card to only access the memory range mapped by the virtual machine. S5: Configure the pass-through send queue and pass-through receive queue of the physical network card, make its DMA target address point to the IOVA address range, and establish a control channel for transmitting data packet descriptors and performing notification synchronization between the host side and the virtual machine side; S6: Send pass-through configuration information to the virtual machine side so that the virtual machine side driver initializes the descriptor ring and makes the descriptor point to the mapped network buffer; S7: Execute zero-copy transmission process: The virtual machine side writes the address information and length information corresponding to the data to be sent into the transmission descriptor ring and sends a notification through the control channel. The host machine side pass-through driver module converts the address information into IOVA according to the mapping table and programs it into the physical network card transmission queue descriptor, so that the physical network card DMA engine can directly read data from the virtual machine memory corresponding to the IOVA and send it. S8: Execute zero-copy reception process: When the physical network card receives data, it directly writes the data to the virtual machine memory corresponding to the IOVA through DMA and generates a reception completion notification. The virtual machine side obtains the completed reception descriptor according to the reception descriptor ring and reads the corresponding data. The pass-through driver module uses a lightweight forwarding path on the data plane, performing only necessary frame encapsulation processing while skipping the layered processing flow of the host kernel TCP / IP protocol stack, thereby achieving zero-copy acceleration of virtual machine network I / O.

[0014] Furthermore, S1 includes: after the host machine starts up, loading the passthrough driver module and triggering initialization, initializing the internal data structure; the internal data structure includes at least a virtual machine mapping table vm_map_table and a physical network card queue status table; and detecting the physical network card, marking at least a portion of the physical network card's transmit and receive queues as passthrough dedicated queues, so that the passthrough dedicated queues are isolated from the data path of the host machine kernel network protocol stack.

[0015] Furthermore, it also includes an IOMMU availability check; when the IOMMU is unavailable, it is marked as traditional fallback mode and pass-through mode is disabled, causing the virtual machine to fall back to traditional virtual network mode.

[0016] Furthermore, the passthrough mode enable request is initiated through a device-specific ioctl interface and carries virtual machine identification information and memory layout information; and the method also includes dynamically enabling or disabling passthrough mode through the ioctl interface.

[0017] Furthermore, the S3 security authentication includes verification of the operation permissions of the initiating process; the resource pre-check includes at least verification of the availability of the pass-through dedicated network card queue, IOMMU domain space, and DMA-related resources; when any verification fails, an error is returned and the system reverts to the traditional virtual network mode.

[0018] Furthermore, the locking operation of S4 involves performing a pin operation on the memory page corresponding to the network buffer to prevent the memory page from being swapped out and to ensure the stability of the DMA access target; and establishing a mapping from the memory page to the IOVA within the IOMMU protection domain, recording the mapping relationship in the vm_map_table to restrict the physical network card to only access the memory range allocated to the virtual machine.

[0019] Furthermore, S5 includes: configuring interrupts for the pass-through send queue and the pass-through receive queue and establishing a binding relationship with the virtual machine's virtual CPU; and the control channel is a shared memory page or a doorbell register, the control channel is used to transmit descriptors and perform notifications and synchronization, but does not transmit actual data packet content.

[0020] Furthermore, S6 includes: the pass-through driver module encapsulates the queue index, IOVA start address, control channel address and interrupt information into a configuration block and returns it to the virtualization component, and the virtualization component writes the configuration information into the register or memory area of ​​the pass-through mode front-end driver in the virtual machine, so that the front-end driver in the virtual machine initializes the ring descriptor queue and points to the network data buffer located in the virtual machine memory.

[0021] Furthermore, S7 and S8 include: after the host-side pass-through driver module obtains the descriptor and completes the address translation according to vm_map_table, it programs the converted IOVA and its length into the physical network card queue descriptor, so as to trigger the physical network card to directly read the transmitted data from the virtual machine memory corresponding to the IOVA and write the received data into the virtual machine memory corresponding to the IOVA through DMA, and enable the virtual machine side to complete the transmission completion processing and the received data reading processing according to the descriptor ring.

[0022] Furthermore, it also includes stability and operation and maintenance scenario handling, which includes: a) Continuous health checks and anomaly handling: The passthrough driver module's monitoring thread performs health checks at preset intervals. These health checks include at least the passthrough queue error count, the validity of IOMMU mapping entries, and the liveness status of associated virtualization processes. When a network card error, IOMMU mapping anomaly, or multiple consecutive periods of unresponsiveness on the virtual machine side are detected, anomaly handling is triggered. This anomaly handling includes retrying for recoverable errors and pausing passthrough, saving the context, unmapping and releasing resources, notifying the virtualization component to fall back to the traditional path, and logging for unrecoverable errors. b) Virtual machine hot migration support: Upon receiving a migration notification, pause pass-through data paths and complete unprocessed descriptors, unmap and output device status to participate in the migration; re-execute pass-through enabling, mapping establishment and queue configuration on the target host to restore the network; and / or c) Resource release and unloading: When the virtual machine is destroyed, stop the relevant queues, clear the IOMMU mapping and release the IOVA address space, unlock memory pages, delete the vm_map_table entry and destroy the IOMMU protection domain; before unloading the passthrough driver module, if the vm_map_table is empty, release global resources and then complete the unloading.

[0023] This invention improves upon existing technical solutions in terms of performance, resource utilization, scalability, domestic compatibility, and security and stability by customizing the kernel of a domestic operating system, introducing a dedicated pass-through driver module, and constructing a direct memory mapping mechanism based on IOMMU. Compared with traditional virtual machine network I / O processing methods based on the host kernel protocol stack, it has at least the following advantages: This invention bypasses the host kernel protocol stack processing path on the data plane through a pass-through driver module and establishes a direct memory mapping between the virtual machine and the physical network card, reducing the overhead caused by multiple data copies and protocol stack layering in traditional solutions. At the same time, it adopts a lightweight forwarding path, performing only necessary frame encapsulation processing, thereby shortening the data transmission path, reducing processing latency and improving network throughput, making it suitable for performance optimization needs in high-speed network scenarios.

[0024] This invention reduces CPU cycle consumption caused by data copying through zero-copy transmission and reduces the interaction overhead between virtual machines and host machines, and between user space and kernel space by simplifying data paths. Under the same network load conditions, it helps to reduce CPU resource consumption, improve the overall resource utilization of the virtualization system, and make more CPU resources available to support virtual machines or business applications.

[0025] In traditional solutions, the host kernel protocol stack is treated as a shared resource, which can easily lead to resource contention and affect performance stability when multiple virtual machines are running concurrently. This invention addresses this by establishing an IOMMU protection domain for the virtual machine and combining it with pass-through queue resource configuration. This achieves isolation and load balancing of network data plane processing, which helps reduce the impact of shared resource contention and thus improves scalability and operational stability in multi-virtual machine scenarios.

[0026] To address the issue of optimization potential in virtualized network I / O zero-copy and high-performance data paths of domestic operating systems, this invention achieves this through the coordinated implementation of kernel-level pass-through drivers and IOMMU mapping mechanisms. This can be adapted and optimized by combining the characteristics of domestic operating system kernels and their IOMMU implementations, thereby improving the deployment feasibility and performance consistency of domestic software and hardware platforms.

[0027] This invention utilizes the IOMMU protection domain to constrain DMA access boundaries, restricting the physical network card to access only the mapped memory range allocated to the target virtual machine, thereby improving isolation and security. It also provides health checks, exception handling, and rollback mechanisms, enabling orderly pauses, resource releases, and rollbacks to traditional paths in the event of network card errors, mapping anomalies, or insufficient resources, preventing fault propagation and improving system maintainability. Furthermore, it supports hot migration and standardized resource release processes, enhancing availability in real-world virtualization operation and maintenance scenarios. Attached Figure Description

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

[0029] Figure 1 This is a flowchart of the virtual machine network I / O zero-copy acceleration method based on the direct-drive of a domestic operating system, according to the present invention. Figure 2 This is a schematic diagram of a traditional virtual machine network I / O data path based on the host kernel protocol stack; Figure 3 This is a schematic diagram of the zero-copy data path for virtual machine network I / O based on the direct-drive mechanism of a domestic operating system, as described in this invention. Detailed Implementation

[0030] Exemplary embodiments will now be described in detail, examples of which are illustrated in the accompanying drawings. When the following description relates to the drawings, unless otherwise indicated, the same numerals in different drawings denote the same or similar elements. The embodiments described in the following exemplary embodiments do not represent all embodiments consistent with the present invention. Rather, they are merely examples of apparatuses and methods consistent with some aspects of the invention as detailed in the appended claims.

[0031] Example 1 This embodiment provides a zero-copy acceleration method for virtual machine network I / O based on a domestic operating system's pass-through driver, characterized by including: S1: Customize and modify the domestic operating system kernel to introduce a dedicated passthrough driver module. The passthrough driver module is used to directly manage the mapping relationship between virtual machine memory and host physical network card DMA access, and bypass the host kernel network protocol stack processing path on the data plane. The passthrough driver module can be implemented as a new kernel module loaded into the domestic operating system kernel, for example, named vm_direct_net.ko. This module is registered as a new network device driver during initialization and is responsible for detecting the host physical network card and reserving at least some network card resources for passthrough mode.

[0032] S2: Extend the virtual network device of the virtual machine and provide it with a pass-through mode. When the virtual network device is enabled in pass-through mode, it establishes a cooperative working relationship with the pass-through driver module so that network data can be sent and received on the host side without being forwarded by the host user space. The phrase "sent and received on the host side without being forwarded by the host user space" mainly refers to the data plane transmission path, that is, data packets are sent and received on the host side without being forwarded by the user space. Control plane operations such as the establishment, start and stop of pass-through mode and resource configuration can still be completed by the interaction between the virtualization component and the pass-through driver module.

[0033] S3: Receives the pass-through mode enable request initiated by the virtualization component and performs security authentication and resource pre-check. When the pre-check passes, it creates an independent IOMMU protection domain for the target virtual machine based on the IOMMU. S4: Lock the memory pages used for network transmission and reception of the target virtual machine, and establish a mapping from the memory pages to the IOVA within the IOMMU protection domain. Record the mapping relationship in the mapping table to restrict the physical network card to only access the memory range mapped by the virtual machine. S5: Configure the pass-through send queue and pass-through receive queue of the physical network card, make its DMA target address point to the IOVA address range, and establish a control channel for transmitting data packet descriptors and performing notification synchronization between the host side and the virtual machine side; S6: Send pass-through configuration information to the virtual machine side so that the virtual machine side driver initializes the descriptor ring and makes the descriptor point to the mapped network buffer; S7: Execute zero-copy transmission process: The virtual machine side writes the address information and length information corresponding to the data to be sent into the transmission descriptor ring and sends a notification through the control channel. The host machine side pass-through driver module converts the address information into IOVA according to the mapping table and programs it into the physical network card transmission queue descriptor, so that the physical network card DMA engine can directly read data from the virtual machine memory corresponding to the IOVA and send it. S8: Execute zero-copy reception process: When the physical network card receives data, it directly writes the data to the virtual machine memory corresponding to the IOVA through DMA and generates a reception completion notification. The virtual machine side obtains the completed reception descriptor according to the reception descriptor ring and reads the corresponding data. The pass-through driver module employs a lightweight forwarding path on the data plane, performing only necessary frame encapsulation processing while skipping the layered processing flow of the host kernel's TCP / IP protocol stack. This achieves zero-copy acceleration of virtual machine network I / O. The lightweight forwarding path can handle only necessary frame encapsulation, such as Ethernet header encapsulation, and skip the complete TCP / IP protocol stack layered processing flow. This reduces latency and CPU overhead caused by protocol stack processing, thereby improving the throughput of virtual machine network I / O and reducing latency fluctuations.

[0034] As one implementation method, S1 in this embodiment includes: loading the passthrough driver module and triggering initialization after the host machine starts up, initializing the internal data structure; the internal data structure includes at least a virtual machine mapping table (vm_map_table) and a physical network interface card (NIC) queue status table; and detecting the physical NIC, marking at least a portion of the physical NIC's transmit and receive queues as passthrough-dedicated queues, thus isolating the passthrough-dedicated queues from the data path of the host machine kernel network protocol stack. Detecting the physical NIC includes: detecting the system PCI bus, and identifying and locking a specified physical NIC through the vendor ID and device ID; the passthrough-dedicated queue can be marked as "passthrough-dedicated mode" and unbound from the original kernel network protocol stack, so that the passthrough-dedicated queue does not participate in the data path of the host machine kernel network protocol stack. The vm_map_table in the internal data structure is used to record the correspondence between virtual machine memory pages and IOVA addresses used for DMA remapping, and the physical NIC queue status table is used to record the occupancy and running status of the passthrough transmit queue and the passthrough receive queue.

[0035] As one implementation, this embodiment also includes an IOMMU availability check; when the IOMMU is unavailable, it is marked as traditional fallback mode and pass-through mode is disabled, causing the virtual machine to fall back to traditional virtual network mode. The IOMMU may include an Intel VT-d or ARM SMMU; when the IOMMU is detected to be unavailable, the pass-through driver module records an error log and marks itself as "traditional fallback mode," disabling any pass-through functionality; when the IOMMU is detected to be available, the pass-through driver module initializes the interaction interface with the IOMMU driver and requests IOVA address space for DMA remapping.

[0036] In one implementation, the passthrough mode enable request in this embodiment is initiated through a device-specific ioctl interface, carrying virtual machine identification information and memory layout information; the method also includes dynamically enabling or disabling passthrough mode through the ioctl interface. The virtualization component may be QEMU; the passthrough mode enable request may be initiated after the virtual machine memory initialization is complete; the device-specific ioctl command may be VM_DIRECT_NET_ATTACH, and the virtual machine identification information may be the process PID.

[0037] As one implementation, the security authentication of S3 in this embodiment includes verification of the operation permissions of the initiating process; the resource pre-check includes at least verification of the availability of the pass-through dedicated network interface card queue, IOMMU domain space, and DMA-related resources; when any check fails, an error is returned and the system reverts to the traditional virtual network mode. The resource pre-check is used to confirm that at least the available pass-through dedicated network interface card queue, IOMMU domain space, and continuous DMA buffer exist; when any check fails, the pass-through driver module returns an error code, causing the virtual machine to revert to the traditional virtio-net mode for startup.

[0038] In one implementation, the locking operation in S4 of this embodiment involves performing a pin operation on the memory page corresponding to the network buffer to prevent the memory page from being swapped out and to ensure the stability of the DMA access target. A mapping from the memory page to the IOVA is established within the IOMMU protection domain, and the mapping relationship is recorded in the vm_map_table to restrict the physical network card to access only the memory range allocated to this virtual machine. Before or after performing the pin operation, the passthrough driver module can create an independent IOMMU protection domain for the current virtual machine and establish a mapping from the locked virtual machine physical memory page to the IOVA within the IOMMU protection domain. The mapping relationship is recorded in the vm_map_table, ensuring that the physical network card can only access the specific physical memory range allocated to this virtual machine through the IOVA, and cannot access the memory of other virtual machines or the host machine, thereby forming hardware-forced memory isolation.

[0039] In one implementation, S5 in this embodiment includes: configuring interrupts for the pass-through send queue and the pass-through receive queue and establishing a binding relationship with the virtual machine's virtual CPU; and the control channel is a shared memory page or a doorbell register, which is used to transmit descriptors and perform notifications and synchronization, but not to transmit the actual data packet content. The pass-through driver module can set the DMA engine target address of the pass-through send queue and the pass-through receive queue to the IOVA address range allocated for the virtual machine; the control channel is used for metadata exchange, and the metadata is a data packet descriptor, used for notifications and synchronization rather than transmitting the actual data packet content.

[0040] In one implementation, S6 in this embodiment includes: the passthrough driver module encapsulates the queue index, IOVA start address, control channel address, and interrupt information into a configuration block and returns it to the virtualization component. The virtualization component then writes the configuration information into the register or memory area of ​​the passthrough mode front-end driver within the virtual machine, causing the front-end driver within the virtual machine to initialize the ring descriptor queue and point it to the network data buffer located in the virtual machine's memory. After recognizing the passthrough mode, the front-end driver within the virtual machine initializes the ring descriptor queue and makes the descriptor queue point to the network data buffer located in the virtual machine's own physical memory, the address of which can be represented by the virtual machine physical address GPA.

[0041] As one implementation, S7 and S8 in this embodiment include: after the host-side pass-through driver module obtains the descriptor and completes the address translation according to vm_map_table, it programs the converted IOVA and its length into the physical network card queue descriptor, so as to trigger the physical network card to directly read the transmitted data from the virtual machine memory corresponding to the IOVA and write the received data into the virtual machine memory corresponding to the IOVA through DMA, and enable the virtual machine side to complete the transmission completion processing and the received data reading processing according to the descriptor ring.

[0042] The virtual machine side can notify the host side that there is data to be sent by writing to the "doorbell" register, and the "doorbell" register can be mapped to the control channel; the host side pass-through driver module can detect the "doorbell" event and retrieve the descriptor by polling or interrupting; the host side pass-through driver module converts the GPA in the descriptor to IOVA according to vm_map_table, and programs the IOVA and length into the physical network card queue descriptor, so that the physical network card DMA engine can directly read data from the virtual machine memory corresponding to the IOVA and send it, thereby realizing "no copy" data transmission on the host side.

[0043] When the physical network card generates an interrupt after receiving data, the interrupt can be intercepted by the pass-through driver module and directly injected into the vCPU of the corresponding virtual machine according to the binding relationship. The virtual machine driver processes the interrupt and obtains the completed descriptor from the receive descriptor ring, where GPA points to the buffer where data has been written. During the process of data packets from the network card to the virtual machine kernel protocol stack, there is no data copying on the host side and the data does not go through the layered processing of the host kernel network protocol stack.

[0044] As one implementation method, this embodiment also includes stability and maintenance scenario processing, which includes: a) Continuous health checks and anomaly handling: The passthrough driver module's monitoring thread performs health checks at preset intervals. These health checks include at least the passthrough queue error count, the validity of IOMMU mapping entries, and the liveness status of associated virtualization processes. When a network card error, IOMMU mapping anomaly, or multiple consecutive periods of unresponsiveness on the virtual machine side are detected, anomaly handling is triggered. This anomaly handling includes retrying for recoverable errors and pausing passthrough, saving the context, unmapping and releasing resources, notifying the virtualization component to fall back to the traditional path, and logging for unrecoverable errors. b) Virtual machine hot migration support: Upon receiving a migration notification, pause pass-through data paths and complete unprocessed descriptors, unmap and output device status to participate in the migration; re-execute pass-through enabling, mapping establishment and queue configuration on the target host to restore the network; and / or c) Resource release and unloading: When the virtual machine is destroyed, stop the relevant queues, clear the IOMMU mapping and release the IOVA address space, unlock memory pages, delete the vm_map_table entry and destroy the IOMMU protection domain; before unloading the passthrough driver module, if the vm_map_table is empty, release global resources and then complete the unloading.

[0045] The monitoring thread can be a low-priority thread and can perform health checks at a preset cycle, such as once per second. The health check may include: checking the overflow and error counter of the physical network card passthrough queue, verifying the validity of the IOMMU mapping table entries, and checking whether the associated QEMU process is alive. When an uncorrectable error is detected (including PCIe error or DMA error), the IOMMU driver reports a mapping failure or domain error, or the virtual machine has no descriptor update or response for several consecutive cycles (e.g., 5 consecutive cycles), exception handling is triggered. Exception handling may include: resetting the queue and retrying for recoverable minor errors (e.g., a full temporary queue), pausing passthrough for unrecoverable errors or retry failures, saving the descriptor ring state and IOMMU mapping table context, unmapping and releasing the network card queue and IOVA resources, and notifying QEMU to fall back the virtio-net device to standard mode to route network traffic back to the host kernel protocol stack, while recording error codes, detection points, and recovery actions to the kernel log, thereby achieving fault isolation and graceful degradation.

[0046] During the hot migration process, after the passthrough driver module unmaps, it can return the final device status to QEMU. The device status may include the descriptor ring pointer. On the target host, the steps of passthrough request, return configuration information and virtual machine driver initialization can be repeated to re-establish passthrough mapping and restore network connectivity on the new physical network card and IOMMU domain.

[0047] When a virtual machine is destroyed, QEMU can send a VM_DIRECT_NET_DETACH ioctl. When releasing resources, the passthrough driver module can sequentially stop relevant queues to ensure that no ongoing DMA operations are in progress, clear the IOMMU mapping and release the IOVA address space, unlock memory pages and return them to the network card queue, delete entries from the vm_map_table and destroy the IOMMU protection field. Before unloading the passthrough driver module, it checks whether the vm_map_table is empty. If it is not empty, it refuses to unload and reports an error. If it is empty, it releases pre-allocated IOVA space and other global resources and completes safe unloading to avoid resource leaks and ensure long-term stable operation.

[0048] Example 2 The core of this implementation is to modify the kernel of a domestic OS (taking Huawei OpenEuler as an example, but its principle applies to any Linux-based domestic OS) to create a dedicated "passthrough" driver module. This module allows the virtual network device of the virtual machine to establish a direct memory mapping with the physical network card of the host machine, completely bypassing the host kernel protocol stack and achieving zero-copy network I / O. The solution includes the following components: Passthrough driver module: A new module loaded into the domestic OS kernel, responsible for managing the mapping between virtual machine memory and physical network card.

[0049] Virtual device extension: Modify the virtual network device (such as virtio-net) of the virtual machine to support pass-through mode.

[0050] Memory mapping mechanism: Through DMA (Direct Memory Access) remapping technology, the physical address of the virtual machine is directly mapped to the DMA area of ​​the network card.

[0051] Security and isolation mechanisms: Ensure memory isolation and access control in passthrough mode to prevent interference between virtual machines.

[0052] Detailed implementation steps Kernel Modification and Passthrough Driver Module Development: Modify the domestic OS kernel (such as OpenEernel 5.10) to add a new kernel module (e.g., named vm_direct_net.ko). This module registers as a new network device driver during initialization. The module is responsible for detecting the host machine's physical network interface card (such as the Intel 82599 series) and reserving some network interface card resources (such as queues and DMA areas) specifically for passthrough mode. The module implements the ioctl interface for user-space tools (such as QEMU) to configure the virtual machine's memory mapping.

[0053] Virtual Machine Virtual Device Passthrough: This involves modifying the backend of the virtual network device in a virtual machine. Taking virtio-net as an example, the virtio-net device is extended in QEMU by adding a "Passthrough Mode" option. When enabled, virtio-net no longer interacts with the traditional host protocol stack but directly with the passthrough driver module. At virtual machine startup, QEMU calls the passthrough driver module via ioctl to request mapping the virtual machine's memory regions to the physical network interface card's DMA space. This involves translating the virtual machine's physical address (GPA) to the host physical address (HPA) and ensuring secure mapping through an IOMMU (such as Intel VT-d).

[0054] Memory mapping establishment process: The pass-through driver module utilizes IOMMU technology to create a direct mapping from virtual machine memory to network interface card (NIC) DMA. Specifically, the module maintains a mapping table that records the correspondence between virtual machine memory pages and NIC DMA buffers. When the virtual machine sends network data, the data is directly written to the mapped memory area, and the NIC reads the data directly from this area via DMA, without going through the host kernel buffer. Similarly, when receiving data, the NIC DMAs the data to the virtual machine memory, and the virtual machine reads it directly.

[0055] Mathematically, the mapping setup time is negligible, and the data transmission latency is reduced to near the level of a physical machine. Let the physical machine latency be... The traditional solution was delayed for This plan is delayed for ,in It is the mapping overhead, which is usually less than 1 microsecond.

[0056] Path optimization bypassing the protocol stack: The pass-through driver module intercepts network I / O requests from the virtual machine and forwards them directly to the physical network card. It implements a simplified data path, handling only necessary frame encapsulation (such as Ethernet headers) and skipping the full TCP / IP stack. For compatibility, the module supports a fallback mechanism: if pass-through fails (e.g., IOMMU is unavailable), it automatically switches back to the traditional path.

[0057] like Figure 2 The diagram illustrates a traditional virtual machine network I / O data path based on the host kernel protocol stack. From top to bottom, this path includes: virtual machine application (VM App), virtual machine kernel protocol stack, virtual device virtio-net, QEMU user space, host kernel protocol stack, physical network card driver, and physical network card.

[0058] Taking the sending direction as an example: After the virtual machine application (VM App) generates network data to be sent, it first enters the virtual machine kernel protocol stack. The virtual machine kernel completes socket buffer management, protocol processing, and packet organization. Then, the data is submitted to the front-end path of the virtual device virtio-net. The virtual device virtio-net delivers the data to the virtualization component in the QEMU user space in the form of descriptors / queues. QEMU collects, assembles, and performs back-end forwarding of the above queues in user space. After that, the data further enters the host kernel protocol stack. The host kernel performs complete network protocol stack processing on the data (including but not limited to protocol layer processing, buffer organization, and verification-related processing). Then, it is handed over to the host physical network card driver to complete driver layer processing and transmission preparation. Finally, the physical network card sends the data to the physical network through DMA / transmission queue.

[0059] Taking the receiving direction as an example: After the physical network card receives external network data, the physical network card driver sends the data to the host kernel protocol stack. After the host kernel completes the protocol stack processing and buffer organization, it hands the data over to the QEMU user space. QEMU then transfers the data to the virtual device virtio-net, and finally it enters the virtual machine kernel protocol stack and is read by the virtual machine application.

[0060] Depend on Figure 2As can be seen, the data path of traditional solutions spans multiple processing levels, including virtual machine kernel mode, host user mode, and host kernel mode, and is usually accompanied by multiple buffer handovers and context switches. Furthermore, data often needs to be moved or reassembled multiple times between virtual machine protocol stack buffers, user-mode virtualization component buffers, host protocol stack buffers, and network card DMA buffers, thereby introducing additional copy overhead and processing latency. In multi-virtual machine concurrent scenarios, the host kernel protocol stack, as a shared processing path, may also lead to resource contention, further affecting network I / O latency and throughput performance.

[0061] like Figure 3 The diagram illustrates the zero-copy data path for virtual machine network I / O based on a domestically developed operating system pass-through driver, as described in this invention. From top to bottom, this path includes: virtual machine application (VM App), virtual machine kernel protocol stack, pass-through mode virtio-net, pass-through driver module, physical network card DMA, and physical network card.

[0062] Taking the transmission direction as an example: After the virtual machine application (VM App) generates network data to be transmitted, it enters the virtual machine kernel protocol stack. The virtual machine kernel organizes the data to be transmitted in the network buffer in the virtual machine memory. Subsequently, virtio-net, which supports pass-through mode, writes the address information and length information corresponding to the data to be transmitted into the transmission descriptor queue and submits the descriptor information to the pass-through driver module. The pass-through driver module, in the host kernel space, performs address conversion and verification in the descriptor according to a pre-established mapping relationship (e.g., the IOVA mapping table established through the IOMMU), and configures the converted target address into the transmission queue descriptor of the physical network card, enabling the physical network card DMA engine to directly read the data to be transmitted from the virtual machine memory corresponding to the mapped address and complete the transmission. Thus, the transmitted data does not need to be forwarded by the host user space virtualization component on the host side, nor does it need to be processed in the host kernel protocol stack buffer, thereby reducing intermediate processing layers and avoiding data copying on the host side.

[0063] Taking the receiving direction as an example: After the physical network card receives external network data, the physical network card's DMA engine directly writes the data to the mapped memory area associated with the target virtual machine (i.e., the memory location corresponding to the virtual machine's network buffer) based on the receive queue descriptor. The passthrough driver module then notifies the virtual machine side of the receiving completion event. The virtual machine side retrieves the completed descriptor from the receive descriptor queue and reads the corresponding buffer data, which is then processed by the virtual machine kernel protocol stack and read by the virtual machine application. Thus, receiving data does not require layered processing in the host machine's kernel protocol stack, nor does it require data transfer in the host machine's user space.

[0064] and Figure 2Compared to the traditional solution shown, such as Figure 3 As shown, this invention separates the processing of virtual machine network I / O from the common path of host user space forwarding and host protocol stack processing in the data plane. In pass-through mode, network data does not need to be transported through user space virtualization components on the host side, nor does it need to enter the host kernel protocol stack for protocol layering. Instead, it is directly accessed by the physical network card DMA through the mapping relationship established by the pass-through driver module, thereby reducing processing latency and improving network I / O efficiency.

[0065] The performance improvement of this solution can be quantified through a mathematical model. Assume that network throughput (Throughput) is affected by latency (T) and CPU overhead (C). The throughput formula for the traditional solution is: ; Where S is the data packet size. It is the total delay. R is the protocol stack CPU overhead coefficient, and R is the data rate.

[0066] The throughput of this scheme is: ; because and The throughput is significantly improved despite the small size difference. Experimental data shows that in a 10Gb / s network, this solution can increase the throughput from 7Gb / s of the traditional solution to 9.5Gb / s (close to the 9.8Gb / s of the physical machine).

[0067] Details on adaptation to domestic operating systems: For domestic operating systems (such as OpenEuler), this patent modifies the kernel source code to add a passthrough driver module. The module utilizes specific features of domestic operating systems, such as Huawei's KAE (Kunpeng Accelerator Engine) for encryption acceleration, but this solution focuses on network I / O optimization. The module integrates with the IOMMU driver of domestic operating systems (such as ARM SMMU or Intel VT-d) to ensure mapping security.

[0068] Detailed algorithm flow: S1. Host Machine Startup and Module Loading: After the host machine (based on a domestic OS) starts up, the system administrator or the startup script loads the vm_direct_net.ko kernel module. The module initialization function is then called.

[0069] S2. Module Initialization and Hardware Detection: The passthrough driver module initializes its internal data structures (such as the virtual machine mapping table vm_map_table and the physical network card queue status table). The module detects the system PCI bus, discovers and locks the specified physical network card (e.g., by vendor ID and device ID), marks part of its transmit and receive queues as "passthrough-only mode", and unbinds it from the original kernel network protocol stack.

[0070] S3. IOMMU Check and Initialization: The module checks whether the system IOMMU (such as Intel VT-d or ARM SMMU) is enabled and functioning correctly. If the IOMMU is unavailable, the module logs an error and marks itself as "traditional fallback mode," disabling any pass-through functionality. If available, the module initializes the interaction interface with the IOMMU driver and requests IOVA (I / O Virtual Address) address space for DMA remapping.

[0071] S4. Virtual Machine Startup Request Passthrough: When the QEMU process starts a virtual machine, if the command-line parameters specify that "network passthrough mode" is enabled (e.g., -netdev type=direct,...), then after the virtual machine memory is initialized, QEMU initiates a passthrough establishment request to the vm_direct_net module through a device-specific ioctl command (e.g., VM_DIRECT_NET_ATTACH), and passes the virtual machine identifier (e.g., process PID) and memory layout information.

[0072] S5. Security Authentication and Resource Pre-check: Upon receiving a request, the passthrough driver module first performs security authentication (e.g., checking the permissions of the caller's QEMU process), and then pre-checks system resources: confirming that sufficient passthrough dedicated network interface card queues, IOMMU domain space, and continuous DMA buffers are available. If any check fails, an error code is returned, and the virtual machine will fall back to traditional virtio-net mode for startup.

[0073] S6. Create IOMMU protection domain: The module creates an independent IOMMU protection domain for the current virtual machine. This domain will serve as a container for address translation and access control for DMA access of the virtual machine's dedicated device (the pass-through queue of the physical network card).

[0074] S7. Pinning Virtual Machine Memory Pages: The module uses the kernel interface to pin a portion of the virtual machine's physical memory pages (HVA, Host Virtual Address) on the host machine. These pages typically correspond to the virtual machine's network buffer. The locking operation ensures that these pages are not swapped out, guaranteeing that the target physical address for DMA operations remains fixed.

[0075] S8. Establish IOMMU Mapping Table: The module establishes a mapping from the virtual machine physical memory pages (HPA, host physical address) locked in S7 to IOVAs within the IOMMU protection domain. This step is a critical security isolation step, ensuring that the network card can only access the specific physical memory allocated to the virtual machine through IOVAs, and cannot access the memory of other virtual machines or the host machine. The mapping relationship is recorded in the module's vm_map_table.

[0076] S9. Configure Physical Network Interface Card Queues: The module configures a dedicated transmit queue (TX Queue) and receive queue (RX Queue) for the physical network interface card, setting the target address of its DMA engine to the IOVA address range allocated to the virtual machine in the previous step. Simultaneously, it configures the interrupt number of the queue and binds it to the virtual machine's virtual CPU (vCPU) to enable direct interrupt delivery.

[0077] S10. Establish a control channel: The module establishes a small control channel (e.g., a shared memory page or doorbell register) between the host kernel address space and the virtual machine address space for metadata exchange. This channel is used to transmit packet descriptors, rather than the actual packet content, for notification and synchronization.

[0078] S11. Return configuration information: The module encapsulates the configured resource information (such as queue index, IOVA starting address, control channel address, interrupt number, etc.) into a configuration block and returns it to the QEMU process in user space via ioctl.

[0079] S12. Driver Initialization within the Virtual Machine: QEMU writes the received configuration information into specific registers or memory areas of the modified virtio-net passthrough front-end driver within the virtual machine. The driver within the virtual machine is activated, the passthrough mode is recognized, and its internal descriptor ring is initialized, pointing to the network data buffer that has been mapped and is located in its own physical memory (GPA).

[0080] S13. Data transmission process (zero copy): S13.1: Applications within the virtual machine send data via sockets, and the data is copied to the output buffer of the virtual machine kernel protocol stack (this copying is unavoidable and is an internal behavior of the virtual machine).

[0081] S13.2: The virtual machine kernel driver (pass-through mode) fills the GPA and length of the data to be sent into the TX descriptor ring and updates the ring tail pointer.

[0082] S13.3: The driver notifies the host that there is data to be sent by writing to a special "doorbell" register (actually mapped to the control channel).

[0083] S13.4: The host machine's pass-through driver module polls or detects the "doorbell" event through an interrupt and retrieves the descriptor from the descriptor ring.

[0084] S13.5: The module converts the GPA in the descriptor to the corresponding IOVA (via vm_map_table) and directly programs this IOVA and length into the TX queue descriptor of the physical network card.

[0085] S13.6: The module triggers the network card to send data. The network card's DMA engine reads the data packet content directly from the IOVA (i.e., the mapping of virtual machine memory) based on the TX queue descriptor, assembles the frame, and sends it to the physical cable. During this process, the data packet is not copied on the host side.

[0086] S14. Data Reception Process (Zero Copy): S14.1: When the physical network card receives a data packet, the DMA engine writes the data packet directly to the physical memory (i.e., virtual machine memory) corresponding to that IOVA based on the IOVA address in the RX queue descriptor.

[0087] S14.2: The network card generates a receive completion interrupt. This interrupt is intercepted by the pass-through driver module and injected directly into the corresponding virtual machine vCPU according to the binding relationship.

[0088] S14.3: The driver in the virtual machine handles the interrupt, retrieves the completed packet descriptor from the RX descriptor ring, where GPA points to the buffer where the data has been stored.

[0089] S14.4: The virtual machine kernel protocol stack reads data packets from the memory address corresponding to this GPA for processing. During this process, the data packets travel from the network card to the virtual machine application without any copying or protocol stack processing on the host side.

[0090] S15. Continuous Health Check: The passthrough driver module runs a low-priority monitoring thread in the background, periodically (e.g., once per second) checking the following: S15.1 Queue Health: Checks the overflow and error counter of the physical network card's pass-through queue.

[0091] S15.2 Memory Mapping Validity: Verify the validity of IOMMU mapping entries.

[0092] S15.3 Virtual machine liveness status: Check whether the associated QEMU process is alive.

[0093] S16. Anomaly Detection: Anomaly detection is triggered in the following situations: S16.1 Network device error: The network card reports an uncorrectable error (PCIe error, DMA error).

[0094] S16.2 IOMMU Fault: IOMMU driver reports mapping failure or domain error.

[0095] S16.3 Virtual machine unresponsive: The monitoring thread detected that the virtual machine has not updated any descriptors or responded for a long time (e.g., 5 consecutive cycles).

[0096] S17. Fault Recovery Procedure: S17.1 Graceful Rollback: When a recoverable minor error is detected (such as a full temporary queue), the module attempts to reset the queue and retry the operation. If the retry fails, or a critical error as described in S16 is detected, the module initiates the rollback process.

[0097] S17.2 State Preservation: The module first pauses operations on the virtual machine pass-through queue and saves the current descriptor ring state, IOMMU mapping table and other key contexts.

[0098] S17.3 Resource Cleanup: The module removes the mapping within the virtual machine's IOMMU protection domain and releases occupied network card queues, IOVA addresses, and other resources.

[0099] S17.4 Traditional Path Reconstruction: The module notifies the QEMU process. QEMU then reinitializes the virtual machine's virtio-net device to standard mode (non-passthrough), routing the virtual machine's network traffic back to the host kernel .1 protocol stack. This process appears internally to the virtual machine as a brief network jitter and reconnection.

[0100] S17.5 Fault Log: Records detailed error codes, checkpoints, and recovery actions in the kernel log for administrator analysis.

[0101] S18. Virtual machine hot migration support: When the hypervisor initiates a virtual machine hot migration, QEMU notifies the passthrough driver module via ioctl.

[0102] S18.1: The module pauses the pass-through data path and completes the processing of any unfinished data packet descriptors.

[0103] S18.2: The module removes all relevant mappings on the current host machine and returns the final device state (such as the descriptor ring pointer) to QEMU.

[0104] S18.3: QEMU migrates this device state as part of the virtual machine state to the target host.

[0105] S18.4: On the target host, repeat steps S4-S12 to re-establish passthrough mapping on the new physical network card and IOMMU domain, and restore the network.

[0106] S19. Virtual Machine Destruction and Resource Release: When a virtual machine is shut down, QEMU sends VM_DIRECT_NET_DETACHioctl.

[0107] S19.1: The module stops all relevant queues to ensure that there are no ongoing DMA operations.

[0108] S19.2: Clear the IOMMU mapping and release the IOVA address space.

[0109] S19.3: Release memory page locking and return the network card queue to the idle resource pool.

[0110] S19.4: Remove all entries for this virtual machine from the vm_map_table and destroy its IOMMU protection domain.

[0111] S20. Module Unloading: When the system needs to unload the vm_direct_net.ko module, the module checks if vm_map_table is empty. If it is not empty (indicating that some virtual machines are still using passthrough), the unloading fails and an error is reported. If it is empty, all occupied global resources (such as pre-allocated IOVA space) are released sequentially, and the module is safely unloaded.

[0112] Compared with the prior art, this embodiment has the following advantages and effects. This solution reduces network I / O latency from hundreds of microseconds to tens of microseconds in traditional solutions, while achieving throughput close to that of physical machines. In traditional solutions, data copying and protocol stack processing are the main bottlenecks. This solution eliminates these overheads; as shown in the flowchart, the data path is direct and concise. Mathematically, the latency reduction is... This primarily stems from the elimination of copy and protocol stack time. For high-traffic scenarios, throughput can be increased by more than 30%, which is crucial for cloud computing and high-speed network applications.

[0113] This solution significantly reduces CPU utilization by avoiding context switching and protocol stack processing. Experiments show that, when handling the same traffic, CPU utilization can be reduced from 50% to 10% compared to traditional solutions. CPU overhead mainly comes from data copying and interrupt handling. This solution reduces the number of copies and interrupt frequency through direct memory mapping. Formulaically, the CPU savings can be modeled as follows: ,in It refers to the number of copies. This refers to the overhead of a single copy operation. The saved CPU resources can be used to run more virtual machines or applications, improving overall energy efficiency.

[0114] This solution, through pass-through isolation, avoids contention for shared host protocol stacks, allowing more virtual machines to run simultaneously without performance degradation. In traditional solutions, the protocol stack is a shared resource, leading to increased lock contention as the number of virtual machines increases. This solution provides an independent mapping path for each virtual machine, reducing resource conflicts. Tests show that when the number of virtual machines increases from 10 to 50, the throughput of this solution decreases by only 5%, while the traditional solution decreases by 50%. This enhances the scalability of domestically developed cloud platforms.

[0115] This solution, optimized for domestic operating systems, addresses the shortcomings of general-purpose kernels in virtualization scenarios, bringing the performance of domestic cloud infrastructure in line with international standards. Domestic operating systems are typically based on community kernels and lack in-depth optimization. The pass-through driver module in this patent is customized for domestic operating systems, resolving specific bottlenecks, such as improving compatibility and performance by adapting to the IOMMU of domestic hardware (e.g., Huawei Kunpeng chips).

[0116] This embodiment achieves high performance without compromising security and supports a rollback mechanism to ensure compatibility. Specifically, the following design ensures system security and stability: Hardware-enforced memory isolation: A core security mechanism involves establishing an independent address translation table for each virtual machine through IOMMU protection domains (S6, S8). This ensures that even if the physical network card is misconfigured or attacked, its DMA operations are strictly limited to the physical memory allocated to that virtual machine, preventing damage to other virtual machines or the host kernel, thus fundamentally eliminating DMA-based memory attacks.

[0117] Minimizing the kernel attack surface: In traditional solutions, the complex kernel network protocol stack is exposed to all virtual machines. This solution moves the data plane out of the general protocol stack, and the dedicated pass-through driver module (S1) has a highly focused function (only handling mapping and descriptor forwarding). The code is small and the logic is simple, which significantly reduces the potential kernel vulnerability attack surface.

[0118] Fault detection and isolation recovery: Health checks (S15), anomaly detection (S16), and fault recovery procedures (S17) constitute a complete stability assurance mechanism. When a single virtual machine's passthrough channel or associated hardware fails, the system can automatically detect it and quickly and isolatedly fall back to the traditional network path (S17.4), preventing the fault from spreading and ensuring the continuity of services for other virtual machines and the overall stability of the host machine. This "fault isolation and graceful degradation" capability is not available in traditional shared protocol stack solutions.

[0119] Controllable resource management: The module performs strict resource checks and reservations during initialization (S2, S3) and virtual machine requests (S5), avoiding disorderly resource contention. A clear resource release process (S19, S20) also prevents resource leaks and improves the long-term stability of the system.

[0120] Supports standard management operations: By designing to support hot migration (S18), this solution can be integrated into the existing virtualization operation and maintenance management system, meeting the production environment's requirements for flexibility and maintainability, which is also an important aspect of stability.

[0121] In summary, the technical effectiveness of this embodiment stems from the pass-through mapping and protocol stack bypass in the specific solution. By reducing data path complexity and CPU involvement, high-performance network I / O is achieved. The inference is based on network theory and technical implementation, and the results are supported by mathematics and experiments.

[0122] This embodiment is unique because it deeply modifies the domestic OS kernel, creating a dedicated passthrough driver module to achieve zero-copy network acceleration. Existing alternatives such as SR-IOV (Single Root I / O Virtualization) or DPDK (Data Plane Development Kit) cannot directly replace it: SR-IOV requires hardware support and is complex to configure, making it unsuitable for domestic environments; DPDK bypasses the kernel but requires user-space drivers and lacks virtual machine integration. This patented solution is an innovative hardware and software co-optimization, with no direct equivalent replacement.

[0123] Although embodiments of the present invention have been shown and described above, it is understood that the above embodiments are exemplary and should not be construed as limiting the present invention. Those skilled in the art can make changes, modifications, substitutions and variations to the above embodiments within the scope of the present invention.

Claims

1. A zero-copy acceleration method for virtual machine network I / O based on a domestic operating system pass-through driver, characterized by: include: S1: Customize and modify the kernel of the domestic operating system, and introduce a dedicated pass-through driver module. The pass-through driver module is used to directly manage the mapping relationship between virtual machine memory and host physical network card DMA access, and bypass the host kernel network protocol stack processing path in the data plane. S2: Extend the virtual network device of the virtual machine and provide it with a pass-through mode, so that the virtual network device can establish a cooperative working relationship with the pass-through driver module when the pass-through mode is enabled, so that network data can be sent and received on the host side without being forwarded by the host user space; S3: Receives the pass-through mode enable request initiated by the virtualization component and performs security authentication and resource pre-check. When the pre-check passes, it creates an independent IOMMU protection domain for the target virtual machine based on the IOMMU. S4: Lock the memory pages used for network transmission and reception of the target virtual machine, and establish a mapping from the memory pages to the IOVA within the IOMMU protection domain. Record the mapping relationship in the mapping table to restrict the physical network card to only access the memory range mapped by the virtual machine. S5: Configure the pass-through send queue and pass-through receive queue of the physical network card, make its DMA target address point to the IOVA address range, and establish a control channel for transmitting data packet descriptors and performing notification synchronization between the host side and the virtual machine side; S6: Send pass-through configuration information to the virtual machine side so that the virtual machine side driver initializes the descriptor ring and makes the descriptor point to the mapped network buffer; S7: Execute zero-copy transmission process: The virtual machine side writes the address information and length information corresponding to the data to be sent into the transmission descriptor ring and sends a notification through the control channel. The host machine side pass-through driver module converts the address information into IOVA according to the mapping table and programs it into the physical network card transmission queue descriptor, so that the physical network card DMA engine can directly read data from the virtual machine memory corresponding to the IOVA and send it. S8: Execute zero-copy reception process: When the physical network card receives data, it directly writes the data to the virtual machine memory corresponding to the IOVA through DMA and generates a reception completion notification. The virtual machine side obtains the completed reception descriptor according to the reception descriptor ring and reads the corresponding data. The pass-through driver module uses a lightweight forwarding path in the data plane, performing only necessary frame encapsulation processing while skipping the layered processing flow of the host kernel TCP / IP protocol stack, thereby achieving zero-copy acceleration of virtual machine network I / O.

2. The method according to claim 1, characterized in that: S1 includes: after the host machine starts up, loading the passthrough driver module and triggering initialization, initializing the internal data structure; the internal data structure includes at least a virtual machine mapping table vm_map_table and a physical network card queue status table; and detecting the physical network card, marking at least a portion of the physical network card's transmit and receive queues as passthrough dedicated queues, so that the passthrough dedicated queues are isolated from the data path of the host machine kernel network protocol stack.

3. The method according to claim 2, characterized in that: It also includes an IOMMU availability check; when the IOMMU is unavailable, it is marked as traditional fallback mode and pass-through mode is disabled, causing the virtual machine to fall back to traditional virtual network mode.

4. The method according to claim 3, characterized in that: The passthrough mode enable request is initiated through a device-specific ioctl interface and carries virtual machine identification information and memory layout information; the method also includes dynamically enabling or disabling passthrough mode through the ioctl interface.

5. The method according to claim 4, characterized in that: The S3 security authentication includes verification of the operation permissions of the initiating process; the resource pre-check includes at least verification of the availability of the pass-through dedicated network card queue, IOMMU domain space and DMA-related resources; when any verification fails, an error is returned and the system reverts to the traditional virtual network mode.

6. The method according to claim 5, characterized in that: The locking operation of S4 involves performing a pin operation on the memory page corresponding to the network buffer to prevent the memory page from being swapped out and to ensure the stability of the DMA access target; and establishing a mapping from the memory page to the IOVA within the IOMMU protection domain, recording the mapping relationship in the vm_map_table to restrict the physical network card to only access the memory range allocated to the virtual machine.

7. The method according to claim 6, characterized in that: S5 includes: configuring interrupts for the pass-through send queue and the pass-through receive queue and establishing a binding relationship with the virtual machine's virtual CPU; and the control channel is a shared memory page or a doorbell register, the control channel is used to transmit descriptors and perform notifications and synchronization, but does not transmit actual data packet content.

8. The method according to claim 7, characterized in that: The S6 includes: the pass-through driver module encapsulates the queue index, IOVA start address, control channel address and interrupt information into a configuration block and returns it to the virtualization component, and the virtualization component writes the configuration information into the register or memory area of ​​the pass-through mode front-end driver in the virtual machine, so that the front-end driver in the virtual machine initializes the ring descriptor queue and points to the network data buffer located in the virtual machine memory.

9. The method according to claim 8, characterized in that: S7 and S8 include: after the host-side pass-through driver module obtains the descriptor and completes the address translation according to the vm_map_table, it programs the converted IOVA and its length into the physical network card queue descriptor, so as to trigger the physical network card to directly read the transmitted data from the virtual machine memory corresponding to the IOVA and write the received data into the virtual machine memory corresponding to the IOVA through DMA, and enable the virtual machine side to complete the transmission completion processing and the received data reading processing according to the descriptor ring.

10. The method according to claim 9, characterized in that: It also includes stability and operation and maintenance scenario handling, which includes: a) Continuous health checks and anomaly handling: The passthrough driver module's monitoring thread performs health checks at preset intervals. These health checks include at least the passthrough queue error count, the validity of IOMMU mapping entries, and the liveness status of associated virtualization processes. When a network card error, IOMMU mapping anomaly, or multiple consecutive periods of unresponsiveness on the virtual machine side are detected, anomaly handling is triggered. This anomaly handling includes retrying for recoverable errors and pausing passthrough, saving the context, unmapping and releasing resources, notifying the virtualization component to fall back to the traditional path, and logging for unrecoverable errors. b) Virtual machine hot migration support: Upon receiving a migration notification, pause pass-through data paths and complete unprocessed descriptors, unmap and output device status to participate in the migration; re-execute pass-through enabling, mapping establishment and queue configuration on the target host to restore the network; and / or c) Resource release and unloading: When the virtual machine is destroyed, stop the relevant queues, clear the IOMMU mapping and release the IOVA address space, unlock memory pages, delete the vm_map_table entry and destroy the IOMMU protection domain; before unloading the passthrough driver module, if the vm_map_table is empty, release global resources and then complete the unloading.

Images