A GPU virtualization implementation method based on SR-IOV technology

Abstract

The application is suitable for the technical field of computer virtualization, and provides a GPU virtualization implementation method based on SR-IOV technology, which comprises the following steps: S1, dividing the independent resources of a physical GPU through SR-IOV technology; S2, installing a virtual graphics card driver in a user layer virtual machine; S3, establishing a communication transmission mechanism of a Hypervisor layer Host OS and the user layer virtual machine; S4, after the user layer virtual machine initiates an API request, transmitting the API request to the Host OS through the Hypervisor layer, and processing the API request in sequence according to the event priority and the time stamp, wherein each virtual machine can only access the corresponding independent resources, so as to guarantee the resource isolation and safety during use. The application is based on layered design, can flexibly divide the physical GPU resources according to the number of virtual machines, and can specifically define and sort the functions of each part of the virtualization scheme, so as to improve the low resource utilization rate of the traditional GPU virtualization scheme and solve the problem that the traditional GPU virtualization scheme cannot guarantee the safety of resource isolation.

Description

Technical Field

[0001] This invention belongs to the field of computer virtualization technology, and in particular relates to a GPU virtualization implementation method based on SR-IOV technology. Background Technology

[0002] In recent years, with the increasing demands for GPU resource utilization and security in multi-user modes, GPU virtualization technology has developed rapidly. GPU virtualization refers to abstracting the hardware resources of the GPU and providing them for shared use by multiple users to maximize GPU resource utilization. As a system-level hardware and software solution, GPU virtualization has been widely applied in cloud sharing platforms, VDI, remote assistance, and other fields as user demands for GPU resources have diversified. This technology, while fully utilizing the internal computing resources of the GPU, provides flexible user PC management capabilities, has strong scalability, and effectively ensures the isolation of internal video memory, computing power, and faults among users.

[0003] Currently, the main solution for GPU virtualization is API redirection. This approach, without considering hardware details, directly intercepts API requests from the virtual machine that call the graphics library and sends them to the physical GPU for processing. However, this approach significantly increases the system burden on the CPU to manage all virtual machines, especially when multiple virtual machines are used simultaneously, making it difficult to guarantee context isolation and frame buffer isolation for GPU time-sharing.

[0004] Furthermore, to reduce system load, one solution proposes directly dividing the physical GPU into multiple modules. During use, each partitioned physical GPU is provided to the upper-layer virtual machine via pass-through. Each virtual machine installs a real physical graphics card driver. However, this solution is only suitable for applications with a fixed number of virtual machines. Because the physical GPU resources are pre-allocated, resources are wasted when the number of virtual machines is less than the number of GPU partitions. Additionally, installing real physical graphics card drivers on virtual machines poses a security risk, as a single virtual machine could potentially gain unauthorized access to other partitioned physical GPU resources. Summary of the Invention

[0005] In view of the above problems, the purpose of this invention is to provide a GPU virtualization implementation method based on SR-IOV technology, which aims to solve the problems of low resource utilization and failure to guarantee the security of resource isolation in traditional GPU virtualization schemes.

[0006] The present invention adopts the following technical solution:

[0007] The GPU virtualization implementation method based on SR-IOV technology includes the following steps:

[0008] Step S1: Divide the independent resources of the physical GPU using SR-IOV technology;

[0009] Step S2: Install the virtual graphics card driver in the user-level virtual machine;

[0010] Step S3: Establish a communication and transmission mechanism between the Host OS in the Hypervisor layer and the virtual machine in the user layer;

[0011] Step S4: After the user-level virtual machine initiates an API request, it is transmitted to the Host OS through the Hypervisor layer. The Host OS processes the requests in order according to the event priority and timestamp. Each virtual machine can only access its corresponding independent resources, ensuring resource isolation and security during use.

[0012] Furthermore, the specific process of step S1 is as follows:

[0013] S11. Based on the configured number of virtual machines, determine the number of physical GPU partitions, which is fixed to an even number. If the number of virtual machines is odd, the number of physical GPU partitions is the number of virtual machines plus 1.

