Video memory virtual access method and device of GPU model and computer equipment

Abstract

The invention relates to a video memory virtual access method and device of a GPU model and computer equipment. The method comprises the following steps: receiving an access request initiated by a CPU (Central Processing Unit) in the virtual machine, wherein the access request comprises indication information of a target base address register; based on the indication information and a preset association relationship, routing the access request to a target address range in a simulated physical address space; wherein the preset association relationship comprises a corresponding relationship between an address range in a simulated physical address space and a base address register of the GPU model, and a mapping relationship between the address range in the simulated physical address space and a host memory allocated for a video memory area of the GPU model; the GPU model is a software module for simulating a physical GPU in a virtual environment. By adopting the method, the access speed can be improved.

Description

Technical Field

[0001] This application relates to the field of GPU model memory access mechanism optimization technology, and in particular to a GPU model memory virtual access method, apparatus and computer device. Background Technology

[0002] In virtualization scenarios, to achieve virtual simulation of GPU models to support driver development, instruction debugging, and other needs, the Quick Emulator (QEMU) virtual platform has become the mainstream implementation carrier. Currently, access to the GPU model's video memory space by the Central Processing Unit (CPU) within the virtual machine is generally achieved through Memory-Mapped I / O (MMIO). Specifically, QEMU registers a dedicated structure for the GPU's Base Address Register (BAR) space, defines read / write callback functions in code to respond to CPU access, and then initializes the memory region and completes the BAR space registration. Under this mechanism, CPU access to the GPU model's video memory is intercepted by QEMU, which then calls back the read / write callback functions, allowing the simulation logic to indirectly complete the video memory read / write.

[0003] However, in this MMIO access method, each MMIO operation is limited to a fixed transfer size (such as 64 bits), and the access needs to go through a multi-level call path of CPU, QEMU, simulated device logic, and simulated video memory. As a result, when the CPU needs to perform large-scale data access or consistency verification on the video memory of the GPU model, the access speed is extremely slow, the performance of the virtual platform is severely limited, and it is difficult to meet the high-frequency access requirements. Summary of the Invention

[0004] Therefore, it is necessary to provide a method, apparatus, and computer device for virtual accessing GPU memory that can improve access speed, addressing the aforementioned technical problems.

[0005] Firstly, this application provides a method for virtual memory access in a GPU model, including:

[0006] Receive an access request initiated by the CPU in the virtual machine, the access request including: indication information of the target base address register;

[0007] Based on the indicated information and the preset association, the access request is routed to the target address range in the simulated physical address space;

[0008] The preset association relationship includes: the correspondence between the address range in the simulated physical address space and the base address register of the GPU model, and the mapping relationship between the address range in the simulated physical address space and the host memory allocated to the video memory area of ​​the GPU model, wherein the GPU model is a software module that simulates a physical GPU in a virtualization environment.

[0009] In one embodiment, the process of establishing the preset association includes:

[0010] Allocate corresponding host memory to the video memory area of ​​the GPU model. The host memory is obtained by creating shared memory or by calling a dynamic memory allocation function within the virtualization platform. The virtualization platform is built on the host machine and provides a runtime environment for the virtual machine to handle the CPU access requests of the virtual machine and support the software architecture for running the GPU model.

[0011] The host machine memory is mapped to a simulated physical address space to determine the mapping relationship;

[0012] Establish the correspondence between the address range in the simulated physical address space and the base address register of the GPU model.

[0013] In one embodiment, mapping the host machine memory to a simulated physical address space to determine the mapping relationship includes:

[0014] Obtain the file descriptor of the shared memory;

[0015] The memory region initialization interface provided by the virtualization platform is invoked to map the shared memory corresponding to the file descriptor to the simulated physical address space, thereby determining the mapping relationship.

[0016] In one embodiment, mapping the host machine memory to a simulated physical address space to determine the mapping relationship includes:

[0017] Obtain the pointer to the memory allocated by the dynamic memory allocation function;

[0018] The virtualization platform's memory region initialization interface is invoked to map the host memory corresponding to the memory pointer to the simulated physical address space, thereby determining the mapping relationship.

[0019] In one embodiment, the method further includes:

[0020] If a cross-process communication requirement based on an inter-process communication interface is detected, and the cross-process communication requirement needs to be transferred through the GPU model's video memory area, the host memory is obtained by creating shared memory.

[0021] The inter-process communication requirements of the inter-process communication interface include: communication requirements between the virtual machine and the host machine, and / or, communication requirements between multiple virtual machines.

[0022] In one embodiment, the method further includes:

[0023] In the absence of detected cross-process communication requirements based on inter-process communication interfaces, the host machine memory is obtained by calling dynamic memory allocation functions within the virtualization platform;

[0024] The inter-process communication requirements of the inter-process communication interface include: communication requirements between the virtual machine and the host machine, and / or, communication requirements between multiple virtual machines.

[0025] In one embodiment, routing the access request to a target address range in the simulated physical address space based on the indication information and a preset association includes:

[0026] Based on the indication information of the target base address register and the corresponding relationship, a candidate address range in the simulated physical address space corresponding to the target base address register is obtained;

[0027] If, based on the mapping relationship, it is confirmed that there is a mapping relationship between the candidate address range and the host memory allocated to the video memory region of the GPU model, the candidate address range is determined as the target address range;

[0028] The address field of the access request is converted to an address within the target address range to complete the routing of the access request.

[0029] Secondly, this application also provides a virtual memory access device for a GPU model, comprising:

[0030] The receiving module is used to receive access requests initiated by the CPU in the virtual machine, wherein the access request includes: indication information of the target base address register;

[0031] The routing module is used to route the access request to a target address range in the simulated physical address space based on the indication information and the preset association relationship.

[0032] The preset association relationship includes: the correspondence between the address range in the simulated physical address space and the base address register of the GPU model, and the mapping relationship between the address range in the simulated physical address space and the host memory allocated to the video memory area of ​​the GPU model, wherein the GPU model is a software module that simulates a physical GPU in a virtualization environment.

[0033] Thirdly, this application also provides a computer device, including a memory and a processor, wherein the memory stores a computer program, and the processor executes the computer program to implement the method as described in the first aspect or any embodiment thereof.

[0034] Fourthly, this application also provides a computer-readable storage medium having a computer program stored thereon, which, when executed by a processor, implements the method as described in the first aspect or any embodiment thereof.

