Implementation architecture, implementation method and computing device for virtual machine using dpu function

Abstract

The application provides an implementation architecture and method of virtual machine using DPU function and a computing device, the implementation architecture is based on a DPU mounted with at least one function device and a host configured with the DPU, and the implementation architecture comprises a virtual machine monitor, a DPU device aggregation layer and a DPU driving module, wherein the virtual machine monitor comprises a DPU device simulation layer, the DPU device simulation layer interacts with the DPU device aggregation layer; the DPU device aggregation layer interacts with the DPU driving module, thereby providing the DPU device simulation layer with a hardware layer function of the DPU and the function device mounted with the DPU; and the DPU driving module is used for driving the DPU and the function device mounted with the DPU, and providing the DPU device aggregation layer with a use interface of the DPU and a use interface of the function device mounted with the DPU. According to the technical solution of the application, the management and configuration can be simplified, the actual hardware function and device layer are decoupled, and the flexibility of management is improved.

Description

Technical Field

[0001] This invention relates to the field of computer network technology, and specifically to an implementation architecture, implementation method, and computing device for virtual machines using DPU functionality. Background Technology

[0002] In current virtualization technology, the hardware resources of virtual machines (VMs), such as DPUs, storage, and GPUs, are typically virtualized into multiple independent virtual devices. Figure 1 The diagram illustrates currently common virtualization technologies; see [link / reference]. Figure 1 For example, a DPU is virtualized as a virtual network interface card (vNIC), a storage device as a virtual block device (vDisk), and a GPU as a virtual graphics card (vGPU). Each virtual device corresponds to a specific implementation of a physical device, and the virtual machine interacts with the outside world through these devices. The management and configuration of these devices are typically handled by the host administrator. In this traditional architecture, the host administrator needs to configure each hardware device separately, such as setting different network interface cards, storage volumes, and graphics cards. While these virtual devices provide an abstraction of hardware functionality, the host administrator still needs to manage and configure various hardware devices, failing to focus on the actual application functionality.

[0003] It is evident that while current virtualization technology is mature, its architecture remains fundamentally at the "device-level abstraction" level. Faced with the rapid proliferation of heterogeneous resources such as DPUs, GPUs, and intelligent storage, the traditional approach of virtualizing physical devices one-to-one as vNICs, vDisks, and vGPUs is increasingly revealing its structural flaws. Administrators are forced to manually configure various device drivers, network policies, storage volumes, and GPU memory allocations at the host layer. This "hardware-centric" management paradigm is not only cumbersome and error-prone but also leads to difficulties in cross-device collaboration and severe resource silos. Especially in cloud-native and AI computing scenarios, applications have increasingly strong demands for low latency, high throughput, and elastic resources. However, the fragmented management of network, storage, and computing resources in the existing architecture makes performance tuning complex and difficult to achieve global optimization, significantly increasing operational costs and technical barriers. Moreover, the existing virtualization architecture bundles hardware devices with functions, such as network functions with DPUs and storage functions with disk devices. This requires virtual machine management to focus on the specific hardware implementation, reducing the flexibility and efficiency of virtual machine functional design. Therefore, existing technologies have not yet solved the problem of decoupling device functionality from virtual device management, and have significant shortcomings in terms of flexible configuration. A deeper problem is that this architecture fails to achieve a true "service-oriented" transformation. Virtual machines still see discrete hardware interfaces (such as virtio-blk, virtio-net), rather than on-demand computing, networking, or storage capabilities. Administrators' energy is tied to adapting and debugging underlying devices, preventing them from focusing on business logic and application value delivery. As computing power demands become heterogeneous and specialized, single CPU virtualization is insufficient to support modern workloads. Current technologies lack a standardized and automated integration framework for unified scheduling of DPU offloading for networking, GPU-accelerated computing, and NVMe-oF providing remote storage, resulting in limited overall system efficiency and low resource utilization.

[0004] Therefore, a technical solution is needed that can ignore the complexity of device management, focus not only on the functions provided by virtual devices, simplify management and configuration, decouple actual hardware functions from the device layer, improve management flexibility, and make the function configuration of virtual machines no longer bound to physical devices, but adjusted entirely based on the needs of virtual machine users. Summary of the Invention

[0005] This application aims to provide an implementation architecture, implementation method, and computing device for virtual machines to use DPU functionality. It can ignore the complexity of device management, focus not only on the functions provided by the virtual device, simplify management and configuration, decouple the actual hardware functions from the device layer, improve management flexibility, and make the virtual machine's function configuration no longer bound to the physical device, but completely adjusted based on the virtual machine user's needs.

[0006] According to one aspect of this application, an implementation architecture for virtual machines using DPU functionality is provided. This architecture is based on a DPU equipped with at least one functional device and a host configured with the DPU. The architecture includes: a virtual machine monitor, a DPU device aggregation layer, and a DPU driver module.

[0007] The virtual machine monitor includes a DPU device emulation layer, which interacts with the DPU device aggregation layer to discover virtual functional devices of the DPU device aggregation layer and provide the virtual functional devices to at least one virtual machine.

[0008] The DPU device aggregation layer interacts with the DPU driver module. Through the DPU user interface provided by the DPU driver module and the user interface of the functional device attached to the DPU, the functions provided by the DPU and the functions provided by the functional device attached to the DPU are aggregated to form a virtual functional device, thereby providing the hardware layer functions of the DPU and the functional device attached to the DPU to the DPU device simulation layer.

[0009] The DPU driver module is used to drive the DPU and the functional devices attached to the DPU, and to provide the DPU device aggregation layer with the usage interface of the DPU and the usage interface of the functional devices attached to the DPU.

[0010] According to some embodiments, after the virtual machine is created and started, it interacts with the DPU device emulation layer through a first virtio interface, and the virtual machine uses the DPU device emulation layer through the first virtio interface.

[0011] According to some embodiments, the DPU device simulation layer interacts with the DPU device aggregation layer through a second virtio interface and discovers the virtual functional devices of the DPU device aggregation layer through the virtio protocol.