[0014] S12. Divide the address space within the physical GPU into a first space and a second space. The first space is used for configurable control register space, connecting the display module, and non-configurable computing power and video encoding / decoding scheduling unit. The second space is used to provide access to the upper-layer graphics controller and to save the graphics context and store temporary data.

[0015] S13. Divide the first space and the second space equally according to the number of physical GPU partitions;

[0016] S14. Establish the mapping relationship between virtual addresses and physical addresses through the MMIO page table.

[0017] Furthermore, the specific process of step S2 is as follows:

[0018] S21. Configure the virtual machine to non-transparent transmission mode;

[0019] S22. Set the virtual machine on the Hypervisor layer and set the virtual machine number, where the virtual machine with number 0 is the Host OS with the highest privilege level;

[0020] S23. When installing the virtual graphics card driver, each user-level virtual machine with a number greater than 0 stores a separate virtual machine identifier and records the address space allocated to it and mapped through the MMIO page table; the virtual graphics card driver provides the standard graphics library OpenGL graphics library API functions to the upper-layer application, and the virtual graphics card driver is used to intercept and forward the API requests of the user-level virtual machine.

[0021] Furthermore, the specific process of step S3 is as follows:

[0022] S31. Automatically create a one-to-one correspondence between Virtio virtual devices and virtual machines in the Hypervisor layer. The front-end driver of the Virtio virtual device is provided by the virtual graphics card driver, and the back-end driver is only used to receive information transmitted from the front-end driver and forward it to the Host OS.

[0023] S32. The backend driver sets up a circular queue, VirtQueue, to facilitate data exchange between the Host OS and the virtual machine.

[0024] Furthermore, the specific process of step S4 is as follows:

[0025] S41. The user layer program used for display or graphics rendering first calls the graphics middleware. The graphics middleware decomposes the display or graphics rendering task into basic graphics drawing requirements, and then calls the underlying standard graphics library OpenGL to generate API requests for basic graphics drawing.

[0026] S42. The virtual graphics card driver of the user-level virtual machine is the same as the current API request. After receiving the API request, the API interface records the function parameters based on the drawing task and event priority, the API call order and timestamp, the configured virtualized GPU identifier, and the software status information.

[0027] S43. After the information recorded by the virtual graphics card driver is packaged into the API request, it is transmitted to the backend driver of the Hypervisor layer through the Virtio virtual device created by the Hypervisor layer.

[0028] The backend driver of the S44 Hypervisor layer transmits all API requests from user virtual machines sequentially to the Host OS numbered 0 through a circular queue VirtQueue.

[0029] S45 and Host OS create multiple independent transmission channels to receive and parse API requests, process them according to high priority, process them according to timestamp order for the same priority, and call the native graphics card driver to access the physical GPU in a thread manner.

[0030] S46. The physical GPU processes various API requests transmitted from the Host OS, and the processing results are transmitted back to the Host OS as return values. The Host OS then transmits them to the corresponding virtual machines through the Hypervisor layer's circular queue, VirtQueue.

[0031] The beneficial effects of this invention are as follows: This invention implements a GPU virtualization method based on SR-IOV technology through a layered design. Multiple modules in the layered design can also be processed and improved independently. In practical use, the virtual machine installs the virtual graphics card driver, establishes a communication relationship with the Host OS through the Hypervisor layer, and re-allocates the independent resources of the physical GPU. The Host OS receives API requests from all virtual machines and processes them centrally. By directly accessing the physical GPU, different API requests are time-sharingly scheduled using computing resources and video encoding / decoding resources, and the calculated results are transmitted back to the corresponding virtual machine system. This invention maximizes the utilization of GPU resources, reduces the CPU system burden, and ensures security under resource isolation. Attached Figure Description

[0032] Figure 1 This is a flowchart of a GPU virtualization implementation method based on SR-IOV technology provided in an embodiment of the present invention;

