Address mapping method, device and computer equipment for GPU emulation

Abstract

The present disclosure provides an address mapping method, device and computer equipment for GPU simulation, and relates to the field of computers and chips, which comprises the following steps: applying a first virtual address space through a host kernel interface, and specifying a second virtual address space for a GPU device simulation model, the address limit of the second virtual address space is not more than the size of the first virtual address space and has no address overlap; establishing a first mapping relationship therebetween, the second virtual address is mapped to the first virtual address through an offset operation; in response to a PCIe enumeration request when a native driver is loaded, shielding the operation and returning second virtual address space information; and in response to a read-write request of a native driver user state, a kernel state or a device simulation model, redirecting to the first virtual address space based on the first mapping relationship, the scheme can provide a lossless kernel-level virtualization hardware simulation mechanism, realize the replacement of a real GPU physical address space, and be fully compatible with the upper-layer ecology and kernel state characteristics of the native driver.

Description

Technical Field

[0001] This disclosure relates to the fields of computers and chips, and in particular to technologies such as GPU (graphics processing unit) simulation and verification, native driver adaptation and hardware-software co-operation. Specifically, it relates to an address mapping method, apparatus, computer device, computer-readable storage medium and computer program product for GPU simulation. Background Technology

[0002] As the complexity of GPUs continues to increase in general computing and graphics processing, IP-level verification has become a critical step before SoC tape-out. The industry commonly adopts a "software-hardware collaborative left-shift" strategy, integrating real-world application ecosystems and native drivers into the design simulation model before tape-out to expose potential issues in software-hardware interactions. However, native drivers rely on the PCIe bus for device detection and address mapping, while IP simulation models run in host user space, lacking real hardware support. This prevents native drivers from completing initialization and address mapping in the simulation environment, limiting their full functional coverage during the IP verification phase. Therefore, a solution that enables native drivers to run fully in the IP simulation environment is urgently needed. Summary of the Invention

[0003] This disclosure provides an address mapping method, apparatus, computer device, computer-readable storage medium, and computer program product for GPU emulation.

[0004] According to one aspect of this disclosure, an address mapping method for GPU emulation is provided, comprising: requesting a first virtual address space through a host machine's kernel interface, wherein a device emulation model for GPU emulation runs on the host machine; specifying a second virtual address space for the device emulation model, the second virtual address space being continuous for a specified address limit starting from a specified base address, wherein the address limit does not exceed the size of the requested first virtual address space, and the second virtual address space does not overlap with the first virtual address space; establishing a first mapping relationship between the second virtual address space and the first virtual address space, wherein the second virtual address space contains a second virtual address space... The address is mapped to a first virtual address in the first virtual address space via an offset operation. The offset operation uses the base address as the offset reference and performs linear address translation based on the starting address of the first virtual address space. In response to the native driver issuing a request for PCIe enumeration operation during loading, the PCIe enumeration operation is masked and information associated with the second virtual address space is returned. The PCIe enumeration operation is used to obtain the physical address via the PCIe bus. In response to any read / write request issued by the user mode, kernel mode, or device emulation model of the native driver during GPU emulation, the read / write request is redirected to the first virtual address space based on the first mapping relationship.

[0005] In some embodiments, the method further includes: determining whether a memory release instruction for a second virtual address space is intercepted; and in response to intercepting the memory release instruction, suspending the memory release instruction and returning a memory release success message, wherein memory release for the first virtual address space based on the first mapping relationship is masked.

[0006] In some embodiments, there is a second mapping relationship between the first virtual address space and the first physical address space, where the first physical address space indicates the physical address of the host machine's memory unit, and the second mapping relationship is recorded in the host machine's page table.

[0007] In some embodiments, in response to a read / write request issued by the user space of the native driver during GPU emulation, the method further includes: converting a first virtual address corresponding to the read / write request into a target physical address via a second mapping relationship; and writing the target physical address into the host machine's page table, wherein the host machine's memory units are accessed based on the host machine's page table.

[0008] In some embodiments, in response to a read / write request issued by the kernel mode of the native driver during GPU emulation, the method further includes: masking I / O mapping operations so that the first virtual address corresponding to the read / write request can be directly accessed.

[0009] In some embodiments, in response to a read / write request issued by the device emulation model during GPU emulation, the method further includes: after the read / write request is redirected to a first virtual address space, so that the first virtual address corresponding to the read / write request is directly accessed.

[0010] In some embodiments, the offset operation includes subtracting the base address from the second virtual address and adding the starting address of the first virtual address space.

[0011] In some embodiments, the user mode and kernel mode of the native driver request the allocation or release of a second virtual address in the second virtual address space via a unified address management entry point, which is set in the kernel mode.

[0012] According to one aspect of this disclosure, an address mapping apparatus for GPU emulation is provided, comprising: a first allocation module configured to request a first virtual address space through a host machine's kernel interface, wherein a device emulation model for GPU emulation runs on the host machine; a second allocation module configured to specify a second virtual address space for the device emulation model, the second virtual address space being continuous for a specified address limit starting from a specified base address, wherein the address limit does not exceed the size of the requested first virtual address space, and the second virtual address space does not overlap with the first virtual address space; and a mapping construction module configured to establish a first mapping relationship between the second virtual address space and the first virtual address space, wherein the second virtual address space... The second virtual address in the first virtual address space is mapped to the first virtual address in the first virtual address space via an offset operation. The offset operation uses the base address as the offset reference and performs linear address translation based on the starting address of the first virtual address space. The first masking module is configured to mask the PCIe enumeration operation and return information associated with the second virtual address space in response to a request issued by the native driver for PCIe enumeration operation during loading. The PCIe enumeration operation is used to obtain the physical address via the PCIe bus. The redirection module is configured to redirect the read / write request to the first virtual address space based on the first mapping relationship in response to a read / write request issued by any of the user mode, kernel mode, or device emulation model of the native driver during GPU emulation.