[0012] According to some embodiments, the DPU device emulation layer also provides a configuration interface for enabling or disabling the virtual functional device.

[0013] According to some embodiments, the DPU device aggregation layer interacts with the DPU driver module through an Auxiliary bus interface, and the at least one functional device includes a GPU and / or a storage device.

[0014] According to another aspect of this application, a method for implementing virtual machine use of DPU functionality is provided. This method is applied to an implementation architecture as described in any of the preceding claims. The implementation architecture is based on a DPU mounted with at least one functional device and a host configured with the DPU. The architecture includes a virtual machine monitor, a DPU device aggregation layer, and a DPU driver module. The implementation method includes:

[0015] After creation and startup, at least one virtual machine interacts with the DPU device simulation layer in the virtual machine monitor and uses the virtual functional devices provided by the DPU device simulation layer. The DPU device simulation layer interacts with the DPU device aggregation layer to discover the virtual functional devices of the DPU device aggregation layer and provide the virtual functional devices to at least one virtual machine.

[0016] The DPU device aggregation layer interacts with the DPU driver module. Through the DPU user interface provided by the DPU driver module and the user interface of the functional device attached to the DPU, the layer aggregates the functions provided by the DPU and the functional device attached to the DPU to form a virtual functional device, thereby providing the hardware layer functions of the DPU and the functional device attached to the DPU to the DPU device simulation layer.

[0017] The DPU driver module is used to drive the DPU and the functional devices attached to the DPU, and to provide the DPU device aggregation layer with the usage interface of the DPU and the usage interface of the functional devices attached to the DPU.

[0018] According to some embodiments, the virtual machine interacts with the DPU device emulation layer through a first virtio interface, and the virtual machine uses the DPU device emulation layer through the first virtio interface.

[0019] According to some embodiments, the DPU device simulation layer interacts with the DPU device aggregation layer through a second virtio interface and discovers the virtual functional devices of the DPU device aggregation layer through the virtio protocol.

[0020] According to some embodiments, it also includes: enabling or disabling the functions of each virtual device through the configuration interface provided by the DPU device emulation layer.

[0021] According to some embodiments, the DPU device aggregation layer interacts with the DPU driver module through an Auxiliary bus interface, and the at least one functional device includes a GPU and / or a storage device.

[0022] According to another aspect of this application, a computing device is provided, comprising: a DPU on which at least one functional device is mounted and a host configured with the DPU, wherein the host and the DPU are integrated into the implementation architecture described in any of the preceding claims.

[0023] According to another aspect of this application, a non-transitory computer-readable storage medium is provided, having stored thereon computer-readable instructions that, when executed by a processor, cause the processor to perform the method as described in any of the preceding claims.

[0024] According to embodiments of this application, by introducing a DPU device simulation layer and a DPU device aggregation layer, unified abstraction and centralized management of various hardware functions are achieved. Compared to traditional virtualization environments, where each hardware function (such as network, storage, and GPU) often requires independent virtual device models and driver support, resulting in complex virtual machine configuration and fragmented management, this solution integrates these functions into a unified virtual device framework supported by a DPU. Host administrators only need to interact with a single logical device interface to schedule and control multiple types of resources, significantly simplifying the deployment and maintenance of the virtual machine environment.

[0025] According to some embodiments, the technical solution of this invention supports dynamically enabling or disabling specific hardware functions based on the actual business needs of the virtual machine, achieving decoupling of functions from the underlying physical hardware. Host administrators can complete function configuration and resource scheduling without needing in-depth knowledge of the specific models, interface characteristics, or driver details of the DPU or peripherals. All hardware capabilities are uniformly discovered and reported by the DPU device aggregation layer and transmitted to the DPU device emulation layer via the standard virtio protocol, forming a hardware-independent virtualization interface. This not only reduces dependence on specific hardware platforms but also enhances the portability and compatibility of virtual machines across different physical environments.

[0026] It should be understood that the above general description and the following detailed description are merely exemplary and do not limit this application. Attached Figure Description

[0027] To more clearly illustrate the technical solutions in the embodiments of this application, the accompanying drawings used in the description of the embodiments will be briefly introduced below.

[0028] Figure 1 This diagram illustrates a common virtualization technology used in existing technologies.

[0029] Figure 2 This diagram illustrates an implementation architecture of a virtual machine using DPU functionality according to an example embodiment.

[0030] Figure 3 The flowchart illustrates a method for implementing DPU functionality in a virtual machine according to an example embodiment.

[0031] Figure 4 A block diagram of a computing device according to an exemplary embodiment is shown. Detailed Implementation

[0032] Exemplary embodiments will now be described more fully with reference to the accompanying drawings. However, these exemplary embodiments can be implemented in many forms and should not be construed as limited to the embodiments set forth herein; rather, they are provided so that this application will be thorough and complete, and will fully convey the concept of the exemplary embodiments to those skilled in the art. The same reference numerals in the drawings denote the same or similar parts, and therefore repeated descriptions of them will be omitted.

[0033] Furthermore, the described features, structures, or characteristics can be combined in any suitable manner in one or more embodiments. Numerous specific details are provided in the following description to give a thorough understanding of embodiments of this application. However, those skilled in the art will recognize that the technical solutions of this application can be practiced without one or more of the specific details, or other methods, components, apparatuses, steps, etc., can be employed. In other instances, well-known methods, apparatuses, implementations, or operations are not shown or described in detail to avoid obscuring various aspects of this application.

[0034] The block diagrams shown in the accompanying drawings are merely functional entities and do not necessarily correspond to physically independent entities. That is, these functional entities can be implemented in software, in one or more hardware modules or integrated circuits, or in different network and / or processor devices and / or microcontroller devices.

[0035] The flowcharts shown in the accompanying drawings are merely illustrative and do not necessarily include all content and operations / steps, nor do they necessarily need to be performed in the described order. For example, some operations / steps can be broken down, while others can be combined or partially combined; therefore, the actual execution order may change depending on the specific circumstances.