[0033] Figure 2 This is an implementation framework diagram of the GPU virtualization implementation method provided in the embodiments of the present invention. Detailed Implementation

[0034] To make the objectives, technical solutions, and advantages of this invention clearer, the invention will be further described in detail below with reference to the accompanying drawings and embodiments. It should be understood that the specific embodiments described herein are merely illustrative and not intended to limit the invention.

[0035] To illustrate the technical solution described in this invention, specific embodiments are described below.

[0036] Figure 1 The flowchart of the GPU virtualization implementation method based on SR-IOV technology provided in the embodiment of the present invention is shown. Figure 2 The diagram illustrates the implementation framework of an embodiment of the present invention. For ease of explanation, only the parts related to the embodiments of the present invention are shown.

[0037] like Figure 1 , 2 As shown, the GPU virtualization implementation method based on SR-IOV technology includes the following steps:

[0038] Step S1: Divide the independent resources of the physical GPU using SR-IOV technology.

[0039] This step implements the partitioning of physical GPU resources, such as memory, controller, and connectivity modules, using SR-IOV technology. Upper-layer I / O operations access physical GPU resources through a separate physical address space and the partitioned virtual MMIO page tables. Shared resources such as physical GPU computing power and video encoding / decoding are time-sharing scheduled based on task priority and timestamps.

[0040] The specific process for this step is as follows:

[0041] S11. Based on the configured number of virtual machines, determine the number of physical GPU partitions, which is fixed to an even number. If the number of virtual machines is odd, the number of physical GPU partitions is the number of virtual machines plus 1.

[0042] S12. Divide the address space within the physical GPU into a first space and a second space. The first space is used for configurable control register space, connecting display modules, and non-configurable computing power and video encoding / decoding scheduling units. The second space is used to provide access to the upper-layer graphics controller and to save graphics context and store temporary data.

[0043] Taking a GPU with 32GB of video memory as an example, 4GB of video memory is allocated as the first space, which serves as the configurable control register space (CRTC), the connector for the display module, and the non-configurable computing power and video encoding / decoding scheduling unit. The remaining 28GB of video memory is the second space, which is provided to the upper-level graphics controller for storing graphics context and temporary data.

[0044] S13. Divide the first space and the second space equally according to the number of physical GPU partitions.

[0045] After determining the number of physical GPUs, the 28GB VRAM space and the 4GB VRAM space are divided equally among the configurable separate control register space (CRTC) and the physical space for connecting the display module (connector). Taking four virtual machines as an example, each virtual machine has an independent 7GB of accessible graphics context and temporary data storage, as well as 1GB of separate control register space (CRTC) and space for connecting the display module (connector).

[0046] S14. Establish the mapping relationship between virtual addresses and physical addresses through the MMIO page table.

[0047] To ensure the isolation and security of upper-layer virtual machine access and avoid direct access to the physical address space, a mapping relationship between virtual addresses and physical addresses is established through the MMIO page table. The virtual space seen and accessed by the upper-layer virtual machine is mapped to the actual physical address through the MMIO page table. The establishment and maintenance of the MMIO page table is implemented by the native graphics card driver in the host operating system (HostOS). Whenever the host OS obtains the virtual address space that the virtual machine needs to access, it maps it to the actual physical address based on the already allocated physical space and the MMIO page table.

[0048] When a physical GPU, as an independent PCIe (Peripheral Component Interconnect Express) device, performs I / O transfers and communication with the host OS, multiple PCIe devices can be virtualized using SR-IOV technology. Each device occupies independent resources such as dedicated video memory, controller, and connectivity. In other words, from the perspective of the host OS, which provides a pass-through layer, the GPU device is no longer just one, but rather multiple GPU units are connected simultaneously. Each GPU unit is called a VF (Virtual Function).

[0049] Implementing the SR-IOV partitioning method for GPUs first requires technical support during hardware design, primarily ensuring that the hardware can implement separate PF (Physical Function) and Virtual Function (VF) partitions. The upper-layer user operating system (Guest OS) mainly accesses the PF and its associated Virtual Function (VF) through I / O.