[0013] According to another aspect of this disclosure, a computer device is provided, comprising: at least one processor; and a memory having a computer program stored thereon, wherein the computer program, when executed by the at least one processor, causes the at least one processor to perform the methods provided above in this disclosure.

[0014] According to another aspect of this disclosure, a computer-readable storage medium is provided having a computer program stored thereon, which, when executed by a processor, causes the processor to perform the methods provided above in this disclosure.

[0015] According to another aspect of this disclosure, a computer program product is provided, including a computer program that, when executed by a processor, causes the processor to perform the methods provided above in this disclosure.

[0016] According to one or more embodiments of this disclosure, a lossless kernel-level virtualization hardware simulation mechanism can be provided to replace the physical address space of the real GPU, fully compatible with the upper-level ecosystem and kernel-mode characteristics of the native driver, and has advantages such as low invasiveness and deployment flexibility since no destructive modifications to the kernel core are required.

[0017] These and other aspects of this disclosure will be apparent from the embodiments described below, and will be elucidated with reference to the embodiments described below. Attached Figure Description

[0018] The accompanying drawings exemplify embodiments and form part of the specification, serving together with the textual description to explain exemplary implementations of the embodiments. The illustrated embodiments are for illustrative purposes only and do not limit the scope of this disclosure. Throughout the drawings, the same reference numerals refer to similar but not necessarily identical elements.

[0019] Figure 1 This is a flowchart illustrating an address mapping method for GPU emulation according to an exemplary embodiment.

[0020] Figure 2 This is a schematic diagram illustrating a first mapping relationship between a second virtual address space and a first virtual address space according to an exemplary embodiment.

[0021] Figure 3 This is a schematic diagram illustrating a pseudo-release mechanism according to an exemplary embodiment.

[0022] Figure 4 This is a schematic diagram illustrating a second mapping relationship between a first virtual address space and a first physical address space according to an exemplary embodiment.

[0023] Figure 5 This is a schematic diagram illustrating the process of accessing the second virtual address space in different scenarios according to an exemplary embodiment.

[0024] Figure 6 This is a schematic block diagram illustrating an address mapping apparatus for GPU emulation according to an exemplary embodiment.

[0025] Figure 7 This is a block diagram illustrating an exemplary computer device that can be applied to an exemplary embodiment. Detailed Implementation

[0026] The exemplary embodiments of this disclosure are described below with reference to the accompanying drawings, including various details of the embodiments to aid understanding, and should be considered merely exemplary. Therefore, those skilled in the art will recognize that various changes and modifications can be made to the embodiments described herein without departing from the scope of this disclosure. Similarly, for clarity and brevity, descriptions of well-known functions and structures are omitted in the following description.

[0027] In this disclosure, unless otherwise stated, the use of terms such as "first," "second," etc., to describe various elements is not intended to limit the positional, temporal, or importance relationships of these elements; such terms are merely used to distinguish one element from another. In some examples, the first element and the second element may refer to the same instance of that element, while in other cases, based on the context, they may refer to different instances.

[0028] The terminology used in the description of the various examples described in this disclosure is for the purpose of describing particular examples only and is not intended to be limiting. Unless the context explicitly indicates otherwise, an element may be one or more unless the number of elements is specifically limited. As used herein, the term "multiple" means two or more, and the term "based on" should be interpreted as "at least partially based on". Furthermore, the terms "and / or" and "at least one of..." cover any one of the listed items and all possible combinations thereof.

[0029] In related technologies, with the evolution of general-purpose computing and graphics processing technologies, the complexity of GPU IP has increased exponentially. IP-level verification, as a core step before SoC integration, directly determines the reliability after tape-out. To shorten product launch cycles, the industry is increasingly emphasizing the "software-hardware collaborative left-shift" strategy. By pre-compiling and debugging real application software stacks, native drivers (including user-mode and kernel-mode drivers), and design simulation models (such as C-Model or RTL-level Simv), it is possible to leverage mature ecosystems such as CUDA, OpenGL, and OpenCL to deeply expose key issues in software-hardware interaction, such as deadlocks and address mapping anomalies, before the hardware logic is tapered.

[0030] Within the existing verification framework, a significant address gap exists between the native driver software stack and the IP emulation environment. The native kernel-mode driver relies on the PCIe (Peripheral Component Interconnect) protocol stack for device detection and resource mapping, with its underlying logic involving PCIe enumeration, BAR (Base Address Register) space mapping, and allocation of physically contiguous memory. However, GPU IP emulation models typically run as independent processes in the host machine's user space, lacking the support of a real PCIe physical bus. This prevents the native driver from completing device initialization through standard kernel calls, and further hinders its ability to correctly map the virtual addresses it manages to the memory space where the emulation model resides, thus limiting the full functionality of the native driver during the IP verification phase.