[0036] It should be understood that although the terms first, second, third, etc., may be used herein to describe various components, these components should not be limited by these terms. These terms are used to distinguish one component from another. Therefore, the first component discussed below may be referred to as the second component without departing from the teachings of this application. As used herein, the term "and / or" includes all combinations of any one and more of the associated listed items.

[0037] The user information (including but not limited to user device information, user personal information, etc.) and data (including but not limited to data used for analysis, data stored, data displayed, etc.) involved in this application are all information and data authorized by the user or fully authorized by all parties. Furthermore, the collection, use and processing of the relevant data must comply with the relevant laws, regulations and standards of the relevant countries and regions, and corresponding operation entry points are provided for users to choose to authorize or refuse.

[0038] Those skilled in the art will understand that the accompanying drawings are merely schematic diagrams of exemplary embodiments, and the modules or processes in the drawings are not necessarily essential for implementing this application, and therefore cannot be used to limit the scope of protection of this application.

[0039] In current virtualization technologies, the hardware resources of virtual machines (VMs), such as DPUs, storage, and GPUs, are typically virtualized as multiple independent virtual devices. For example, a DPU is virtualized as a virtual network interface card (vNIC), a storage device as a virtual block device (vDisk), and a GPU as a virtual graphics card (vGPU). Each virtual device corresponds to a specific implementation of the physical device, and the VM interacts with the outside world through these devices. The management and configuration of these devices are usually handled by the host administrator. In this traditional architecture, the host administrator needs to configure each hardware device separately, such as setting different network interface cards, storage volumes, and graphics cards. While these virtual devices provide an abstraction of hardware functionality, the host administrator still needs to manage and configure various hardware devices, failing to focus on the actual application functionality.

[0040] The deeper problem lies in the fact that this architecture fails to achieve a true "service-oriented" transformation. Virtual machines still see discrete hardware interfaces (such as virtio-blk and virtio-net), rather than on-demand computing, networking, or storage capabilities. Administrators are tied to adapting and debugging the underlying devices, unable to focus on delivering business logic and application value. As computing power demands become more heterogeneous and specialized, single CPU virtualization is insufficient to support modern workloads. Current technologies lack a standardized and automated framework for unified scheduling of DPU offloading for networking, GPU-accelerated computing, and NVMe-oF for remote storage, resulting in limited overall system efficiency and low resource utilization.

[0041] To address this, this application proposes an architecture, method, and computing device for virtual machines to utilize DPU functionality. This approach ignores the complexity of device management, focusing not only on the functions provided by the virtual device but also simplifying management and configuration. It decouples actual hardware functions from the device layer, improving management flexibility and allowing virtual machine configuration to be adjusted entirely based on user needs, rather than being tied to physical devices. According to the embodiments, by introducing a DPU device simulation layer and a DPU device aggregation layer, unified abstraction and centralized management of various hardware functions are achieved. Compared to traditional virtualization environments where each hardware function (such as network, storage, and GPU) often requires independent virtual device models and driver support, leading to complex virtual machine configuration and fragmented management, this solution integrates these functions into a unified virtual device framework supported by a DPU. Host administrators only need to interact with a single logical device interface to schedule and control multiple types of resources, significantly simplifying the deployment and maintenance of the virtual machine environment.

[0042] According to some embodiments, the technical solution of this invention supports dynamically enabling or disabling specific hardware functions based on the actual business needs of the virtual machine, thus decoupling functions from the underlying physical hardware. Host administrators can complete function configuration and resource scheduling without needing in-depth knowledge of the specific models, interface characteristics, or driver details of the DPU or peripherals. All hardware capabilities are uniformly discovered and reported by the DPU device aggregation layer and transmitted to the DPU device emulation layer via the standard virtio protocol, forming a hardware-independent virtualization interface. This not only reduces dependence on specific hardware platforms but also enhances the portability and compatibility of virtual machines across different physical environments.

[0043] Before describing the embodiments of this application, some terms or concepts involved in the embodiments of this application will be explained.

[0044] A Data Processing Unit (DPU) is a dedicated programmable processor that integrates a high-performance computing core and a hardware acceleration engine. It is primarily used to offload and accelerate infrastructure tasks within a data center, such as network packet processing, storage I / O operations, security encryption, and virtualization management. DPUs typically work in conjunction with the CPU, freeing up main CPU resources by taking over I / O-intensive tasks, thereby improving overall system performance and energy efficiency.

[0045] In a virtualization architecture, a host server (HOST) refers to the physical server running the Virtual Machine Monitor (VMM), which is the underlying hardware platform that hosts multiple virtual machine instances. It provides computing, storage, and networking resources, and uses virtualization technology to abstract and allocate these resources, supporting the operation of upper-layer virtual machines. A host typically runs a host operating system (HostOS), responsible for managing DPU drivers, device aggregation layers, and other system services.

[0046] A virtual machine (VM) is an independent, isolated virtual computing environment created on top of physical hardware using virtualization technology. Each VM can run its own operating system and applications, appearing to the user as an independent physical computer. In this architecture, multiple VMs run on the same host and communicate efficiently with underlying resources through the virtio interface.

[0047] A Virtual Machine Monitor (VMM), also known as a Hypervisor, is the core virtualization software layer running on the host, responsible for creating, managing, and scheduling multiple virtual machine instances. The VMM provides a virtual hardware environment, enabling resource isolation and sharing between virtual machines, and handling virtual machine access requests to underlying physical resources. In this solution, the VMM includes a DPU device emulation layer, used to simulate virtio devices and forward I / O requests.

[0048] Virtio: A Linux I / O virtualization technology framework. Virtio is a standardized I / O virtualization framework designed for Linux systems to improve the communication efficiency between virtual machines and the host machine. It employs paravirtualization technology and defines a set of common device interfaces (such as virtio-net and virtio-blk), enabling front-end drivers in the virtual machine and back-end processing modules in the VMM or HOST to efficiently exchange data through shared memory and notification mechanisms, significantly reducing virtualization overhead and improving I / O performance.