[0035] Fifthly, this application also provides a computer program product, including a computer program that, when executed by a processor, implements the method described in the first aspect or any embodiment thereof.

[0036] The aforementioned GPU model's virtual memory access method, apparatus, and computer device receive an access request initiated by the CPU in the virtual machine. The access request includes: indication information of the target base address register; based on the indication information and a preset association relationship, the access request is routed to a target address range in the simulated physical address space; wherein, the preset association relationship includes: the correspondence between the address range in the simulated physical address space and the base address register of the GPU model, and the mapping relationship between the address range in the simulated physical address space and the host memory allocated for the GPU model's video memory region, and the GPU model is a software module that simulates a physical GPU in a virtualization environment. This scheme establishes a dual pre-defined association between the address range of the simulated physical address space and the GPU model's base address register and the host machine's memory. Upon receiving an access request from the virtual machine's CPU, the target base address register information in the request is used to directly route the access request to the corresponding target address range in the simulated physical address space. This skips the redundant steps of multi-layer address translation and request forwarding that may exist in traditional GPU model memory access. At the same time, the fixed association ensures that the request's routing path is clearly fixed, avoiding the latency caused by dynamic address resolution and reducing the communication overhead of address interaction between the virtual machine and the host machine. Ultimately, this improves the speed of virtual access to GPU model memory, allowing applications in the virtual machine that rely on GPU model memory to achieve more efficient data read and write response, avoiding severe performance limitations of the virtual platform, and meeting high-frequency access requirements. Attached Figure Description

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

[0038] Figure 1 This is a flowchart illustrating the virtual memory access method of a GPU model in one embodiment;

[0039] Figure 2 This is a flowchart illustrating one method for determining a mapping relationship in one embodiment;

[0040] Figure 3 This is a flowchart illustrating another method for determining mapping relationships in one embodiment;

[0041] Figure 4 This is a block diagram of the virtual memory access device of a GPU model in one embodiment;

[0042] Figure 5 This is an internal structural diagram of a computer device in one embodiment. Detailed Implementation

[0043] To make the objectives, technical solutions, and advantages of this application clearer, the following detailed description is provided in conjunction with the accompanying drawings and embodiments. It should be understood that the specific embodiments described herein are merely illustrative and not intended to limit the scope of this application.

[0044] Currently, to achieve virtual simulation of GPU models to support driver development, instruction debugging, and other needs, the Quick Emulator (QEMU) virtual platform has become the mainstream implementation carrier. The access of the GPU model's video memory space by the Central Processing Unit (CPU) within the virtual machine can be achieved through Memory-Mapped I / O (MMIO). Specifically, QEMU registers a dedicated structure for the GPU's Base Address Register (BAR) space, defines read / write callback functions in the code to respond to CPU access, and then initializes the memory region and completes the BAR space registration. Under this mechanism, CPU access to the GPU model's video memory is intercepted by QEMU, which then calls back the read / write callback functions, allowing the simulation logic to indirectly complete the video memory read / write. However, in this MMIO access method, each MMIO operation is limited to a fixed transfer size (such as 64 bits), and the access needs to go through a multi-level call path of CPU, QEMU, simulated device logic, and simulated video memory. As a result, when the CPU needs to perform large-scale data access or consistency verification on the video memory of the GPU model, the access speed is extremely slow, the performance of the virtual platform is severely limited, and it is difficult to meet the high-frequency access requirements.

[0045] To address the aforementioned issues, this application provides a method for virtual access to GPU model memory. This method can improve the speed of virtual access to GPU model memory, enabling applications in the virtual machine that rely on GPU model memory to achieve more efficient data read / write response, avoiding severe performance limitations of the virtual platform, and meeting high-frequency access requirements.

[0046] The GPU model's virtual memory access method provided in this application can be executed by a GPU model's virtual memory access device or a computer device. The GPU model's virtual memory access device can be a functional module or entity within the computer device used to implement the GPU model's virtual memory access method. The computer device can be a host machine. The GPU model's virtual memory access method can be implemented on the host machine within a virtualization environment based on a virtualization platform.

[0047] In this embodiment, the GPU model is a software module that simulates a physical GPU in a virtualized environment. The virtualization platform is a software architecture built on the host machine that provides a runtime environment for the virtual machine, handles the CPU access requests of the virtual machine, and supports the operation of the GPU model. This virtualization platform can be the QEMU virtualization platform.

[0048] It should be noted that the virtualization platform in this application embodiment is not limited to the QEMU virtual platform. Any virtualization platform with physical resource abstraction, simulated address space management, device model virtualization, memory mapping and request routing capabilities is applicable to the GPU model video memory virtual access method of this application.

[0049] For example, the open-source virtualization platform KVM (Kernel-based Virtual Machine), as a virtualization module based on the Linux kernel, can be used in conjunction with QEMU (QEMU is responsible for device emulation, and KVM is responsible for CPU virtualization acceleration). The memory mapping and address routing logic of this application can be directly deployed in the KVM-QEMU architecture. At the same time, in a pure KVM environment, by combining some virtualization device frameworks, the same memory access optimization effect can also be achieved by registering the BAR address space of the GPU model and establishing the mapping relationship between the simulated address and the host memory.

[0050] In one exemplary embodiment, such as Figure 1 As shown, a method for virtual memory access in a GPU model is provided. Taking the application of this method to a host machine as an example, the method includes the following steps 101 and 102. Wherein:

[0051] 101. Receive access requests initiated by the CPU in the virtual machine.

[0052] The aforementioned access request includes: indication information of the target base address register (BAR), which refers to the identification information used to identify the target BAR, such as: BAR index, register number, etc. This identification information of the target BAR can help the host machine to determine the target base address register that the virtual machine CPU wants to access.

[0053] In this embodiment, the host machine refers to the physical computer running virtualization software (such as QEMU). It is the core execution carrier of the entire virtual access scheme, responsible for allocating actual memory resources, establishing address mapping relationships, and processing virtual machine access requests. The host machine possesses real hardware resources (CPU, memory, storage, etc.) and provides a running environment for the virtual machine.

[0054] In this embodiment, a virtual machine refers to a virtual computer simulated on a host machine using virtualization technology, possessing an independent operating system and virtual hardware. The CPU in a virtual machine is not a real physical CPU; its access requests must be processed by the virtualization layer of the host machine before they can be mapped to real hardware resources or resources allocated by the host machine.