[0031] A traditional solution is based on data stream capture and replay, which involves pre-capturing data streams on mature hardware and replaying them in a simulation environment using specific drivers. This approach is essentially offline verification, discarding the dynamic interaction details of the upper-layer software ecosystem (such as drivers dynamically adjusting memory allocation based on hardware status). The hardware and software environments are severely decoupled, making it impossible to verify real-world closed-loop interaction logic and resulting in extremely low coverage of scenarios such as asynchronous exception handling. Furthermore, this solution is essentially a one-way static instruction injection, completely detached from the driver runtime environment. Due to the lack of real-time interaction with the upper-layer software ecosystem (such as OpenCL / OpenGL / CUDA), it cannot capture hardware state anomalies triggered by dynamic software logic, leading to a severe disconnect between the verification scenario and actual applications. Simultaneously, the simulation model lacks realistic address management and mapping capabilities, failing to simulate critical hardware behaviors such as dynamic memory allocation and page table updates, resulting in address-related logic vulnerabilities remaining undetected during the IP verification phase.

[0032] Another traditional solution is to customize a simplified driver. To bypass the complexity of kernel mode, developers create a simplified driver that is stripped of PCIe dependencies, or move all logic to user mode. However, the underlying code architecture of customized drivers differs significantly from that of native drivers, resulting in the driver in the verification environment being a different codebase from the driver in the production environment. For example, critical logic such as interrupt handling, kernel-mode memory management, and host page table configuration is skipped. To adapt to environments without PCIe, customized drivers often require large-scale modifications to the kernel code, such as moving the device address space that should be managed by the kernel to user mode. This reconstruction of the underlying interaction logic shields the resource contention, context switching, and memory isolation features of the real kernel mode, skipping interrupt handling, kernel-mode memory management, and host page table configuration, resulting in a significant gap in the coverage of hardware-software co-verification. At the same time, customized drivers are verification-specific code and cannot be directly inherited into mass-produced products. This redundant development not only increases R&D costs but may also lead to inconsistencies between the verified code and the final deployed native code.

[0033] Therefore, in the GPU IP-level simulation stage, the simulation model (such as C-Model, Simv) is unable to be addressed by the native kernel driver and the address interaction link is broken due to the lack of physical layer (such as no PCIe controller and bus structure). This invention proposes a low-intrusion virtual device construction scheme implemented in kernel space. It aims to build a virtual device address interaction protocol without destroying the integrity of the native driver. It can maintain complete transparency to the upper-layer application software ecosystem (such as OpenCL / OpenGL / CUDA) and achieve full ecosystem support without modifying the user layer code. It builds a virtual device address space corresponding to the simulation model in kernel space, so that the verification process can cover all the key features of the native kernel driver (such as interrupt handling, page table management, etc.). Furthermore, through a lightweight address interception and redirection mechanism, it retains the logical architecture of the native driver to the maximum extent and significantly reduces the R&D investment in software and hardware adaptation.

[0034] Figure 1 This is a flowchart illustrating an address mapping method for GPU emulation according to an exemplary embodiment.

[0035] In step S101, a first virtual address space is requested through the host machine's kernel interface. The device simulation model used for GPU emulation runs on the host machine.

[0036] In the example, the device emulation model used for GPU emulation can include a C-Model or an RTL-level Simv as described above. The device emulation model runs on a host machine. The host machine can run an operating system such as Linux, with a CPU as the core processor. The host machine's kernel interface can include system calls or kernel functions provided by the operating system's kernel, such as the vmalloc kernel interface. A large and contiguous virtual address space, i.e., the first virtual address space, can be reserved in kernel mode via the vmalloc kernel interface when the native driver is loaded. The native driver can refer to a driver program directly loaded by the operating system kernel and tightly coupled to the GPU hardware.

[0037] In step S102, a second virtual address space is specified for the device simulation model. The second virtual address space is continuous within a specified address limit, starting from the specified base address. This address limit does not exceed the size of the allocated first virtual address space, and the second virtual address space does not overlap with the first virtual address space.

[0038] In the example, the base address of the second virtual address space could be, for example, 0xF0000000. This base address can be determined based on the addressing bit width of the GPU IP, that is, the address bus width defined during GPU hardware design, such as 32 bits or 64 bits, which determines the size of the address space the GPU can access. The address limit of the second virtual address space can be determined based on the simulated GPU memory size. For example, with a base address of 0xF0000000, the second virtual address space can be contiguous from 0xF0000000 to 0xFFFFFFFF, in which case the address limit can be 256MB. It is understood that the above base address and address limit are not limited to the example here.

[0039] According to embodiments of this disclosure, the second virtual address space is a virtual device address space specified for the device emulation model. Its purpose is to serve as a physical resource carrier for simulating the GPU, enabling the native driver to treat this second virtual address space as the GPU's physical address space during GPU emulation. This replaces the real physical address obtained via the PCIe bus, thereby helping to solve the problems caused by the lack of a physical layer (such as the absence of a PCIe controller and bus structure) in the GPU IP-level emulation stage. In other words, for the logic of the native driver, the base address of the second virtual address space is regarded as the GPU's real physical starting address.

[0040] In step S103, a first mapping relationship is established between the second virtual address space and the first virtual address space. The second virtual address in the second virtual address space is mapped to the first virtual address in the first virtual address space via an offset operation. This offset operation uses the base address as the offset reference and performs linear address translation based on the starting address of the first virtual address space.