[0050] The PF accessed by the upper-layer Host OS contains all the PCI functions of the GPU, and can directly discover, manage, and process all its storage space and processing units. It also has full configuration resources and can be used to configure or control other partitioned VF devices. As a lightweight PCIe functional unit, the VF contains some of the GPU's physical functions and can share partitioned physical resources with its associated PF. That is, the VF contains all the memory addresses of the partitioned video memory, control unit, and connector.

[0051] SR-IOV technology enables the creation of PF and VF modules through configuration register movement. First, the number of VF modules to be dynamically partitioned is determined based on the number of upper-layer virtual machines; therefore, repartitioning is required when the number of upper-layer virtual machines changes. The number of VFs allocated is determined by designing the CX_MAX_VF_N parameter in the PF module. Furthermore, writing to the PF's InitialVFs register allows for changes to VF allocation upon reset, thus reaffirming that the VF management register is programmable. The written CX_MAX_VF_N ensures that the InitialVFs register is initialized to enable SR-IOV capabilities.

[0052] Initializing GPU virtualization configuration primarily involves storing the aforementioned configurations through display firmware such as vBIOS or UEFI. First, the local CPU, i.e., the host, overrides the default values ​​of the terminal's internal SR-IOV registers via the local bus controller through the data bus interface. The remote high-privilege port first discovers the physical GPU's Power Function (PF), reads its SR-IOV function registers, and configures and enables its multiple Virtual Functions (VFs) modules, achieving port-VF matching. After matching the VF function modules, the remote high-privilege port completes the allocation of individual resources such as video memory, control units, and connectors through the configuration of the PF and VF Bars. Finally, the remote high-privilege port writes to the message signal interrupt tables of the PF and VFs and enables internal message signal interrupts. Through this process, the GPU's SR-IOV configuration is completed.

[0053] Unlike SR-IOV network card virtualization, which only requires consideration of I / O port virtualization during design and use (i.e., decomposing the original single I / O port to achieve multi-path I / O virtual communication), GPU virtualization using SR-IOV technology requires the physical GPU to be allocated independent resources. The external functions include independent access to video memory, controller, and connectivity modules. Furthermore, after network card virtualization, upper-layer user software only needs to access different virtualized spaces through different address spaces. For GPU virtualization, the upper-layer user layer or operating system primarily uses configured identifiers to differentiate between virtualized graphics cards. These identifiers are set by the hardware during partitioning and made visible to the upper layer when the device is loaded. Multiple virtualizations accessing fixed hardware resources need to carry a specific identifier.

[0054] After the virtualization partitioning described above, the virtualized hardware GPUs are directly connected to the Host OS via the same PCI Express cable. The Host OS accesses different virtualized GPUs primarily through GPU hardware information carrying identifiers. For shared resources, such as computing power and video encoding / decoding, the hardware provides them to different virtualized GPUs for round-robin scheduling based on the identifiers.

[0055] Step S2: Install the virtual graphics card driver in the user-level virtual machine.

[0056] When multiple virtual machines access the same physical GPU, a separate virtual graphics driver needs to be installed on the Guest OS. The virtual graphics driver contains the same API interface functions as the graphics libraries OpenGL, OpenCL, and Vulcan. The virtual graphics driver intercepts and redirects requests from upper-layer graphics middleware, such as QT, OSG, and Mini GUI, to the underlying graphics libraries. The specific process is as follows:

[0057] S21. Configure the virtual machine to non-transparent transmission mode.

[0058] For user-level virtual machines, to ensure security, all configured virtual machines are in non-transparent mode, preventing application API requests from accessing the physical GPU. In non-transparent mode, the virtual graphics card driver, as kernel device driver code, is responsible for hardware-software interaction, enabling communication between the Guest OS and the graphics device.

[0059] S22. Set the virtual machine on the Hypervisor layer and set the virtual machine number, where the virtual machine with number 0 is the Host OS with the highest privilege level.