[0049] The auxiliary bus is a lightweight bus interface in the Linux kernel used to connect logical devices and drivers. It is suitable for device models that do not use traditional physical bus connections. In this architecture, the auxiliary bus is used to implement communication between the DPU device aggregation layer and various DPU drivers in the virtual system. It supports modular design, facilitating functional expansion and dynamic driver loading.

[0050] A Graphics Processing Unit (GPU) is a processor designed specifically for parallel computing. Originally used for graphics rendering, it is now widely applied in high-performance computing, artificial intelligence training and inference, scientific simulation, and other fields. In this virtualization architecture, the GPU is directly connected to and uniformly scheduled by the DPU, and multiple virtual machines can share the same resources through virtualization technology, achieving efficient allocation of graphics or AI acceleration capabilities.

[0051] The following description, in conjunction with the accompanying drawings, illustrates exemplary embodiments of this application.

[0052] Figure 2 This diagram illustrates an implementation architecture of a virtual machine using DPU functionality according to an example embodiment.

[0053] See Figure 2 The figure shows an implementation architecture for a virtual machine using DPU functionality. The implementation architecture is based on a DPU with at least one functional device mounted on it and a host configured with the DPU. The implementation architecture includes: a virtual machine monitor, a DPU device aggregation layer, and a DPU driver module.

[0054] According to some embodiments, the implementation architecture generally consists of at least one virtual machine instance, which is the user-facing runtime environment in the entire virtualization architecture. Each virtual machine instance can independently run an operating system and applications, providing users with isolated computing space and supporting diverse business needs.

[0055] According to some implementations, when a user operates within a virtual machine, such as accessing the network, reading or writing data, or invoking graphics functions, the system automatically generates corresponding operation requests. These operation requests are encapsulated by the operating system inside the virtual machine through a standard virtio driver and sent out through an efficient paravirtualization interface. These virtual machines themselves do not directly access underlying hardware resources; instead, they transmit all I / O requests to the Virtual Machine Monitor (VMM), which is responsible for subsequent scheduling and processing. This ensures system security and isolation while providing good compatibility and performance for upper-layer applications. In this way, efficient interaction with the user is achieved, and the foundation for unified management and accelerated processing of underlying resources is laid. All requests from multiple virtual machines are reported in an orderly manner, facilitating aggregation, optimization, and offloading to the DPU for execution in subsequent layers, thereby improving the overall system's resource utilization and response efficiency.

[0056] According to some embodiments, the virtual machine monitor includes a DPU device emulation layer. This layer interacts with the DPU device aggregation layer, discovers virtual functional devices in the aggregation layer, and provides these virtual functional devices to at least one virtual machine. The virtual machine monitor manages and schedules multiple virtual machines, receiving operation requests from the virtual layer (including at least one virtual machine). The virtual machine monitor bears the core responsibility of unified management and resource scheduling for multiple virtual machine instances. The virtual machine monitor includes a DPU device emulation layer capable of emulating standard virtio network cards, storage controllers, and GPU devices, providing consistent and compatible virtual device interfaces for upper-layer virtual machines. When a virtual machine initiates an I / O operation, the DPU device emulation layer receives these operation requests from the virtual machine layer and parses and processes them.

[0057] According to some embodiments, upon receiving an operation request from a virtual machine, the DPU device emulation layer transforms it from abstract instructions of the virtual device into actual operation instructions that can be executed by the underlying hardware. This process fully leverages the advantages of paravirtualization technology, ensuring high performance while avoiding the additional overhead of full virtualization. The transformed instructions are no longer processed directly by the host CPU but are encapsulated and forwarded to the host operating system layer for further transmission to a dedicated DPU for accelerated execution. The virtual machine monitor not only achieves effective isolation and allocation of virtual machine resources but also acts as a bridge between the virtualization environment and the DPU hardware, allowing upper-layer applications to remain unaware of changes in the underlying hardware while supporting flexible feature configuration and dynamic adjustments, providing crucial support for building efficient and scalable modern data center virtualization architectures.

[0058] According to some embodiments, the DPU device aggregation layer interacts with the DPU driver module. Through the user interface of the DPU provided by the DPU driver module and the user interface of the functional devices attached to the DPU, the aggregation layer aggregates the functions provided by the DPU and the functional devices attached to the DPU, forming a virtual functional device. This provides the hardware layer functions of the DPU and the functional devices attached to the DPU to the DPU device simulation layer. The DPU driver module drives the DPU device and manages and controls the attached devices of the DPU device through the user interface of the DPU provided by the DPU driver module and the user interface of the functional devices attached to the DPU. The DPU device aggregation layer receives hardware operation instructions from the virtual machine monitor and distributes them to the corresponding type of DPU driver in the DPU driver module for processing. The DPU driver then drives the DPU device and manages and controls the attached devices of the DPU device, thereby aggregating the functions of the DPU and its attached devices using the DPU driver, providing network interface card, storage, GPU, and other functions to the DPU device simulation layer. Generally, the DPU device aggregation layer and multiple DPU driver modules are located below the virtual machine monitor. This layer is a crucial intermediary connecting the virtualization management layer and the underlying hardware, responsible for interfacing with hardware operation commands from the upper layer and coordinating the scheduling and execution of DPU resources. As a core component of the virtual system, the DPU device aggregation layer receives various hardware operation commands translated by the virtual machine monitor, such as network packet processing, storage read / write, or GPU acceleration requests.

[0059] According to some embodiments, the DPU device aggregation layer has instruction classification and routing functions, which can distribute instructions to the corresponding DPU drivers of the DPU driver modules according to the instruction type. For example, storage instructions are sent to the NVMe-DPU driver, and network instructions are handled by the network acceleration driver. This modular design based on function improves the maintainability and scalability of the system. Each DPU driver communicates with the DPU device aggregation layer through a standard interface, further transmitting instructions to the DPU chip via the PCIe bus to trigger its actual operation on the physical device. Through the collaborative work of the DPU device aggregation layer and the DPU drivers, the host operating system achieves unified management and efficient access to DPU resources, which not only reduces the CPU's involvement in I / O processing but also ensures low latency and high throughput of the data path, providing solid support for building a high-performance virtualization environment. At the same time, the decoupled design of the driver layer also provides a good foundation for future expansion to support new DPUs or added functions.