[0041] In the example, the second virtual address space can be the same size as the first virtual address space, so that the second virtual address space is continuously aligned from the base address to the first virtual address space from the start address, thus enabling linear address translation through address offset.

[0042] Figure 2 This is a schematic diagram illustrating a first mapping relationship between a second virtual address space and a first virtual address space according to an exemplary embodiment.

[0043] like Figure 2As shown, three second virtual addresses 0xF0000000, 0xF0000004, and 0xF0000008 in the second virtual address space, and three first virtual addresses in the first virtual address space are illustrated, denoted as "V_P +0", "V_P + 4", and "V_P + 8", respectively. The second virtual address 0xF0000000 is mapped to the first virtual address "V_P +0", the second virtual address 0xF0000004 is mapped to the first virtual address "V_P + 4", and the second virtual address 0xF0000008 is mapped to the first virtual address "V_P + 8".

[0044] In some embodiments, the offset operation described above may include subtracting the base address from the second virtual address and adding the starting address of the first virtual address space.

[0045] by Figure 2 Taking the mapping between the second virtual address 0xF0000004 and the first virtual address "V_P + 4" as an example, the first virtual address "V_P + 4" can be obtained by subtracting the base address 0xF0000000 from the second virtual address 0xF0000004 and adding the starting address "V_P + 0" of the first virtual address space.

[0046] By establishing a deterministic and reversible linear mapping relationship between the second virtual address space and the first virtual address space, any second virtual address can be uniquely mapped to a specific location in the first virtual address space, thereby redirecting the access of the native driver or device emulation model to the GPU physical address to the actual memory of the host machine.

[0047] Return to reference again Figure 1 In step S104, in response to the native driver issuing a request for PCIe enumeration operation during loading, the PCIe enumeration operation is masked and information associated with the second virtual address space is returned. The PCIe enumeration operation is used to obtain a physical address via the PCIe bus.

[0048] In the example, the native driver obtains the GPU's physical address via the PCIe bus through a PCIe enumeration operation during loading. However, as mentioned earlier, in the GPU IP-level emulation stage, the device emulation model itself lacks a physical layer, meaning it does not have a PCIe controller or bus structure. In this case, according to embodiments of this disclosure, if the native driver issues a request for a PCIe enumeration operation during loading, it intentionally masks the PCIe enumeration operation and instead returns information associated with the second virtual address space, such as a specified base address. This allows the native driver to treat the base address of the second virtual address space as the GPU's actual physical starting address.

[0049] In step S105, in response to any read / write request issued during GPU emulation by the native driver's user mode, kernel mode, or device emulation model, the read / write request is redirected to the first virtual address space based on the first mapping relationship.

[0050] In the example, user mode and kernel mode are two layers of the native driver, involving different permissions. User mode can run at the ordinary program level and cannot directly manipulate hardware; therefore, requesting GPU resources requires system calls to be made via kernel mode. Kernel mode can run at the operating system's kernel level and can have high privileges to directly manage hardware resources, configure page tables, handle interrupts, etc. In the embodiments of this disclosure, by redirecting read and write requests to the first virtual address space, full-scenario access, including the native driver's user mode, kernel mode, and device emulation model, can be supported.

[0051] Therefore, the address mapping method for GPU emulation according to embodiments of this disclosure provides a lossless kernel-level virtualization hardware simulation mechanism, overcoming the limitations of traditional IP verification that must rely on physical PCIe enumeration or be completely detached from kernel-mode drivers. By constructing a resource pool based on contiguous system virtual addresses in kernel space, the generation logic of virtual device addresses is reconstructed from the bottom layer. This mechanism achieves a replacement for the real GPU physical address space, is fully compatible with the upper-layer ecosystem and kernel-mode characteristics of native drivers (such as interrupt handling, memory management, and page table configuration), and has advantages such as low invasiveness and deployment flexibility because it does not require destructive modifications to the kernel core.

[0052] In some embodiments, the user mode and kernel mode of the native driver can request the allocation or release of a second virtual address in the second virtual address space via a unified address management entry point. This unified address management entry point can be set in kernel mode.

[0053] By setting a unified address management entry point in kernel mode, allocation and release requests for the second virtual address space from both user mode and kernel mode of the native driver can be processed through the same channel. This enables centralized control of virtual device address resources, avoiding address conflicts or allocation fragmentation caused by multi-path requests. Furthermore, since this entry point runs in kernel mode, it can directly manipulate the physical memory resources carried by the first virtual address space. This allows release instructions targeting the second virtual address space to be intercepted at the kernel level, enabling logical release and shielding the underlying physical memory reclamation, ultimately ensuring the continuous effectiveness of memory units throughout the simulation cycle.

[0054] In some embodiments, the address mapping method for GPU emulation according to the present disclosure may further include: determining whether a memory release instruction for a second virtual address space is intercepted; and in response to intercepting the memory release instruction, suspending the memory release instruction and returning a memory release success message, wherein memory release for the first virtual address space based on the first mapping relationship is masked.

[0055] Figure 3 This is a schematic diagram illustrating a pseudo-release mechanism according to an exemplary embodiment.