[0055] In the implementation of step 101 above, firstly, when the CPU in the virtual machine runs GPU-related applications (such as drivers and graphics rendering tasks), it needs to access the GPU model's video memory to read or write data, generating a corresponding access request (read request or write request). Secondly, since the CPU is in a virtual environment, its access request is intercepted by the Peripheral Component Interconnect Express (PCIe) bus emulation module of the QEMU virtual platform. Finally, QEMU forwards the intercepted access request to a module in the host machine that specifically handles GPU model video memory access (such as the GPU model's memory management module). This module receives the access request and parses the target base address register indication information contained in the request, preparing for subsequent address routing. Throughout this process, the virtual machine CPU does not need to be aware of the host machine's real hardware environment; it only needs to initiate requests according to the GPU model's address specifications.

[0056] The PCIe bus is the standard bus for communication between the CPU and peripherals such as the GPU, and it is simulated by QEMU in the virtualization environment.

[0057] 102. Based on the instruction information and the preset association, the access request is routed to the target address range in the simulated physical address space.

[0058] The preset associations include: the correspondence between the address range in the simulated physical address space and the base address register of the GPU model, and the mapping between the address range in the simulated physical address space and the host memory allocated to the video memory area of ​​the GPU model.

[0059] The aforementioned simulated physical address space can be a physical address space simulated in the host machine's memory by virtualization software (QEMU). This simulated physical address space is used to shield the virtual machine from the real host machine's physical addresses. The physical addresses accessed by the CPU in the virtual machine are actually addresses in this simulated space. The host machine translates these addresses into real host machine memory addresses through address mapping, thereby achieving virtualization isolation and resource management.

[0060] The aforementioned preset association can be a set of two sets of mapping rules pre-established by the host machine. Its core function is to establish a link between virtual machine CPU access requests and the actual memory resources of the host machine. One set is the correspondence between the simulated physical address space address range and the GPU model BAR, which is used to locate the simulated address range according to the BAR indication information; the other set is the mapping relationship between the simulated physical address space address range and the host machine memory, which is used to convert the simulated address into a real memory address.

[0061] Shared memory is a memory region created by the host machine that can be accessed by multiple processes. Memory mapping technology allows different processes to directly access the same memory block, avoiding data copying and improving access efficiency. In this embodiment, shared memory can be a memory region accessed by both the QEMU process and the GPU model process.

[0062] The QEMU virtual platform mentioned above is an open-source virtualization software that can emulate various hardware architectures and devices (such as CPU, GPU, PCIe bus, etc.) and is the core tool for realizing virtual machine operation and address virtualization.

[0063] The aforementioned dynamic memory allocation function refers to a function that dynamically requests memory during program execution (such as the dynamic memory allocation function in C language). Here, it is used to directly allocate host memory to the GPU model's video memory area within the QEMU virtual platform, without the need to create a shared memory file, thus achieving fast memory allocation and reclamation.

[0064] In the implementation of step 102 above, request location and address routing can be completed through a preset association relationship. First, the host processing module extracts the target base address register (BAR) indication information from the access request received in step 101. Based on this indication information, it queries the first set of correspondences in the preset association relationship (simulated physical address space address range - GPU model BAR) to determine the simulated physical address space address range corresponding to the target BAR, i.e., the target address range. Second, the received access request (including read / write operation type, data length, etc.) is routed to this target address range, completing the binding of the request with the simulated address, laying the foundation for subsequent access to the real host memory. It should be noted that this step only completes the routing of the access request to the simulated physical address space and does not yet involve reading and writing to the real host memory. The purpose is to quickly locate the target address through the preset association relationship, avoiding the multi-layer function callbacks in the traditional MMIO method and improving request processing efficiency.

[0065] In some embodiments, the legality of the target address range can be verified before routing the received access request (including information such as read / write operation type and data length) to the target address range to avoid unauthorized access.

[0066] For example, when verifying the legality of a target address range, it can be verified whether the target address range is within the allocated GPU memory address range, and / or whether there is access permission for the target address range, etc.

[0067] The aforementioned GPU model's virtual memory access method establishes a dual pre-defined association between the address range of the simulated physical address space and the GPU model's base address register and the host machine's memory. Upon receiving an access request from the virtual machine's CPU, it directly routes the access request to the corresponding target address range in the simulated physical address space using the target base address register indication information in the request. This skips the redundant steps of multi-layer address translation and request forwarding that may exist in traditional GPU model memory access. At the same time, the fixed association ensures that the request's routing path is clearly fixed, avoiding the latency caused by dynamic address resolution and reducing the communication overhead of address interaction between the virtual machine and the host machine. Ultimately, this improves the speed of GPU model's virtual memory access, allowing applications in the virtual machine that rely on the GPU model's memory to achieve more efficient data read and write response, avoiding severe performance limitations of the virtual platform, and meeting high-frequency access requirements.

[0068] In some embodiments, the process of establishing a preset association includes: allocating corresponding host memory to the GPU model's video memory region; mapping the host memory to a simulated physical address space to determine the mapping relationship; and establishing a correspondence between the address range in the simulated physical address space and the base address register of the GPU model. The host memory is obtained by creating shared memory, or by calling a dynamic memory allocation function within the virtualization platform.

[0069] First, the host machine can allocate memory resources for the GPU model's video memory region in two ways. One is by creating shared memory allocation. Specifically, the host machine can call the operating system's shared memory creation interface to create a shared memory region of a specified size and obtain the file descriptor for that region. The second is through QEMU's internal dynamic memory allocation functions. Specifically, when the virtualization platform initializes the GPU model, it calls dynamic memory allocation functions such as malloc to directly request a contiguous memory region in the host machine's memory as the GPU model's video memory buffer and obtain the starting pointer of that memory region. This video memory buffer is part of the host machine's physical memory, and its address space belongs to the host machine's memory address space. The GPU model's read and write operations on this video memory buffer are essentially accesses to the corresponding physical memory region on the host machine, and the starting pointer of that memory region is obtained. Secondly, the allocated host memory can be mapped to the simulated physical address space. If shared memory is used, the file descriptor RAM memory region initialization interface (memory_region_init_ram_from_fd() interface) provided by QEMU needs to be called to map the shared memory file descriptor to a range of addresses in the simulated physical address space. This simulated physical address range and the shared memory (i.e., a part of the host memory) form a one-to-one mapping relationship. Accessing this simulated physical address range is equivalent to accessing the corresponding shared memory region in the host memory. The mapping relationship between this address range and the shared memory is recorded. If dynamic memory allocation is used, the device pointer RAM memory region initialization interface (memory_region_init_ram_device_ptr() interface) of QEMU needs to be called to register the memory pointer allocated by malloc as a memory region in the simulated physical address space and establish the mapping relationship between the simulated address range and the memory pointer. Finally, a correspondence between the simulated physical address space address range and the GPU model BAR can be established. Specifically, the base address of the simulated physical address range obtained in the second step is written into the BAR register corresponding to the GPU model, and the mapping entry of the simulated address range corresponding to the BAR is recorded in the association table of the host machine, thus completing the establishment of the preset association.