[0060] According to some embodiments, after creation and startup, the virtual machine interacts with the DPU device emulation layer through a first virtio interface, and the virtual machine uses the DPU device emulation layer through the first virtio interface. The virtual machine communicates with the DPU device emulation layer through the first virtio interface, achieving efficient and compatible I / O data transmission. Virtio, as a standardized paravirtualization device interface, enables the operating system within the virtual machine to initiate network, storage, and GPU operation requests in a near-native performance manner. When a user performs related tasks in the virtual machine, the system encapsulates the request through the virtio driver and passes it to the DPU device emulation layer. This interaction mechanism does not require the virtual machine to be aware of the specific implementation of the underlying hardware; it only needs to follow the virtio protocol to complete data exchange. The DPU device emulation layer acts as the virtio backend in the VMM, receiving requests from the virtual machine frontend driver and performing subsequent processing. This virtio-based frontend and backend communication mode not only ensures good performance but also has broad system compatibility, supporting mainstream operating systems and virtualization platforms.

[0061] According to some embodiments, the DPU device emulation layer interacts with the DPU device aggregation layer through a second virtio interface, discovering the virtual functional devices of the DPU device aggregation layer via the virtio protocol. By introducing the second virtio interface, the entire virtualization architecture maintains a lightweight design while achieving efficient abstraction and optimization of the I / O path, providing a unified and reliable transmission channel for subsequently offloading tasks to the DPU. When the DPU device emulation layer translates the virtual machine's I / O requests into hardware operation instructions in the Virtual Machine Monitor (VMM), these instructions are encapsulated via the second virtio protocol and sent to the host-side DPU device aggregation layer. The second virtio interface acts as a lightweight communication channel across security domains and execution environments at this level, maintaining compatibility with the existing virtualization ecosystem while avoiding the performance overhead of traditional full virtualization. The DPU device aggregation layer, as the receiver of the virtio backend, can identify and parse various operation instructions from the upper layer and classify them according to their type. This design achieves functional decoupling between the Virtual Machine Monitor and the host operating system, allowing the VMM to focus on virtual device emulation and virtual machine scheduling. Interacting through a unified virtio interface not only improves the modularity of the system, but also provides flexible scalability for the integration of DPU devices from multiple vendors.

[0062] According to some embodiments, the DPU device emulation layer also provides a configuration interface for enabling or disabling the virtual functional device. The DPU device emulation layer further includes a configuration interface that allows host administrators to configure the DPU device emulation layer via command lines to selectively enable or disable at least one of network transmission, storage, and GPU functions. This configuration can be implemented in various forms, such as configuration files or configuration commands. For example, using a configuration file:

[0063] Assuming we use vmX-config.txt as the configuration file for virtual machine X, we can define a configuration format in the configuration file, for example:

[0064] net : 1; 1 indicates that the network function is enabled;

[0065] disk: 1; 1 indicates that storage is enabled;

[0066] gpu: 1; 1 indicates that GPU functionality is enabled.

[0067] Assuming the name of the DPU device emulation layer is dev-emu, its commands can be defined in the following form:

[0068] `dev-emu vmX net on` enables network functionality.

[0069] `dev-emu vmX disk on` indicates that storage functionality is enabled.

[0070] `dev-emu vmX gpu on` means enabling GPU functionality.

[0071] According to some embodiments, the configuration interface allows host administrators to flexibly control virtualization functions. Administrators can dynamically configure the functions of the DPU device emulation layer on the host side using command-line configuration tools. For example, they can selectively enable or disable virtual device functions such as network transmission, storage access, or GPU acceleration based on business needs. This configuration capability allows for more granular management of system resource allocation and security policies. For instance, in scenarios where graphics processing is not required, GPU functions can be disabled to reduce the attack surface or save resources; when only computationally intensive tasks are running, unnecessary storage or network emulation functions can be disabled to improve system efficiency. All configuration operations can be completed during system runtime without restarting the virtual machine or reloading the underlying drivers. This design enhances the maintainability and adaptability of the virtualization architecture, enabling administrators to quickly respond to changes in the needs of different application scenarios, enabling hardware acceleration functions on demand, thereby optimizing overall resource utilization and system security.

[0072] According to some embodiments, the DPU device aggregation layer interacts with the DPU driver module through a logical software bus interface (such as an auxiliary bus interface), and the at least one functional device includes a GPU and / or a storage device. The DPU device aggregation layer communicates with the DPU driver module through the logical software bus interface (such as an auxiliary bus interface), achieving decoupling and efficient collaboration between modules within the host operating system. When the DPU device aggregation layer receives hardware operation instructions from the virtual machine monitor, it needs to distribute these instructions according to their type to the corresponding DPU driver, such as a network processing driver, storage driver, or GPU management driver. This distribution process is completed through the auxiliary bus.

[0073] The auxiliary bus is a lightweight kernel device model bus designed specifically for binding logical devices and drivers that are not connected via traditional physical buses. It allows the DPU device aggregation layer to register functional submodules as a "parent device" and route different types of I / O requests to the corresponding registered DPU drivers. This mechanism avoids hard-coded dependencies between drivers, improving system modularity and scalability.

[0074] Through the auxiliary bus interface, the system can flexibly load, unload, or update DPU drivers for specific functions without affecting the operation of other components. This not only simplifies driver management but also provides a solid architectural foundation for supporting multiple DPU models and new features, enhancing the stability and maintainability of the entire virtualization system.

[0075] Figure 3 The flowchart illustrates a method for implementing DPU functionality in a virtual machine according to an example embodiment.