[0056] like Figure 3 As shown, a unified address management entry point can be established in the kernel mode of the native driver. After initialization, the base address can be identified and marked, such as 0xF0000000. When the upper layer needs to request a second virtual address space, such as requesting a texture space (usually requested by user mode) or requesting the first-level page table corresponding to the texture space (usually requested by kernel mode), it can return at least a part of the second virtual address space through this unified address management entry point.

[0057] When upper-layer software calls the interface to destroy textures or release memory, the kernel driver executes the logical release (updates the software state and returns success), but masks the underlying destruction actions for memory blocks. That is, memory release based on the first mapping relationship in the first virtual address space is masked. This ensures that even if the software believes the resource has been released in complex simulation timing, the underlying layer can still safely access the memory, avoiding illegal memory access caused by asynchronous timing.

[0058] By intercepting memory release instructions targeting the second virtual address space during the simulation cycle and suspending the actual execution of these instructions, the upper-layer software can receive successful memory release feedback and continue normal operation. Furthermore, since the underlying physical memory reclamation operation targeting the first virtual address space is masked, this memory space remains valid at the physical level. Ultimately, when the device simulation model accesses this memory space during asynchronous execution, illegal access or page faults caused by timing differences are avoided, thus ensuring the continuity and stability of the simulation verification.

[0059] Therefore, the address mapping method for GPU simulation according to the embodiments of this disclosure also provides a persistent solution for resource lifecycle management. By intercepting release actions in kernel mode and maintaining the virtual address space, the continuity and security of memory access of the device simulation model in asynchronous computing scenarios are ensured, thereby ensuring the functional coupling of native software logic and hardware timing logic in the address space, and greatly improving the verification coverage of complex concurrent scenarios.

[0060] In some embodiments, there may be a second mapping relationship between the first virtual address space and the first physical address space, wherein the first physical address space indicates the physical address of the host machine's memory unit, and the second mapping relationship is recorded in the host machine's page table.

[0061] Figure 4 This is a schematic diagram illustrating a second mapping relationship between a first virtual address space and a first physical address space according to an exemplary embodiment.

[0062] like Figure 4 As shown, an example is illustrated by three first virtual addresses in the first virtual address space, denoted as “V_P+0”, “V_P+4” and “V_P+8”, respectively, and the correspondence between these three first virtual addresses and three physical addresses in the first physical address space in the host machine’s page table, denoted as “CPU PA0”, “CPU PA1” and “CPU PA2”, respectively.

[0063] By recording a second mapping relationship between the first virtual address space and the first physical address space in the host machine's page table, the first virtual address can be resolved into a physical address via the host machine's standard page table mechanism. When a user-space request from a native driver issues a read / write request, the request is redirected to the first virtual address space via the first mapping relationship, and can then be further converted into a physical address via the second mapping relationship and filled into the page table. The user-space virtual address directly accesses the host machine's memory units through the page table mapping, thereby logically simulating the GPU memory access path and achieving transparent compatibility with the upper-layer application ecosystem.

[0064] Figure 5 This is a schematic diagram illustrating the process of accessing the second virtual address space in different scenarios according to an exemplary embodiment.

[0065] In some embodiments, in response to a read / write request issued by the user space of the native driver during GPU emulation, the address mapping method for GPU emulation according to embodiments of this disclosure may further include: converting the first virtual address corresponding to the read / write request into a target physical address via a second mapping relationship; and writing the target physical address into the host machine's page table, wherein the host machine's memory units are accessed based on the host machine's page table.

[0066] like Figure 5As shown, path A corresponds to the scenario where the native driver's user space issues read / write requests during GPU emulation. Similarly, this scenario can also be applied to the native driver's kernel space. In the example, when the native driver needs to access GPU resources such as textures through the corresponding page table, it can convert the requested second virtual address to the first virtual address, then resolve the first physical address through kernel functions such as virt_to_phys, and fill it into the host machine's page table.

[0067] By further converting the first virtual address, which has been redirected through the first mapping relationship, into a second physical address (i.e., the target physical address) via a second mapping relationship, and writing this target physical address into the host machine's page table, the virtual address of the native driver in user mode can be translated using the host machine's standard page table mechanism. When the CPU executes a user-mode access instruction, it can obtain the target physical address by querying the page table. Thus, user-mode access requests to the second virtual address space are transparently mapped to the host machine's physical memory units, thereby simulating the GPU memory access path without modifying the upper-layer application code.

[0068] In some embodiments, in response to a read / write request issued by the kernel mode of the native driver during GPU emulation, the address mapping method for GPU emulation according to embodiments of this disclosure may further include: masking I / O mapping operations so that the first virtual address corresponding to the read / write request can be directly accessed.

[0069] like Figure 5 As shown, path B corresponds to the scenario where the kernel mode of the native driver issues read / write requests during GPU emulation. In the example, for kernel-specific I / O reads and writes, the standard I / O mapping process (such as ioremap) can be skipped, and an offset mapping from the second virtual address space to the first virtual address space can be directly established, allowing the kernel to operate on this address space as if it were a register.

[0070] By shielding the standard I / O mapping operations in the native kernel driver, kernel-mode read and write requests skip the redundant address translation process. The kernel directly operates on the first virtual address space based on the first mapping relationship, accessing the corresponding memory units without needing page tables or I / O remapping. Therefore, kernel-mode access to the second virtual address space is transparently redirected to the host machine's physical memory, thus achieving a low-intrusive replacement of the real PCIe hardware environment while retaining the direct addressing characteristics of the native driver kernel.