[0070] The two host memory acquisition methods described above are chosen based on the communication requirements of the actual application scenario. Their goal is to provide a real memory carrier for the GPU model's video memory region that can be mapped to the simulated physical address space. Creating shared memory is suitable for scenarios requiring cross-process data interaction, breaking process isolation through a system-level shared memory mechanism; while QEMU's internal dynamic memory allocation is suitable for scenarios requiring only internal QEMU access, simplifying the memory allocation process.

[0071] In some embodiments, step 102 described above can be implemented by including but not limited to the following steps:

[0072] 1021. Based on the indication information and correspondence of the target base address register, the candidate address range in the simulated physical address space corresponding to the target base address register is obtained.

[0073] During the operation of the virtualization platform, the pre-stored relationship between the base address register of the GPU model and the address range in the simulated physical address space is pre-stored in the preset association. When the virtual machine CPU initiates a GPU memory access request, the target base address register indication information carried in the request is received and extracted by the address resolution module of the virtualization platform. The resolution module performs a search and matching based on the indication information, and can locate the simulated physical address space range associated with the target base address register. This range is the candidate address range.

[0074] In step 1021 above, the virtualization platform can ensure that the candidate address ranges corresponding to different base address registers do not overlap through preset address mapping rules, thereby ensuring the accuracy of subsequent access request routing.

[0075] 1022. If, based on the mapping relationship, it is confirmed that there is a mapping relationship between the candidate address range and the host memory allocated to the video memory region of the GPU model, the candidate address range shall be determined as the target address range.

[0076] After obtaining the candidate address range, the mapping relationship in the preset association relationship can be called. This mapping relationship stores the mapping relationship between the simulated physical address space range and the host machine memory region. At this time, the corresponding host machine memory entry can be queried in the mapping relationship according to the candidate address range to confirm whether the candidate address range has been bound to a valid host machine memory resource.

[0077] The entries in the above mapping relationship can be pre-written. Once the host memory entry corresponding to the candidate address range is found, it can be determined that the candidate address range has the validity of the mapping association. At this time, the candidate address range can be directly determined as the target address range for routing.

[0078] 1023. Convert the address field of the access request to an address within the target address range to complete the routing of the access request.

[0079] After determining the target address range, the original address field in the access request can be extracted. This field is the logical address inside the virtual machine. Based on the target address range, the original logical address is converted into an address within the target address range to complete the routing of the access request.

[0080] When routing the above access request, the address within the target address range after conversion can be carried in the access request, and the request can be routed to the corresponding simulated physical address space range through the memory access forwarding interface. Since this range has been bound to the host memory through a mapping relationship, the routing operation is essentially forwarding the virtual machine CPU's access request to the memory area allocated by the host for the GPU model memory, thereby completing a complete GPU memory virtual access process.

[0081] In one exemplary embodiment, such as Figure 2 The diagram illustrates a process for determining a mapping relationship when host machine memory is obtained by creating shared memory. Figure 2 Taking a virtualization platform as an example, this process includes, but is not limited to, the following steps:

[0082] 201. Obtain host machine memory by creating shared memory.

[0083] Step 201 above completes the creation of system-level shared memory, with the host operating system responsible for the allocation and management of memory resources to ensure the persistence and shareability of the memory region.

[0084] 202. Obtain the file descriptor for shared memory.

[0085] The purpose of obtaining the file descriptor in step 202 above is to establish the association between the process and the shared memory. The file descriptor serves as the unique identifier of the shared memory and is the credential for QEMU to access the shared memory subsequently.

[0086] For example, in step 202, the file descriptor can be obtained directly using shm_fd.

[0087] 203. Call the memory region initialization interface provided by the virtualization platform to map the shared memory corresponding to the file descriptor to the simulated physical address space to determine the mapping relationship.

[0088] In step 203, the mapping can be completed through the QEMU interface. Essentially, this involves incorporating the system's shared memory into QEMU's simulated address management system, thereby binding the simulated physical address to the real shared memory.

[0089] For example, shared memory can be created using the following commands: "int fd=mmap(NULL,GPU_MEM_SIZE,O_RDWR, MAP_SHARED,shm_fd,0);memory_region_init_ram_from_fd(&gpu_bar_mem,OBJECT(dev),"gpu-shmem",GPU_MEM_SIZE,fd,0)" and "pci_register_bar(dev,0, PCI_BASE_ADDRESS_SPACE_MEMORY,&gpu_bar_mem)".