[0076] See Figure 3 The figure illustrates an implementation method for a virtual machine using DPU functionality, which is applied to the implementation architecture described in any of the preceding items. See also... Figure 2 The implementation architecture is based on a DPU equipped with at least one functional device and a host configured with the DPU. The implementation architecture includes a virtual machine monitor, a DPU device aggregation layer, and a DPU driver module. The implementation method includes:

[0077] In S301, after creation and startup, at least one virtual machine interacts with the DPU device emulation layer in the virtual machine monitor and uses the virtual functional devices provided by the DPU device emulation layer. The DPU device emulation layer interacts with the DPU device aggregation layer, discovers the virtual functional devices of the DPU device aggregation layer, and provides the virtual functional devices to at least one virtual machine.

[0078] According to some embodiments, firstly, after at least one virtual machine is created and started, its internal operating system establishes communication with the DPU device emulation layer in the Virtual Machine Monitor (VMM) through a standard device driver (such as a virtio driver) to request the use of virtual functional devices. Specifically, the virtual machine interacts with the DPU device emulation layer through a first virtio interface, and the virtual machine uses the DPU device emulation layer through the first virtio interface.

[0079] In S303, the DPU device aggregation layer interacts with the DPU driver module. Through the DPU usage interface provided by the DPU driver module and the usage interface of the functional device attached to the DPU, the functions provided by the DPU and the functions provided by the functional device attached to the DPU are aggregated to form a virtual functional device, thereby providing the hardware layer functions of the DPU and the functional device attached to the DPU to the DPU device simulation layer.

[0080] According to some embodiments, the DPU device emulation layer actively interacts with the host-side DPU device aggregation layer. The DPU device emulation layer interacts with the DPU device aggregation layer through a second virtio interface, discovering the virtual functional devices of the DPU device aggregation layer via the virtio protocol. The list of virtual functional devices currently supported by the DPU device aggregation layer is dynamically discovered using the virtio protocol. These functionalities originate from the DPU's own capabilities and the physical devices it is attached to (e.g., network offloading, NVMe storage access, or vGPU rendering). Based on the discovery results, the DPU device emulation layer exposes the corresponding virtual devices, such as virtio-net, virtio-blk, or virtio-gpu, to the virtual machine.

[0081] In S305, the DPU driver module is used to drive the DPU and the functional devices attached to the DPU, and to provide the DPU device aggregation layer with the usage interface of the DPU and the usage interface of the functional devices attached to the DPU.

[0082] According to some embodiments, the DPU device aggregation layer runs in the host operating system kernel and continuously communicates with the DPU driver module. The DPU driver module is responsible for initializing and managing the DPU chip and its directly connected physical devices (via the PCIe bus), and registering various hardware function interfaces with the DPU device aggregation layer. The DPU device aggregation layer logically integrates these heterogeneous functions—including the capabilities of the DPU's built-in acceleration engine and the services of external GPU / storage devices—and abstracts them into a unified "virtual functional device," which is then provided to the DPU device simulation layer.

[0083] According to some embodiments, the DPU device aggregation layer interacts with the DPU driver module through an Auxiliary bus interface, and the at least one functional device includes a GPU and / or a storage device. The DPU device aggregation layer interacts with the DPU driver module through the Auxiliary bus interface, thereby achieving efficient decoupling and communication between functional modules in the host operating system kernel. The Auxiliary bus is a lightweight logical bus mechanism provided by the Linux kernel, suitable for binding and message passing between devices and drivers that are not connected by traditional physical buses. The DPU driver module, as the underlying hardware driver, is responsible for managing the DPU chip and at least one functional device mounted via the PCIe bus, including GPUs and / or storage devices (such as NVMe SSDs). This design gives the system good modularity and scalability. For new functional devices, only the corresponding interface needs to be implemented in the DPU driver module and registered through the Auxiliary bus; there is no need to modify the core logic of the aggregation layer or simulation layer. Meanwhile, GPUs and storage devices are directly connected via DPU (PCIe Peer-to-Peer), and are uniformly scheduled by DPU, avoiding the bottleneck of CPU involvement in data transfer in traditional solutions, and significantly improving the efficiency and security of virtual machines accessing high-performance peripherals.

[0084] According to some embodiments, the method further includes enabling or disabling the functions of each virtual device via a publicly available configuration interface. Before starting the virtualization architecture, the configuration of the DPU device emulation layer is set through the configuration interface, thereby selecting the hardware functions to be enabled. The implementation also includes a configuration interface through which host administrators can pre-configure the functions of the DPU device emulation layer according to actual business needs before starting the implementation architecture. For example, in pure computing application scenarios, administrators can disable GPU function emulation in advance to reduce resource overhead and potential security risks. In storage-intensive scenarios, only storage and network functions can be enabled to achieve optimal resource allocation. This method not only improves system security and resource utilization but also avoids performance losses caused by invalid device enumeration. Since the configuration operation is based on the actual capabilities detected by the DPU, the rationality and executability of function selection are ensured. The entire process does not require restarting the host or redeploying the underlying drivers, achieving rapid and dynamic deployment preparation and enhancing the adaptability of the virtualization architecture in diverse scenarios.

[0085] According to some embodiments, the configuration interface allows host administrators to dynamically enable or disable specific hardware functions without restarting the virtual machine or reconfiguring the underlying physical devices. The configuration interface supports host administrators in dynamically enabling or disabling specific hardware functions exposed by the DPU device emulation layer, such as network, storage, or GPU capabilities, during virtualization system operation. This function adjustment can be completed in real time without interrupting business operations or restarting the virtual machine, and without requiring reinitialization or reconfiguration of the underlying physical hardware such as the DPU, storage devices, or GPU.