[0071] In some embodiments, in response to a read / write request issued by the device emulation model during GPU emulation, the address mapping method for GPU emulation according to embodiments of the present disclosure may further include: after the read / write request is redirected to a first virtual address space, so that the first virtual address corresponding to the read / write request is directly accessed.

[0072] like Figure 5 As shown, path C corresponds to the scenario where the device emulation model issues read / write requests during GPU emulation. In the example, after the internal logic of the device emulation model C-Model or Simv translates the second virtual address through the corresponding page table, it can directly read and write data in the host machine's memory unit by mapping it back to the first virtual address within the host machine process.

[0073] In this way, since the device simulation model runs in the host machine's user space, its access operations can be completed at the virtual address level without further resolution to physical addresses. The simulation model's read and write operations on GPU memory are transparently mapped to the host machine's memory units, thus achieving a complete simulation of the device-side data access path without relying on real GPU hardware.

[0074] Therefore, the address mapping method for GPU simulation according to the embodiments of this disclosure also provides a multi-dimensional full-mapping address translation and management architecture, which establishes a deterministic mapping of the second virtual address space, the first virtual address space and the first physical address space, supports the coexistence of page table access paths and direct access paths (skipping redundant I / O mappings), accurately matches the memory access behavior of the native driver at different stages, and eliminates the logical differences between the simulation environment and the real environment.

[0075] Embodiments of this disclosure also provide an address mapping apparatus for GPU emulation.

[0076] Figure 6 This is a schematic block diagram illustrating an address mapping apparatus for GPU emulation according to an exemplary embodiment.

[0077] In some embodiments, the address mapping device 600 may include: a first allocation module 601, configured to request a first virtual address space through the host machine's kernel interface, wherein the device emulation model for GPU emulation runs on the host machine; a second allocation module 602, configured to specify a second virtual address space for the device emulation model, the second virtual address space being continuous for a specified address limit starting from a specified base address, wherein the address limit does not exceed the size of the requested first virtual address space, and the second virtual address space and the first virtual address space do not overlap in addresses; and a mapping construction module 603, configured to establish a first mapping relationship between the second virtual address space and the first virtual address space, wherein the second virtual address space contains a second virtual address space. The virtual address is mapped to the first virtual address in the first virtual address space via an offset operation. The offset operation uses the base address as the offset reference and performs linear address translation based on the starting address of the first virtual address space. The first masking module 604 is configured to mask the PCIe enumeration operation and return information associated with the second virtual address space in response to a request issued by the native driver for PCIe enumeration operation during loading. The PCIe enumeration operation is used to obtain the physical address via the PCIe bus. The redirection module 605 is configured to redirect the read / write request to the first virtual address space based on the first mapping relationship in response to a read / write request issued by any of the user mode, kernel mode, or device emulation model of the native driver during GPU emulation.

[0078] The operations of the first allocation module 601, the second allocation module 602, the mapping construction module 603, the first masking module 604, and the redirection module 605 described above can be combined with... Figure 1 The operations of steps S101, S102, S103, S104, and S105 are the same. Therefore, the details of each aspect will not be elaborated here.

[0079] In some embodiments, the address mapping device 600 may further include: a pseudo-release module 606, configured to determine whether a memory release instruction for the second virtual address space is intercepted; and in response to intercepting the memory release instruction, suspending the memory release instruction and returning a memory release success message, wherein memory release for the first virtual address space based on the first mapping relationship is masked.

[0080] In some embodiments, the address mapping device 600 may further include: a physical address access module 607, configured to, in response to a read / write request issued by the user space of the native driver during GPU emulation, convert the first virtual address corresponding to the read / write request into a target physical address via a second mapping relationship; and write the target physical address into the host machine's page table, wherein the host machine's memory units are accessed based on the host machine's page table.

[0081] In some embodiments, the address mapping device 600 may include a second shielding module 608, configured to shield I / O mapping operations in response to read / write requests issued by the kernel mode of the native driver during GPU emulation, so that the first virtual address corresponding to the read / write request can be directly accessed.

[0082] In some embodiments, the address mapping device 600 may further include: a model access module 609, configured to respond to a read / write request issued by the device emulation model during GPU emulation, such that after the read / write request is redirected to a first virtual address space, the first virtual address corresponding to the read / write request is directly accessed.

[0083] While specific functions have been discussed above with reference to specific modules, it should be noted that the functions of the modules discussed herein can be divided into multiple modules, and / or at least some functions of multiple modules can be combined into a single module. The specific actions performed by the modules discussed herein include the specific module itself performing the action, or alternatively, the specific module calling or otherwise accessing another component or module that performs the action (or performs the action in conjunction with the specific module). Therefore, a specific module performing an action can include the specific module performing the action itself and / or another module that performs the action, called or otherwise accessed by the specific module.

[0084] It should also be understood that the above regarding Figure 6 The described modules can be implemented in hardware or in hardware in combination with software and / or firmware. For example, these modules can be implemented as computer program code / instructions configured to execute in one or more processors and stored in a computer-readable storage medium. Alternatively, these modules can be implemented as hardware logic / circuit. For example, these modules can be implemented together in a System on Chip (SoC). An SoC may include an integrated circuit chip (which includes one or more components in a processor (e.g., a Central Processing Unit (CPU), microcontroller, microprocessor, digital signal processor (DSP), etc.), memory, one or more communication interfaces, and / or other circuitry) and may optionally execute received program code and / or include embedded firmware to perform functions.