[0090] The above function `int fd=mmap(NULL,GPU_MEM_SIZE,O_RDWR,MAP_SHARED, shm_fd,0)` is a memory mapping operation at the host operating system level. The `mmap` function maps the pre-created system shared memory identified by `shm_fd` into the address space of the host process. `NULL` indicates that the system automatically allocates the starting address for the mapping. `GPU_MEM_SIZE` specifies the size of the mapped memory (i.e., the capacity required for the GPU model's video memory). `O_RDWR` indicates that the memory region supports read and write operations. `MAP_SHARED` indicates that the mapped region is in shared mode (ensuring that processes such as the virtual machine, QEMU, and the GPU model can access it). The returned `fd` is the file descriptor of the mapped memory region, serving as the core credential for subsequent QEMU operations.

[0091] The above "memory_region_init_ram_from_fd(&gpu_bar_mem,OBJECT(dev),"gpu-shmem",GPU_MEM_SIZE,fd,0)" is a call to QEMU's file descriptor-based RAM memory region initialization interface. This interface registers the shared memory region corresponding to the above fd as the gpu_bar_mem memory region object inside QEMU. OBJECT(dev) specifies that the memory region is associated with the GPU model device instance. "gpu-shmem" is the name identifier of the memory region. GPU_MEM_SIZE is consistent with the previous text. The final 0 indicates that the mapping starts from the beginning of the shared memory. This step completes the access of shared memory to the QEMU simulated memory system and establishes the initial association between shared memory and simulated physical address space.

[0092] The above `pci_register_bar(dev,0,PCI_BASE_ADDRESS_SPACE_MEMORY,&gpu_bar_mem)` registers the initialized memory region as the PCIe Base Address Register (BAR) of the GPU model. Here, `dev` is the GPU model device instance, `0` indicates registration to BAR register number 0, `PCI_BASE_ADDRESS_SPACE_MEMORY` identifies the BAR type as memory space, and `&gpu_bar_mem` binds the previously registered shared memory region to this BAR. After this step, the address range corresponding to this BAR in QEMU's simulated physical address space is completely associated with the host machine's shared memory. When the virtual machine CPU accesses this BAR address, it will directly map to this shared memory, enabling high-speed access to the GPU model's video memory.

[0093] In some embodiments, when a cross-process communication requirement based on an inter-process communication interface is detected, and the cross-process communication requirement needs to be transferred through the GPU model's video memory area, the host memory is obtained by creating shared memory.

[0094] The inter-process communication requirements of the inter-process communication interface include: communication requirements between the virtual machine and the host machine, and / or, communication requirements between multiple virtual machines.

[0095] The aforementioned cross-process communication requirement requires relaying through the GPU model's memory area. This means that cross-process communication uses the GPU model's memory space as a data relay carrier. The business data to be exchanged between different processes must first be written to the designated area of ​​the GPU model's allocated memory. After the transmission is completed, the corresponding data is read from that memory area to complete the data interaction between processes. This implementation method is usually used in scenarios where data transmission efficiency is critical or where the business process itself depends on the GPU runtime environment.

[0096] In this embodiment, the virtualization management module of the host machine first listens for and detects inter-process communication needs, and determines whether the communication needs to be relayed through the GPU model's video memory. When there is cross-process communication between the virtual machine and the host machine, or between multiple virtual machines, and video memory relay is required, the shared memory method is selected because shared memory supports direct access by multiple processes, which can avoid data copying between different processes and meets the needs of efficient cross-process communication.

[0097] For example, if the GPU driver in the virtual machine needs to transfer rendering data to the GPU model on the host machine for processing, and this transfer needs to be relayed through video memory, the host machine will create shared memory as the video memory area of ​​the GPU model after detecting the cross-process communication requirement. The virtual machine and the host machine can directly read and write data through this shared memory without the need for an additional data copying process.

[0098] In one exemplary embodiment, such as Figure 3 As shown, host machine memory is addressed through a virtualization platform ( Figure 3 Taking a virtualization platform as an example, the flowchart illustrating another method for determining mapping relationships, obtained through internal calls to dynamic memory allocation functions, includes but is not limited to the following steps:

[0099] 301. Host machine memory is obtained by calling dynamic memory allocation functions within the virtualization platform.

[0100] In particular, the memory allocation in step 301 is limited to the QEMU process and is uniformly scheduled by the QEMU memory management module, resulting in higher allocation efficiency.

[0101] 302. Obtain the pointer to the memory allocated by the dynamic memory allocation function.

[0102] The memory pointer obtained in step 302 is a direct reference to the host machine's physical memory, through which the allocated memory area can be directly located.

[0103] For example, in step 302, the memory pointer corresponding to gpu_mem can be obtained directly.

[0104] 303. Call the memory region initialization interface provided by the virtualization platform to map the host memory corresponding to the memory pointer to the simulated physical address space to determine the mapping relationship.

[0105] The mapping logic in step 303 is similar to that of the shared memory method. The core difference is that the association is established through memory pointers instead of file descriptors, so as to achieve direct mapping from QEMU internal memory to simulated physical address space.

[0106] For example, host memory can be allocated using "void *gpu_mem = malloc(GPU_MEM_SIZE); memory_region_init_ram_device_ptr(&gpu_bar_mem, OBJECT(dev), "gpu-mem", GPU_MEM_SIZE, gpu_mem)" and "pci_register_bar(dev, 0, PCI_BASE_ADDRESS_SPACE_MEMORY, &gpu_bar_mem)".

[0107] The above "void *gpu_mem = malloc(GPU_MEM_SIZE)" is a dynamic memory allocation operation within the virtualization platform. The malloc function, as the core dynamic memory allocation function, allocates a contiguous physical memory region of size GPU_MEM_SIZE in the host machine's heap memory (this size is the capacity required for the GPU model's video memory) and returns a pointer gpu_mem to the beginning of this memory region. If the memory allocation is successful, gpu_mem will serve as a direct reference to the host machine's physical memory, allowing subsequent direct access to the allocated memory through this pointer without relying on intermediate credentials such as file descriptors, thus adapting to scenarios without cross-process communication requirements.

[0108] The above "memory_region_init_ram_device_ptr(&gpu_bar_mem,OBJECT(dev),"gpu-mem",GPU_MEM_SIZE,gpu_mem)" is a call to QEMU's RAM memory region initialization interface based on device memory pointers. This interface registers the host memory region pointed to by the above gpu_mem as the gpu_bar_mem memory region object inside QEMU. OBJECT(dev) specifies that the memory region is associated with the GPU model device instance. "gpu-mem" is the name identifier of the memory region. GPU_MEM_SIZE is consistent with the memory size allocated by malloc mentioned above. gpu_mem is directly associated with the host-allocated memory pointer as a core input parameter. This step completes the access of the host dynamic memory to the QEMU simulated memory system, establishes the initial association between the memory pointer and the simulated physical address space, and lays the foundation for zero-copy access.

[0109] The above `pci_register_bar(dev,0,PCI_BASE_ADDRESS_SPACE_MEMORY,&gpu_bar_mem)` registers the initialized memory region as the GPU model's PCIe Base Address Register (BAR). Here, `dev` is the GPU model device instance, `0` indicates registration to BAR register number 0, `PCI_BASE_ADDRESS_SPACE_MEMORY` identifies the BAR type as memory space, and `&gpu_bar_mem` binds the previously registered host dynamic memory region to this BAR. After this step, in QEMU's simulated physical address space, the address range corresponding to this BAR is completely associated with the host memory allocated via `malloc`. When the virtual machine CPU accesses this BAR address, it directly maps to this host memory, without needing to go through the MMIO callback function, achieving high-speed access to the GPU model's video memory.

[0110] In some embodiments, if no cross-process communication requirement based on the inter-process communication interface is detected, the host memory is obtained by calling a dynamic memory allocation function within the virtualization platform.

[0111] The inter-process communication requirements of the inter-process communication interface include: communication requirements between the virtual machine and the host machine, and / or, communication requirements between multiple virtual machines.

[0112] In this embodiment, when there is no need for cross-process communication, GPU memory access only occurs within the QEMU process (virtual machine CPU access is directly processed after being intercepted by QEMU). In this case, choosing dynamic memory allocation within QEMU simplifies the implementation process and reduces the additional overhead of shared memory management by the operating system. Dynamically allocated memory is directly managed by QEMU, making memory allocation and release more flexible, and eliminating the need to consider cross-process access permission control issues.

[0113] For example, if GPU driver debugging is performed only within a single virtual machine, without the need for data interaction with the host machine or other virtual machines, and the host machine does not detect the need for cross-process communication, then host machine memory is allocated as the GPU model's video memory through the malloc function inside QEMU. The virtual machine CPU accesses the video memory directly by operating on the memory pointer after being mapped by QEMU, avoiding redundant steps in the creation and management of shared memory and improving memory access efficiency.

[0114] It should be understood that although the steps in the flowcharts of the embodiments described above are shown sequentially according to the arrows, these steps are not necessarily executed in the order indicated by the arrows. Unless explicitly stated herein, there is no strict order restriction on the execution of these steps, and they can be executed in other orders. Moreover, at least some steps in the flowcharts of the embodiments described above may include multiple steps or multiple stages. These steps or stages are not necessarily completed at the same time, but can be executed at different times. The execution order of these steps or stages is not necessarily sequential, but can be performed alternately or in turn with other steps or at least some of the steps or stages of other steps.

[0115] Based on the same inventive concept, this application also provides a GPU model memory virtual access device for implementing the GPU model memory virtual access method described above. The solution provided by this device is similar to the implementation described in the above method. Therefore, the specific limitations in one or more GPU model memory virtual access device embodiments provided below can be found in the limitations of the GPU model memory virtual access method described above, and will not be repeated here.

[0116] In one exemplary embodiment, such as Figure 4 As shown, a virtual memory access device for a GPU model is provided, comprising:

[0117] The receiving module 401 is used to receive an access request initiated by the CPU in the virtual machine, wherein the access request includes: indication information of the target base address register;

[0118] The routing module 402 is used to route the access request to a target address range in the simulated physical address space based on the indication information and the preset association relationship.

[0119] The preset association relationship includes: the correspondence between the address range in the simulated physical address space and the base address register of the GPU model, and the mapping relationship between the address range in the simulated physical address space and the host memory allocated to the video memory area of ​​the GPU model, wherein the GPU model is a software module that simulates a physical GPU in a virtualization environment.

[0120] In some embodiments, the apparatus further includes: a setup module, configured to:

[0121] Allocate corresponding host memory to the video memory area of ​​the GPU model. The host memory is obtained by creating shared memory or by calling a dynamic memory allocation function within the virtualization platform. The virtualization platform is built on the host machine and provides a runtime environment for the virtual machine to handle the CPU access requests of the virtual machine and support the software architecture for running the GPU model.

[0122] The host machine memory is mapped to a simulated physical address space to determine the mapping relationship;

[0123] Establish the correspondence between the address range in the simulated physical address space and the base address register of the GPU model.

[0124] In some embodiments, the module is specifically used for:

[0125] Obtain the file descriptor of the shared memory;

[0126] The memory region initialization interface provided by the virtualization platform is invoked to map the shared memory corresponding to the file descriptor to the simulated physical address space, thereby determining the mapping relationship.

[0127] In some embodiments, the module is specifically used for:

[0128] Obtain the pointer to the memory allocated by the dynamic memory allocation function;

[0129] The virtualization platform's memory region initialization interface is invoked to map the host memory corresponding to the memory pointer to the simulated physical address space, thereby determining the mapping relationship.

[0130] In some embodiments, when a cross-process communication requirement based on an inter-process communication interface is detected, and the cross-process communication requirement needs to be transferred through the video memory area of ​​the GPU model, the host memory is obtained by creating shared memory.

[0131] The inter-process communication requirements of the inter-process communication interface include: communication requirements between the virtual machine and the host machine, and / or, communication requirements between multiple virtual machines.

[0132] In some embodiments, when no cross-process communication requirement based on the inter-process communication interface is detected, the host memory is obtained by calling a dynamic memory allocation function within the virtualization platform;

[0133] The inter-process communication requirements of the inter-process communication interface include: communication requirements between the virtual machine and the host machine, and / or, communication requirements between multiple virtual machines.

[0134] In some embodiments, the routing module 402 is used for:

[0135] Based on the indication information of the target base address register and the corresponding relationship, a candidate address range in the simulated physical address space corresponding to the target base address register is obtained;

[0136] If, based on the mapping relationship, it is confirmed that there is a mapping relationship between the candidate address range and the host memory allocated to the video memory region of the GPU model, the candidate address range is determined as the target address range;

[0137] The address field of the access request is converted to an address within the target address range to complete the routing of the access request.

[0138] The modules in the aforementioned GPU model's virtual memory access device can be implemented entirely or partially through software, hardware, or a combination thereof. These modules can be embedded in the processor of a computer device in hardware form or independent of it, or they can be stored in the memory of a computer device in software form, so that the processor can call and execute the operations corresponding to each module.

[0139] In one exemplary embodiment, a computer device is provided, which may be a server, and its internal structure diagram may be as follows: Figure 5As shown, this computer device includes a processor, memory, input / output (I / O) interfaces, and a communication interface. The processor, memory, and I / O interfaces are connected via a system bus, and the communication interface is also connected to the system bus via the I / O interfaces. The processor provides computational and control capabilities. The memory includes non-volatile storage media and internal memory. The non-volatile storage media stores the operating system, computer programs, and a database. The internal memory provides the environment for the operating system and computer programs stored in the non-volatile storage media. The database stores data. The I / O interfaces are used for exchanging information between the processor and external devices. The communication interface is used for communicating with external terminals via a network connection. When executed by the processor, the computer program implements a virtual memory access method for a GPU model.

[0140] Those skilled in the art will understand that Figure 5 The structure shown is merely a block diagram of a portion of the structure related to the present application and does not constitute a limitation on the computer device to which the present application is applied. Specific computer devices may include more or fewer components than those shown in the figure, or combine certain components, or have different component arrangements.

[0141] In one exemplary embodiment, a computer device is provided, including a memory and a processor, wherein the memory stores a computer program, and the processor executes the computer program to perform the following steps:

[0142] Receive an access request initiated by the CPU in the virtual machine, the access request including: indication information of the target base address register;

[0143] Based on the indicated information and the preset association, the access request is routed to the target address range in the simulated physical address space;

[0144] The preset association relationship includes: the correspondence between the address range in the simulated physical address space and the base address register of the GPU model, and the mapping relationship between the address range in the simulated physical address space and the host memory allocated to the video memory area of ​​the GPU model, wherein the GPU model is a software module that simulates a physical GPU in a virtualization environment.

[0145] In one embodiment, the processor, when executing a computer program, also performs the following steps:

[0146] The process of establishing the preset association includes:

[0147] Allocate corresponding host memory to the video memory area of ​​the GPU model. The host memory is obtained by creating shared memory or by calling a dynamic memory allocation function within the virtualization platform. The virtualization platform is built on the host machine and provides a runtime environment for the virtual machine to handle the CPU access requests of the virtual machine and support the software architecture for running the GPU model.

[0148] The host machine memory is mapped to a simulated physical address space to determine the mapping relationship;

[0149] Establish the correspondence between the address range in the simulated physical address space and the base address register of the GPU model.

[0150] In one embodiment, the processor, when executing a computer program, also performs the following steps:

[0151] The step of mapping the host machine memory to a simulated physical address space to determine the mapping relationship includes:

[0152] Obtain the file descriptor of the shared memory;

[0153] The memory region initialization interface provided by the virtualization platform is invoked to map the shared memory corresponding to the file descriptor to the simulated physical address space, thereby determining the mapping relationship.

[0154] In one embodiment, a computer-readable storage medium is provided having a computer program stored thereon, the computer program performing the following steps when executed by a processor:

[0155] The step of mapping the host machine memory to a simulated physical address space to determine the mapping relationship includes:

[0156] Obtain the pointer to the memory allocated by the dynamic memory allocation function;

[0157] The virtualization platform's memory region initialization interface is invoked to map the host memory corresponding to the memory pointer to the simulated physical address space, thereby determining the mapping relationship.

[0158] In one embodiment, when the computer program is executed by a processor, it also performs the following steps:

[0159] If a cross-process communication requirement based on an inter-process communication interface is detected, and the cross-process communication requirement needs to be transferred through the GPU model's video memory area, the host memory is obtained by creating shared memory.

[0160] The inter-process communication requirements of the inter-process communication interface include: communication requirements between the virtual machine and the host machine, and / or, communication requirements between multiple virtual machines.

[0161] In one embodiment, when the computer program is executed by a processor, it also performs the following steps:

[0162] In the absence of detected cross-process communication requirements based on inter-process communication interfaces, the host machine memory is obtained by calling dynamic memory allocation functions within the virtualization platform;

[0163] The inter-process communication requirements of the inter-process communication interface include: communication requirements between the virtual machine and the host machine, and / or, communication requirements between multiple virtual machines.

[0164] In one embodiment, a computer program product is provided, including a computer program that, when executed by a processor, performs the following steps:

[0165] Receive an access request initiated by the CPU in the virtual machine, the access request including: indication information of the target base address register;

[0166] Based on the indicated information and the preset association, the access request is routed to the target address range in the simulated physical address space;

[0167] The preset association relationship includes: the correspondence between the address range in the simulated physical address space and the base address register of the GPU model, and the mapping relationship between the address range in the simulated physical address space and the host memory allocated to the video memory area of ​​the GPU model.

[0168] In one embodiment, the processor, when executing a computer program, also performs the following steps:

[0169] The process of establishing the preset association includes:

[0170] Allocate host memory to the GPU model's video memory region, wherein the host memory is obtained by creating shared memory or by calling a dynamic memory allocation function within the virtualization platform;

[0171] The host machine memory is mapped to a simulated physical address space to determine the mapping relationship;

[0172] Establish the correspondence between the address range in the simulated physical address space and the base address register of the GPU model.

[0173] In one embodiment, the host memory is obtained by creating shared memory, and the processor further performs the following steps when executing a computer program:

[0174] The step of mapping the host machine memory to a simulated physical address space to determine the mapping relationship includes:

[0175] Obtain the file descriptor of the shared memory;

[0176] The memory region initialization interface provided by the virtualization platform is invoked to map the shared memory corresponding to the file descriptor to the simulated physical address space, thereby determining the mapping relationship.

[0177] In one embodiment, the host machine memory is obtained by calling a dynamic memory allocation function within the virtualization platform, and the computer program further performs the following steps when executed by the processor:

[0178] The step of mapping the host machine memory to a simulated physical address space to determine the mapping relationship includes:

[0179] Obtain the pointer to the memory allocated by the dynamic memory allocation function;

[0180] The virtualization platform's memory region initialization interface is invoked to map the host memory corresponding to the memory pointer to the simulated physical address space, thereby determining the mapping relationship.

[0181] In one embodiment, when the computer program is executed by a processor, it also performs the following steps:

[0182] If a cross-process communication requirement based on an inter-process communication interface is detected, and the cross-process communication requirement needs to be transferred through the GPU model's video memory area, the host memory is obtained by creating shared memory.

[0183] The inter-process communication requirements of the inter-process communication interface include: communication requirements between the virtual machine and the host machine, and / or, communication requirements between multiple virtual machines.

[0184] In one embodiment, when the computer program is executed by a processor, it also performs the following steps:

[0185] In the absence of detected cross-process communication requirements based on inter-process communication interfaces, the host machine memory is obtained by calling dynamic memory allocation functions within the virtualization platform;

[0186] The inter-process communication requirements of the inter-process communication interface include: communication requirements between the virtual machine and the host machine, and / or, communication requirements between multiple virtual machines.

[0187] In one embodiment, when the computer program is executed by a processor, it also performs the following steps:

[0188] Based on the indication information of the target base address register and the corresponding relationship, a candidate address range in the simulated physical address space corresponding to the target base address register is obtained;

[0189] If, based on the mapping relationship, it is confirmed that there is a mapping relationship between the candidate address range and the host memory allocated to the video memory region of the GPU model, the candidate address range is determined as the target address range;

[0190] The address field of the access request is converted to an address within the target address range to complete the routing of the access request.

[0191] Those skilled in the art will understand that all or part of the processes in the above embodiments can be implemented by a computer program instructing related hardware. The computer program can be stored in a non-volatile computer-readable storage medium. When executed, the computer program can include the processes of the embodiments described above. Any references to memory, databases, or other media used in the embodiments provided in this application can include at least one of non-volatile and volatile memory. Non-volatile memory can include read-only memory (ROM), magnetic tape, floppy disk, flash memory, optical memory, high-density embedded non-volatile memory, resistive random access memory (ReRAM), magnetic random access memory (MRAM), ferroelectric random access memory (FRAM), phase change memory (PCM), graphene memory, etc. Volatile memory can include random access memory (RAM) or external cache memory, etc. By way of illustration and not limitation, RAM can take many forms, such as Static Random Access Memory (SRAM) or Dynamic Random Access Memory (DRAM). The databases involved in the embodiments provided in this application may include at least one type of relational database and non-relational database. Non-relational databases may include, but are not limited to, blockchain-based distributed databases. The processors involved in the embodiments provided in this application may be general-purpose processors, central processing units, graphics processing units, digital signal processors, programmable logic devices, quantum computing-based data processing logic devices, etc., and are not limited to these.

[0192] The technical features of the above embodiments can be combined in any way. For the sake of brevity, not all possible combinations of the technical features in the above embodiments are described. However, as long as there is no contradiction in the combination of these technical features, they should be considered to be within the scope of this specification.

[0193] The embodiments described above are merely illustrative of several implementation methods of this application, and while the descriptions are specific and detailed, they should not be construed as limiting the scope of this patent application. It should be noted that those skilled in the art can make various modifications and improvements without departing from the concept of this application, and these all fall within the protection scope of this application. Therefore, the protection scope of this application should be determined by the appended claims.

Claims

1. A method for virtual memory access in a GPU model, characterized in that, include: Receive an access request initiated by the CPU in the virtual machine, the access request including: indication information of the target base address register; Based on the indicated information and the preset association, the access request is routed to the target address range in the simulated physical address space; The preset association relationship includes: the correspondence between the address range in the simulated physical address space and the base address register of the GPU model, and the mapping relationship between the address range in the simulated physical address space and the host memory allocated to the video memory area of ​​the GPU model, wherein the GPU model is a software module that simulates a physical GPU in a virtualization environment.

2. The method according to claim 1, characterized in that, The process of establishing the preset association includes: Allocate corresponding host memory to the video memory area of ​​the GPU model. The host memory is obtained by creating shared memory or by calling a dynamic memory allocation function within the virtualization platform. The virtualization platform is built on the host machine and provides a runtime environment for the virtual machine to handle the CPU access requests of the virtual machine and support the software architecture for running the GPU model. The host machine memory is mapped to a simulated physical address space to determine the mapping relationship; Establish the correspondence between the address range in the simulated physical address space and the base address register of the GPU model.

3. The method according to claim 2, characterized in that, The step of mapping the host machine memory to a simulated physical address space to determine the mapping relationship includes: Obtain the file descriptor of the shared memory; The memory region initialization interface provided by the virtualization platform is invoked to map the shared memory corresponding to the file descriptor to the simulated physical address space, thereby determining the mapping relationship.

4. The method according to claim 2, characterized in that, The step of mapping the host machine memory to a simulated physical address space to determine the mapping relationship includes: Obtain the pointer to the memory allocated by the dynamic memory allocation function; The virtualization platform's memory region initialization interface is invoked to map the host memory corresponding to the memory pointer to the simulated physical address space, thereby determining the mapping relationship.

5. The method according to claim 3, characterized in that, The method further includes: If a cross-process communication requirement based on an inter-process communication interface is detected, and the cross-process communication requirement needs to be transferred through the GPU model's video memory area, the host memory is obtained by creating shared memory. The inter-process communication requirements of the inter-process communication interface include: communication requirements between the virtual machine and the host machine, and / or, communication requirements between multiple virtual machines.

6. The method according to claim 4, characterized in that, The method further includes: In the absence of detected cross-process communication requirements based on inter-process communication interfaces, the host machine memory is obtained by calling dynamic memory allocation functions within the virtualization platform; The inter-process communication requirements of the inter-process communication interface include: communication requirements between the virtual machine and the host machine, and / or, communication requirements between multiple virtual machines.

7. The method according to any one of claims 1 to 6, characterized in that, The step of routing the access request to a target address range in the simulated physical address space based on the indication information and the preset association relationship includes: Based on the indication information of the target base address register and the corresponding relationship, a candidate address range in the simulated physical address space corresponding to the target base address register is obtained; If, based on the mapping relationship, it is confirmed that there is a mapping relationship between the candidate address range and the host memory allocated to the video memory region of the GPU model, the candidate address range is determined as the target address range; The address field of the access request is converted to an address within the target address range to complete the routing of the access request.

8. A virtual memory access device for a GPU model, characterized in that, The device includes: The receiving module is used to receive access requests initiated by the CPU in the virtual machine, wherein the access request includes: indication information of the target base address register; The routing module is used to route the access request to a target address range in the simulated physical address space based on the indication information and the preset association relationship. The preset association relationship includes: the correspondence between the address range in the simulated physical address space and the base address register of the GPU model, and the mapping relationship between the address range in the simulated physical address space and the host memory allocated to the video memory area of ​​the GPU model, wherein the GPU model is a software module that simulates a physical GPU in a virtualization environment.

9. A computer device comprising a memory and a processor, wherein the memory stores a computer program, characterized in that, When the processor executes the computer program, it implements the steps of the method according to any one of claims 1 to 7.

10. A computer-readable storage medium having a computer program stored thereon, characterized in that, When the computer program is executed by a processor, it implements the steps of the method according to any one of claims 1 to 7.

11. A computer program product, comprising a computer program, characterized in that, When the computer program is executed by a processor, it implements the steps of the method according to any one of claims 1 to 7.

Images