[0086] According to some embodiments, when an administrator issues an enable or disable command via command settings, the DPU device simulation layer responds immediately, updating its internal functional status table and synchronously adjusting the virtio device list presented to the virtual machine. For example, if the storage function is temporarily disabled, the corresponding virtio-blk device will be logically unloaded, the virtual machine will be unable to initiate new storage I / O requests, and existing connections can be smoothly handled or disconnected according to the policy. Based on the pre-discovery and abstract management of DPU hardware functions by the DPU device aggregation layer, all optional functions are identified during the system initialization phase. The on / off operations at runtime are only software-level logical controls, ensuring the efficiency, security, and low overhead of the startup or disable process. This is suitable for scenarios such as dynamic resource scheduling, security policy changes, or fault isolation in multi-tenant environments, significantly improving the system's flexibility, maintainability, and resource utilization.

[0087] According to some embodiments, the bus interface includes a PCIe bus interface, through which the DPU achieves high-speed interconnection with the host system and external devices. The PCIe bus provides a high-bandwidth, low-latency communication channel, supporting efficient data transmission between the DPU and the CPU, memory, and mounted devices. In this architecture, the DPU directly connects to and manages various devices, including GPUs and / or storage devices (such as NVMe SSDs), via the PCIe bus, enabling unified access and resource scheduling for these high-performance peripherals.

[0088] According to some embodiments, via the PCIe bus, the DPU can directly access the GPU to allocate and monitor graphics or AI computing tasks, and can also perform I / O scheduling, data encryption, or remote access (such as NVMe-oF) on storage devices. This direct connection avoids the bottleneck of forwarding through the host CPU in traditional solutions, significantly improving data processing efficiency. Simultaneously, as the I / O hub, the DPU can virtualize and abstract the GPU and storage devices, dividing physical resources into multiple logical instances for shared use by multiple virtual machines. This fully utilizes the point-to-point architecture and high throughput of the PCIe bus. Combined with the DPU's hardware acceleration capabilities, a heterogeneous resource management platform centered on the DPU is constructed, suitable for application scenarios with stringent I / O performance requirements, such as cloud computing, artificial intelligence, and high-performance storage.

[0089] According to some embodiments, the technical solution of the present invention achieves unified abstraction and centralized management of various hardware functions by introducing a DPU device simulation layer and a DPU device aggregation layer. Compared with traditional virtualization environments, where each hardware function (such as network, storage, GPU) often requires independent virtual device models and driver support, resulting in complex virtual machine configuration and decentralized management, this solution integrates these functions into a unified virtual device framework supported by DPU. Host administrators only need to face a single logical device interface to complete the scheduling and control of multiple types of resources, significantly simplifying the deployment and operation and maintenance of the virtual machine environment.

[0090] According to some embodiments, the technical solution of this invention supports dynamically enabling or disabling specific hardware functions based on the actual business needs of the virtual machine, achieving decoupling of functions from the underlying physical hardware. Host administrators can complete function configuration and resource scheduling without needing in-depth knowledge of the specific models, interface characteristics, or driver details of the DPU or peripherals. All hardware capabilities are uniformly discovered and reported by the DPU device aggregation layer and transmitted to the DPU device emulation layer via the standard virtio protocol, forming a hardware-independent virtualization interface. This not only reduces dependence on specific hardware platforms but also enhances the portability and compatibility of virtual machines across different physical environments.

[0091] According to some embodiments, the technical solution of the present invention integrates multiple hardware acceleration capabilities such as network, storage, and GPU into a unified virtual device entity through the collaborative design of the DPU device simulation layer and the DPU device aggregation layer, realizing "all-in-one" functional integration; combined with the configuration interface mechanism, it supports dynamic adjustment of the function set of the virtual device at runtime, truly realizing "software-defined" virtual device management, and providing key technical support for building a flexible, efficient, and easy-to-maintain next-generation data center virtualization platform.

[0092] Figure 4A block diagram of a computing device according to an example embodiment of this application is shown.

[0093] like Figure 4 As shown, the computing device 30 includes a processor 12 and a memory 14. The computing device 30 may also include a bus 22, a DPU device 16, and an I / O interface 18. The processor 12, memory 14, DPU device 16, and I / O interface 18 can communicate with each other via the bus 22.

[0094] Processor 12 may include one or more general-purpose CPUs (Central Processing Units), microprocessors, or application-specific integrated circuits (ASICs) for executing relevant program instructions. Memory 14 may include machine-readable media in the form of volatile memory, such as random access memory (RAM), read-only memory (ROM), and / or cache memory. Memory 14 is used to store one or more programs containing instructions, as well as data. Processor 12 can read instructions stored in memory 14 to perform the methods described above according to embodiments of this application.

[0095] The computing device 30 can also communicate with one or more networks via the DPU device 16. The DPU device 16 can mount various devices, such as GPUs and storage devices. The bus 22 can include an address bus, a data bus, and a control bus. The bus 22 provides a path for information exchange between components.

[0096] It should be noted that, in specific implementations, the computing device 30 may also include other components necessary for normal operation. Furthermore, those skilled in the art will understand that the device described above may only include the components necessary for implementing the embodiments of this specification, and not necessarily all the components shown in the figures.

[0097] This application also provides a computer-readable storage medium having a computer program stored thereon, which, when executed by a processor, implements the steps of the above-described method. The computer-readable storage medium may include, but is not limited to, any type of disk, including floppy disks, optical disks, DVDs, CD-ROMs, microdrives, as well as magneto-optical disks, ROMs, RAMs, EPROMs, EEPROMs, DRAMs, VRAMs, flash memory devices, magnetic cards or optical cards, nanosystems (including molecular memory ICs), network storage devices, cloud storage devices, or any type of medium or device suitable for storing instructions and / or data.

[0098] This application also provides a computer program product including a non-transitory computer-readable storage medium storing a computer program operable to cause a computer to perform some or all of the steps of any of the methods described in the above method embodiments.

[0099] Those skilled in the art will clearly understand that the technical solutions of this application can be implemented using software and / or hardware. In this specification, "unit" and "module" refer to software and / or hardware capable of independently performing or cooperating with other components to perform a specific function, where the hardware may be, for example, a field-programmable gate array (FPGA), integrated circuit, etc.