[0085] According to one aspect of this disclosure, a computer device is provided, including a memory, a processor, and a computer program stored in the memory. The processor is configured to execute the computer program to implement the steps of any of the method embodiments described above.

[0086] According to one aspect of this disclosure, a non-transitory computer-readable storage medium is provided, on which a computer program is stored, which, when executed by a processor, implements the steps of any of the method embodiments described above.

[0087] According to one aspect of this disclosure, a computer program product is provided, comprising a computer program that, when executed by a processor, implements the steps of any of the method embodiments described above.

[0088] In the following text, combined with Figure 7 Illustrative examples describing such computer devices, non-transitory computer-readable storage media, and computer program products.

[0089] Figure 7 An example configuration of a computer device 700 that can be used to implement the methods described herein is shown.

[0090] Computer device 700 can be a variety of different types of devices. Examples of computer device 700 include, but are not limited to: desktop computers, server computers, laptop or netbook computers, mobile devices (e.g., tablet computers, cellular or other wireless phones (e.g., smartphones), notebook computers, mobile stations), wearable devices (e.g., glasses, watches), entertainment devices (e.g., entertainment appliances, set-top boxes communicatively coupled to a display device, game consoles), televisions or other display devices, automotive computers, and so on.

[0091] Computer device 700 may include at least one processor 702, memory 704, communication interface 706, display device 708, other input / output (I / O) devices 710, and one or more mass storage devices 712 capable of communicating with each other, such as via system bus 714 or other suitable connection.

[0092] Processor 702 may be a single processing unit or multiple processing units, and all processing units may include single or multiple computing units or multiple cores. Processor 702 may be implemented as one or more microprocessors, microcomputers, microcontrollers, digital signal processors, central processing units, state machines, logic circuits, and / or any device that manipulates signals based on operating instructions. Among other capabilities, processor 702 may be configured to acquire and execute computer-readable instructions stored in memory 704, mass storage device 712, or other computer-readable media, such as program code of operating system 716, program code of application program 718, program code of other program 720, etc.

[0093] Memory 704 and mass storage device 712 are examples of computer-readable storage media for storing instructions that are executed by processor 702 to perform the various functions described above. For example, memory 704 can generally include both volatile and non-volatile memory (e.g., RAM, ROM, etc.). Furthermore, mass storage device 712 can generally include hard disk drives, solid-state drives, removable media, including external and removable drives, memory cards, flash memory, floppy disks, optical disks (e.g., CDs, DVDs), storage arrays, network-attached storage, storage area networks, etc. Both memory 704 and mass storage device 712 can be collectively referred to herein as memory or computer-readable storage media, and can be non-transitory media capable of storing computer-readable, processor-executable program instructions as computer program code, which can be executed by processor 702 as a specific machine configured to perform the operations and functions described in the examples herein.

[0094] Multiple programs can be stored on mass storage device 712. These programs include operating system 716, application programs 718, other programs 720, and program data 722, and they can be loaded into memory 704 for execution. Examples of such application programs or program modules may include... Figure 1 The computer program logic (e.g., computer program code or instructions) of the methods shown and / or other embodiments described herein.

[0095] Although Figure 7 The data is illustrated as being stored in memory 704 of computer device 700, but the operating system 716, application program 718, other programs 720, and program data 722, or portions thereof, may be implemented using any form of computer-readable medium accessible by computer device 700. As used herein, "computer-readable medium" includes at least two types of computer-readable media: computer-readable storage media and communication media.

[0096] Computer-readable storage media include volatile and non-volatile, removable and non-removable media implemented by any method or technology for storing information such as computer-readable instructions, data structures, program modules, or other data. Computer-readable storage media include, but are not limited to, RAM, ROM, EEPROM, flash memory or other memory technologies, CD-ROM, DVD, or other optical storage devices, magnetic cassettes, magnetic tapes, disk storage devices or other magnetic storage devices, or any other non-transmission medium that can be used to store information for access by computer devices. In contrast, communication media can embody computer-readable instructions, data structures, program modules, or other data in modulated data signals such as carrier waves or other transmission mechanisms. Computer-readable storage media as defined herein do not include communication media.

[0097] Communication interface 706 is used for exchanging data with other devices, such as via a network, direct connection, etc. Such a communication interface can be one or more of the following: any type of network interface (e.g., a network interface card (NIC)), wired or wireless (such as IEEE 802.11 Wireless LAN (WLAN)) wireless interface, Wi-MAX interface, Ethernet interface, Universal Serial Bus (USB) interface, cellular network interface, Bluetooth. TM Interfaces include near field communication (NFC) interfaces. Communication interface 706 facilitates communication across various network and protocol types, including wired networks (e.g., LAN, cable, etc.) and wireless networks (e.g., WLAN, cellular, satellite, etc.), the Internet, etc. Communication interface 706 can also provide communication with external storage devices (not shown) such as storage arrays, network-attached storage, storage area networks, etc.

[0098] In some examples, a display device 708, such as a monitor, may be included for displaying information and images to the user. Other I / O devices 710 may be devices that receive various inputs from the user and provide various outputs to the user, and may include touch input devices, gesture input devices, cameras, keyboards, remote controls, mice, printers, audio input / output devices, and so on.