[0060] Before installing the virtual graphics card driver, set the virtual machine to the Hypervisor layer and assign it a virtual machine number. The virtual machine with the number 0, which is the Host OS with the highest privilege level, is responsible for managing other virtual machines and is directly connected to the hardware GPU.

[0061] S23. When installing the virtual graphics card driver, each user-level virtual machine with a number greater than 0 stores a separate virtual machine identifier and records the address space allocated to it and mapped through the MMIO page table; the virtual graphics card driver provides the standard graphics library OpenGL graphics library API functions to the upper-layer application, and the virtual graphics card driver is used to intercept and forward the API requests of the user-level virtual machine.

[0062] The main functions of a virtual graphics card driver include: virtualizing a graphics device for the Guest OS to recognize, and initializing the identification, resource mapping, and corresponding settings of the graphics device during the initialization phase, such as finding the device, accessing the device's configuration space, and implementing interrupt control. It also assists in completing the mapping of graphics device hardware resources to system resource space, and serves as a transmission channel for relevant data and commands when using virtualization for graphics processing.

[0063] Step S3: Establish a communication and transmission mechanism between the Host OS in the Hypervisor layer and the virtual machine in the user layer.

[0064] The hypervisor layer, acting as an intermediary software layer running between the underlying physical GPU and the upper-level virtual machines, coordinates how the upper-level virtual machines access unified physical resources. A Virtio device is established within the hypervisor layer to simulate an independent graphics card. On one hand, it transmits API requests from the virtual machine to the graphics library or scientific computing to the host OS; on the other hand, it transmits the results processed by the GPU back to the corresponding virtual machine through the hypervisor layer.

[0065] All virtual machines are installed on the Hypervisor layer. A Hypervisor is a software layer that runs between the hardware and the virtual machine operating software. Common Hypervisor programs include Xen, VMware, and KVM. This embodiment uses KVM as the Hypervisor, which provides functions such as memory management, storage and guest image formatting, migration implementation, device drivers, and scalability performance.

[0066] Specifically, the process is as follows:

[0067] S31. Automatically create a one-to-one correspondence between Virtio virtual devices and virtual machines in the Hypervisor layer. The front-end driver of the Virtio virtual device is provided by the virtual graphics card driver, and the back-end driver is only used to receive information transmitted from the front-end driver and forward it to the Host OS.

[0068] KVM's Hypervisor layer automatically creates Virtio virtual devices, simulating an independent PCI device that corresponds one-to-one with the virtual machine. The front-end driver of the Virtio virtual device is provided by the virtual graphics card driver, while the back-end driver is only used to receive information transmitted from the front-end driver and forward it to the Host OS. This can be implemented in the Hypervisor virtual machine management system.

[0069] S32. The backend driver sets up a circular queue, VirtQueue, to facilitate data exchange between the Host OS and the virtual machine.

[0070] A communication mechanism is established between the Guest OS and Host OS at the Hypervisor layer of the virtual machine management system. This mechanism avoids traditional socket communication, which requires repeated authentication and consumes significant system resources. Instead, it uses a Virtio channel based on a circular queue for message passing. Virtio, as a virtual I / O interface driver, simulates a PCI device for the virtual machine by creating a Virtio virtual device. A VirtQueue based circular queue is used to exchange data between the Host OS and the virtual machine, reducing the frequency of data copying between the host and the virtual machine.

[0071] After the virtual machine starts, the Hypervisor layer creates a Virtio device visible to the virtual machine. The virtual graphics card driver communicates with the Virtio device in the Hypervisor layer, and the Virtio device in the Hypervisor layer transfers data to the Host OS. This completes the I / O task between the virtual machine and the Host OS.

[0072] Step S4: After the user-level virtual machine initiates an API request, it is transmitted to the Host OS through the Hypervisor layer. The Host OS processes the requests in order according to the event priority and timestamp. Each virtual machine can only access its corresponding independent resources, ensuring resource isolation and security during use.