[0100] It should be noted that, for the sake of simplicity, the foregoing method embodiments are all described as a series of actions. However, those skilled in the art should understand that this application is not limited to the described order of actions, as some steps may be performed in other orders or simultaneously according to this application. Furthermore, those skilled in the art should also understand that the embodiments described in the specification are preferred embodiments, and the actions and modules involved are not necessarily essential to this application.

[0101] In the above embodiments, the descriptions of each embodiment have different focuses. For parts not described in detail in a certain embodiment, please refer to the relevant descriptions in other embodiments.

[0102] In the several embodiments provided in this application, it should be understood that the disclosed apparatus can be implemented in other ways. For example, the apparatus embodiments described above are merely illustrative; for instance, the division of units is only a logical functional division, and in actual implementation, there may be other division methods. For example, multiple units or components may be combined or integrated into another system, or some features may be ignored or not executed. Furthermore, the coupling or direct coupling or communication connection shown or discussed may be through some service interface; the indirect coupling or communication connection between apparatuses or units may be electrical or other forms.

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

[0104] Furthermore, the functional units in the various embodiments of this application can be integrated into one processing unit, or each unit can exist physically separately, or two or more units can be integrated into one unit. The integrated unit can be implemented in hardware or as a software functional unit.

[0105] If the integrated unit is implemented as a software functional unit and sold or used as an independent product, it can be stored in a computer-readable storage device. Based on this understanding, the technical solution of this application, in essence, or the part that contributes to the prior art, or all or part of the technical solution, can be embodied in the form of a software product. This computer software product is stored in a memory and includes several instructions to cause a computer device (which may be a personal computer, server, or network device, etc.) to execute all or part of the steps of the methods of the various embodiments of this application.

[0106] In the above embodiments, the descriptions of each embodiment have different focuses. For parts not described in detail in a certain embodiment, please refer to the relevant descriptions in other embodiments.

[0107] The exemplary embodiments of this application have been specifically shown and described above. It should be understood that this application is not limited to the detailed structures, arrangements, or implementation methods described herein; rather, this application is intended to cover various modifications and equivalent arrangements contained within the spirit and scope of the appended provisions.

Claims

1. An implementation architecture for virtual machines using DPU functionality, characterized in that, The implementation architecture is based on a DPU equipped with at least one functional device and a host configured with the DPU. The implementation architecture includes: a virtual machine monitor, a DPU device aggregation layer, and a DPU driver module. The virtual machine monitor includes a DPU device emulation layer, which interacts with the DPU device aggregation layer to discover virtual functional devices of the DPU device aggregation layer and provide the virtual functional devices to at least one virtual machine. The DPU device aggregation layer interacts with the DPU driver module. Through the DPU user interface provided by the DPU driver module and the user interface of the functional device attached to the DPU, the functions provided by the DPU and the functions provided by the functional device attached to the DPU are aggregated to form a virtual functional device, thereby providing the hardware layer functions of the DPU and the functional device attached to the DPU to the DPU device simulation layer. The DPU driver module is used to drive the DPU and the functional devices attached to the DPU, and to provide the DPU device aggregation layer with the usage interface of the DPU and the usage interface of the functional devices attached to the DPU.

2. The implementation architecture according to claim 1, characterized in that, After creation and startup, the virtual machine interacts with the DPU device emulation layer through the first virtio interface, and uses the DPU device emulation layer through the first virtio interface.

3. The implementation architecture according to claim 2, characterized in that, The DPU device simulation layer interacts with the DPU device aggregation layer through the second virtio interface and discovers the virtual functional devices of the DPU device aggregation layer through the virtio protocol.

4. The implementation architecture according to claim 1, characterized in that, The DPU device simulation layer also provides a configuration interface for starting or disabling the virtual function device.

5. The implementation architecture according to claim 1, characterized in that, The DPU device aggregation layer interacts with the DPU driver module through the Auxiliary bus interface, and the at least one functional device includes a GPU and / or a storage device.

6. A method for implementing DPU functionality in a virtual machine, characterized in that, The implementation method is applied to the implementation architecture as described in any one of claims 1 to 5, the implementation architecture being based on a DPU equipped with at least one functional device and a host configured with the DPU, the architecture including a virtual machine monitor, a DPU device aggregation layer, and a DPU driver module, the implementation method comprising: After creation and startup, at least one virtual machine interacts with the DPU device simulation layer in the virtual machine monitor and uses the virtual functional devices provided by the DPU device simulation layer. The DPU device simulation layer interacts with the DPU device aggregation layer to discover the virtual functional devices of the DPU device aggregation layer and provide the virtual functional devices to at least one virtual machine. The DPU device aggregation layer interacts with the DPU driver module. Through the DPU user interface provided by the DPU driver module and the user interface of the functional device attached to the DPU, the layer aggregates the functions provided by the DPU and the functional device attached to the DPU to form a virtual functional device, thereby providing the hardware layer functions of the DPU and the functional device attached to the DPU to the DPU device simulation layer. The DPU driver module is used to drive the DPU and the functional devices attached to the DPU, and to provide the DPU device aggregation layer with the usage interface of the DPU and the usage interface of the functional devices attached to the DPU.

7. The implementation method according to claim 6, characterized in that, The virtual machine interacts with the DPU device emulation layer through the first virtio interface, and the virtual machine uses the DPU device emulation layer through the first virtio interface.

8. The implementation method according to claim 7, characterized in that, The DPU device simulation layer interacts with the DPU device aggregation layer through the second virtio interface and discovers the virtual functional devices of the DPU device aggregation layer through the virtio protocol.

9. The implementation method according to claim 6, characterized in that, Also includes: The configuration interface provided by the DPU device simulation layer allows you to enable or disable the functions of each virtual device.

10. The implementation method according to claim 6, characterized in that, The DPU device aggregation layer interacts with the DPU driver module through the Auxiliary bus interface, and the at least one functional device includes a GPU and / or a storage device.

11. A computing device, characterized in that, include: A DPU equipped with at least one functional device and a host configured with the DPU, wherein the host and the DPU are integrated into an implementation architecture as described in any one of claims 1 to 5.

Images