[0099] The technologies described herein can be supported by these various configurations of computer device 700, and are not limited to specific examples of the technologies described herein. For example, the functionality can also be implemented wholly or partially on a “cloud” using a distributed system. A cloud includes and / or represents a platform for resources. The platform abstracts the underlying functionality of the cloud’s hardware (e.g., servers) and software resources. Resources may include applications and / or data that can be used when performing computational processing on a server remote from computer device 700. Resources may also include services provided via the Internet and / or via subscriber networks such as cellular or Wi-Fi networks. The platform can abstract resources and functionality to connect computer device 700 to other computer devices. Therefore, the implementation of the functionality described herein can be distributed throughout the cloud. For example, the functionality can be implemented partly on computer device 700 and partly through a platform that abstracts the functionality of the cloud.

Claims

1. An address mapping method for GPU emulation, characterized in that, The method includes: The host machine requests a first virtual address space through its kernel interface, wherein the device simulation model used for GPU emulation runs on the host machine. A second virtual address space is specified for the device simulation model. The second virtual address space is continuous within a specified address limit starting from a specified base address. The address limit does not exceed the size of the first virtual address space that has been applied for, and the second virtual address space does not overlap with the first virtual address space. A first mapping relationship is established between the second virtual address space and the first virtual address space, wherein the second virtual address in the second virtual address space is mapped to the first virtual address in the first virtual address space through an offset operation, and the offset operation is performed on the basis of the base address and the starting address of the first virtual address space. In response to a request for PCIe enumeration operation issued by the native driver during loading, the PCIe enumeration operation is masked, and information associated with the second virtual address space is returned, wherein the PCIe enumeration operation is used to obtain a physical address via the PCIe bus; and In response to a read / write request issued by any of the native driver's user mode, kernel mode, or device emulation model during the GPU emulation process, the read / write request is redirected to the first virtual address space based on the first mapping relationship.

2. The method according to claim 1, characterized in that, The method further includes: Determine whether a memory release instruction for the second virtual address space was intercepted; and In response to the interception of the memory release instruction, the memory release instruction is suspended and a memory release success message is returned, wherein the memory release of the first virtual address space based on the first mapping relationship is masked.

3. The method according to claim 1 or 2, characterized in that, There is a second mapping relationship between the first virtual address space and the first physical address space. The first physical address space indicates the physical address of the memory unit of the host machine, and the second mapping relationship is recorded in the page table of the host machine.

4. The method according to claim 3, characterized in that, In response to a read / write request issued by the user space of the native driver during the GPU emulation process, the method further includes: The first virtual address corresponding to the read / write request is converted to the target physical address via the second mapping relationship; and The target physical address is written into the host machine's page table, wherein the host machine's memory units are accessed based on the host machine's page table.

5. The method according to claim 1 or 2, characterized in that, In response to a read / write request issued by the kernel mode of the native driver during the GPU emulation process, the method further includes: I / O mapping operations are masked so that the first virtual address corresponding to the read / write request can be directly accessed.

6. The method according to claim 1 or 2, characterized in that, In response to the device simulation model issuing a read / write request during the GPU simulation, the method further includes: After the read / write request is redirected to the first virtual address space, the first virtual address corresponding to the read / write request is accessed directly.

7. The method according to claim 1 or 2, characterized in that, The offset operation includes subtracting the base address from the second virtual address and adding the starting address of the first virtual address space.

8. The method according to claim 1 or 2, characterized in that, The native driver's user mode and kernel mode request the allocation or release of the second virtual address in the second virtual address space via a unified address management entry point, which is located in the kernel mode.

9. An address mapping device for GPU emulation, characterized in that, The device includes: The first allocation module is configured to request a first virtual address space through the kernel interface of the host machine, wherein the device simulation model used for the GPU simulation runs on the host machine; The second allocation module is configured to specify a second virtual address space for the device simulation model. The second virtual address space is continuous within a specified address limit starting from a specified base address, wherein the address limit does not exceed the size of the first virtual address space that has been applied for, and the second virtual address space does not overlap with the first virtual address space. The mapping construction module is configured to establish a first mapping relationship between the second virtual address space and the first virtual address space, wherein the second virtual address in the second virtual address space is mapped to the first virtual address in the first virtual address space through an offset operation, and the offset operation uses the base address as the offset reference and performs linear address conversion based on the starting address of the first virtual address space; The first shielding module is configured to, in response to a request for PCIe enumeration operation issued by the native driver during loading, shield the PCIe enumeration operation and return information associated with the second virtual address space, wherein the PCIe enumeration operation is used to obtain a physical address via the PCIe bus; and The redirection module is configured to respond to read / write requests issued by any of the native driver's user mode, kernel mode, and device emulation model during the GPU emulation process, and redirect the read / write requests to the first virtual address space based on the first mapping relationship.

10. A computer device, characterized in that, The computer device includes: At least one processor; A memory having a computer program stored thereon, wherein, when executed by the at least one processor, the computer program causes the at least one processor to perform the method of any one of claims 1-8.

11. A computer-readable storage medium, characterized in that, The computer-readable storage medium stores a computer program that, when executed by a processor, causes the processor to perform the method of any one of claims 1-8.

12. A computer program product, characterized in that, The computer program product includes a computer program that, when executed by a processor, causes the processor to perform the method of any one of claims 1-8.

Images