[0073] The Host OS centrally processes API requests transmitted through the Hypervisor layer. Based on the established mapping between independent resources and virtual machines after physical layer partitioning, resource isolation and security are ensured during use. Before transmission, graphics library API requests transmitted from multiple virtual machines are marked with event priority and timestamps, which determine the order in which the Host OS centrally processes them. Each virtual machine can only access independent physical resources partitioned by SR-IOV, ensuring resource isolation.

[0074] The specific process for this step is as follows:

[0075] S41. The user layer program used for display or graphics rendering first calls the graphics middleware. The graphics middleware decomposes the display or graphics rendering task into basic graphics drawing requirements, and then calls the underlying standard graphics library OpenGL to generate API requests for basic graphics drawing.

[0076] After the virtual machine is configured in the KVM hypervisor layer and the virtual graphics card driver is installed, user-level programs used for display or graphics rendering will first call graphics middleware, such as QT or OSG. The graphics middleware's display or graphics rendering tasks are broken down into basic graphics drawing requirements, and then the underlying standard graphics library OpenGL is called for drawing. Because the virtual graphics card driver contains the same API interfaces as the standard graphics library, it receives the basic graphics drawing requirement APIs from the upper-layer applications.

[0077] When the virtual machine calls the virtual graphics card driver, the virtual graphics card driver provides the OpenGL graphics library API to the upper-layer application. Typically, the graphics card driver provides both the graphics library API and the graphics library API driver to the upper-layer application. In the virtualization design of this invention, the actual graphics drawing and rendering process is implemented solely by the Host OS. Therefore, the virtual machine Guest OS does not design its own graphics library API driver; it only intercepts and forwards the upper-layer application's calls to the graphics library API to the Host OS.

[0078] The virtual graphics card driver provides the OpenGL graphics library API functions to the upper layers. These functions can be used to specify objects and operations to create interactive 3D applications. The OpenGL graphics library API mainly includes object management, state management, texture mapping, vertex operations, shading language compiler, and fragment operations. Object management allows applications to explicitly store data in video memory; vertex operations are responsible for setting vertex attributes and initiating graphics rendering; texture mapping is responsible for 3D texture mapping; the shading language compiler function interface is responsible for scheduling the OpenGL shading language compiler to complete the compilation of shaders; state management is responsible for maintaining the state of the OpenGL context; and fragment operations are responsible for performing alpha blending, depth testing, and stencil testing on fragments.

[0079] S42. The virtual graphics card driver of the user-level virtual machine is the same as the current API request. After receiving the API request, the API interface records the function parameters based on the drawing task and event priority, the API call order and timestamp, the configured virtualized GPU identifier, and the software status information.

[0080] The virtual graphics card driver intercepts and forwards user-level function calls to the graphics library API. It is necessary to organize the relevant configuration parameters and information of the function calls, package them, and send them to the host OS in a unified manner to ensure that the host OS can centrally process API requests from multiple virtual machine systems.

[0081] The configuration parameters and information that the virtual graphics card driver intercepts API requests and provides to the host OS include the following:

[0082] (1) Function parameters with defined semantics. By parsing the function parameters of API requests, the host OS can obtain the semantics of the function, the target address it contains, and the type and structure of the data. These clearly defined function parameters of API requests ensure that the host OS can take the correct execution measures for API requests.

[0083] (2) API request data stream with API call order and timestamps. In multi-user mode, the calling and execution order of virtual machine user-level API requests needs to be explicitly specified, and different APIs have inter-calling relationships. In addition, timestamps can ensure that the host OS executes in the correct execution order, thereby ensuring the integrity and correctness of the results.

[0084] (3) Store state information of GPU hardware, drivers, and user libraries. During the execution of an API request and driver, it is necessary to save and exchange state information of GPU hardware, drivers, and user libraries. This includes cache, memory, kernel mesh, kernel threads, modules and functions, texture operations, context, streams and events, etc.

[0085] S43. After the information recorded by the virtual graphics card driver is packaged into the API request, it is transmitted to the backend driver of the Hypervisor layer through the Virtio virtual device created by the Hypervisor layer.

[0086] The backend driver of the S44 and Hypervisor layers transmits all API requests from user virtual machines sequentially to the Host OS, numbered 0, via a circular queue called VirtQueue.

[0087] S45 and Host OS create multiple independent transmission channels to receive and parse API requests, process them according to high priority, and process them in the order of timestamps for the same priority, and call the native graphics card driver to access the physical GPU in a thread-based manner.

[0088] The parsing process mainly includes: on the one hand, sorting based on timestamps and priorities, and processing the virtual machine's API requests in sequence; on the other hand, determining the specific graphics drawing task in the API request, calling the virtualization hardware with the same identifier for processing, and the relevant independent video memory resources can also be used to preserve the graphics context.

[0089] The host operating system (OS) processes graphics rendering API requests from different virtual machines primarily by sorting them using the timestamps sent by the virtual graphics card drivers on the virtual machines when they are received. In addition, for extremely important tasks, such as urgent or long-running events, they are marked with high priority and processed first through preemption or other methods.

[0090] The host operating system (Host OS) manages the native graphics card driver, including device drivers, graphics library drivers, hardware initialization, and hardware / software management functions. Since the Host OS communicates directly with the actual physical GPU, it needs to periodically report the hardware GPU status and driver information to the Guest OS to ensure state synchronization between the two operating systems.

[0091] After the host operating system parses the API requests for virtual machine graphics drawing or rendering, it calls the native graphics card driver in a thread to access the physical GPU and complete the relevant functions.

[0092] S46. The physical GPU processes various API requests transmitted from the Host OS, and the processing results are transmitted back to the Host OS as return values. The Host OS then transmits them to the corresponding virtual machine through the Hypervisor layer's circular queue, VirtQueue.

[0093] The physical GPU processes various API requests from the host OS, such as 2D / 3D graphics rendering, graphics drawing, and scientific computing. The processing results are returned to the host OS as return values, and then the host OS transmits them to the corresponding virtual machine through the Hypervisor layer's VirtQueue.

[0094] In summary, this invention provides a GPU virtualization implementation method based on SR-IOV technology. The virtualization system implementation is designed in layers: a user layer, a hypervisor layer, a host OS, and a physical GPU hardware layer. At the hardware layer, a physical module is designed based on SR-IOV technology to partition independent resources such as video memory, controllers, and connection modules, and to implement time-sharing scheduling of shared resources such as computing power and video encoding / decoding. At the user layer, a virtual graphics card driver is installed in the user-level virtual machine, and API requests from the virtual machine to the graphics library or scientific computing are intercepted and redirected. At the hypervisor layer, on the one hand, API requests from the virtual machine to the graphics library or scientific computing are transmitted to the host OS; on the other hand, the results processed by the GPU are transmitted to the corresponding virtual machine through the hypervisor layer. In the host OS, API requests transmitted through the hypervisor layer are centrally processed, and a mapping relationship between the independent resources partitioned in the physical layer and the virtual machines is established, ensuring resource isolation and security during use.

[0095] The layered design ensures security during use and maintainability in the future. When configuring a new virtual machine, a communication relationship is established with the Host OS through the Hypervisor layer, and the independent resources of the physical GPU are re-allocated. A virtual graphics card driver is installed in the virtual machine. Based on this, API requests for standard graphics libraries or scientific computing applications can be transmitted to the Host OS through the virtual graphics card driver. The Host OS directly accesses the physical GPU, storing API requests from individual virtual machines within the re-allocated physical GPU, achieving context isolation and frame buffering. The physical GPU performs time-sharing scheduling of computing and video encoding / decoding resources for different API requests, and the computation results are transmitted to the corresponding virtual machine system through the Host OS. This invention maximizes GPU resource utilization, reduces CPU system load, and ensures security under resource isolation.

[0096] The above description is only a preferred embodiment of the present invention and is not intended to limit the present invention. Any modifications, equivalent substitutions, and improvements made within the spirit and principles of the present invention should be included within the protection scope of the present invention.

Claims

1. A GPU virtualization implementation method based on SR-IOV technology, characterized in that, The method includes the following steps: Step S1: Divide the independent resources of the physical GPU using SR-IOV technology; Step S2: Install the virtual graphics card driver in the user-level virtual machine; Step S3: Establish a communication and transmission mechanism between the Host OS in the Hypervisor layer and the virtual machine in the user layer; Step S4: After the user-level virtual machine initiates an API request, it is transmitted to the Host OS through the Hypervisor layer. The Host OS processes the requests in order according to the event priority and timestamp. Each virtual machine can only access its corresponding independent resources, ensuring resource isolation and security during use. The specific process of step S1 is as follows: S11. Based on the configured number of virtual machines, determine the number of physical GPU partitions, which is fixed to an even number. If the number of virtual machines is odd, the number of physical GPU partitions is the number of virtual machines plus 1. S12. Divide the address space within the physical GPU into a first space and a second space. The first space is used for the configurable control register space, connecting the display module and the non-configurable computing power and video encoding / decoding scheduling unit. The second space is used to provide access to the upper-layer graphics controller, as well as to save the graphics context and store temporary data. S13. Divide the first space and the second space equally according to the number of physical GPU partitions; S14. Establish the mapping relationship between virtual addresses and physical addresses through the MMIO page table; The specific process of step S4 is as follows: S41. The user layer program used for display or graphics rendering first calls the graphics middleware. The graphics middleware decomposes the display or graphics rendering task into basic graphics drawing requirements, and then calls the underlying standard graphics library OpenGL to generate API requests for basic graphics drawing. S42. After receiving the API request, the API interface in the virtual graphics card driver of the user-level virtual machine, which is the same as the current API request, records the function parameters with defined drawing task and event priority, the API call order and timestamp, the configured virtualized GPU identifier, and software status information. S43. After the information recorded by the virtual graphics card driver is packaged into the API request, it is transmitted to the backend driver of the Hypervisor layer through the Virtio virtual device created by the Hypervisor layer. The backend driver of the S44 Hypervisor layer transmits all API requests from user virtual machines sequentially to the Host OS numbered 0 through a circular queue VirtQueue. S45 and Host OS create multiple independent transmission channels to receive and parse API requests, process them according to high priority, process them according to timestamp order for the same priority, and call the native graphics card driver to access the physical GPU in a thread manner. S46. The physical GPU processes various API requests transmitted from the Host OS, and the processing results are transmitted back to the Host OS as return values. The Host OS then transmits them to the corresponding virtual machines through the Hypervisor layer's circular queue, VirtQueue.

2. The method of claim 1, wherein the method further comprises: The specific process of step S2 is as follows: S21. Configure the virtual machine to non-transparent transmission mode; S22. Set the virtual machine on the Hypervisor layer and set the virtual machine number, where the virtual machine with number 0 is the Host OS with the highest privilege level; S23. When installing the virtual graphics card driver, each user-level virtual machine with a number greater than 0 stores a separate virtual machine identifier and records the address space allocated to it and mapped through the MMIO page table; the virtual graphics card driver provides the standard graphics library OpenGL graphics library API functions to the upper-layer application, and the virtual graphics card driver is used to intercept and forward the API requests of the user-level virtual machine.

3. The method of claim 2, wherein the method further comprises: The specific process of step S3 is as follows: S31. Automatically create a one-to-one correspondence between Virtio virtual devices and virtual machines in the Hypervisor layer. The front-end driver of the Virtio virtual device is provided by the virtual graphics card driver, and the back-end driver is only used to receive information transmitted from the front-end driver and forward it to the Host OS. S32. The backend driver sets up a circular queue, VirtQueue, to facilitate data exchange between the Host OS and the virtual machine.

Images