Splitting the virtual graphics processing unit (GPU) driver between the host operating system and the guest operating system.

Abstract

Generally, the following techniques are described for providing a virtual graphics processing unit driver: receiving one or more graphics commands from an application in the guest process in the user mode of the guest process executed by the computing system; triggering an operating system call in response to one or more graphics commands in the user mode of the guest process; translating the operating system call into a first virtual buffer in the kernel mode of the guest process; translating the first virtual buffer into an operating system call in the user mode of the host process executed by the computing system; and sending the operating system call to the graphics processing unit driver in the kernel mode of the host process in the user mode of the host process.

Description

Technical Field

[0001] This application claims the benefit of U.S. Patent Application No. 18 / 453,092, filed Aug. 21, 2023, the entire content of which is incorporated herein by reference.

Background Art

[0002] A computing system can support (or, alternatively, host) a virtual environment in which virtual instances (such as so-called virtual machines (VMs)) are executed as separate processes that share the computing hardware (e.g., memory, central processing unit (CPU), graphics processing unit (GPU), interface) underlying the computing system in a restricted manner that limits interactions between the VMs. Due to the constraints provided by the virtual environment to limit VM interactions, each VM may appear to be a distinct computing system to both other VMs and other physical computing devices (even when the VMs share the same underlying computing hardware). Such restrictions provided by the virtual environment can result in enhanced security (since a maliciously configured VM is restricted from directly accessing other VMs), improved reliability of the host computing system (assuming that a failure of one VM does not affect the underlying host computing system), and, in other respects, can make it possible to increase the utilization of available computing resources while reducing the above security concerns.

[0003] In some cases, a virtual environment can allow a VM to run a guest operating system (OS) different from the host OS run by the host computing system. The guest OS can run different applications that are not available for the host OS. These different applications could include, for example, various video games optimized for the guest OS. Therefore, the VM could emulate (perhaps referred to as "emulator") the native hardware architecture required to run the guest OS (along with the video game), thereby allowing the video game to run within a different hardware architecture than that running the host OS. [Overview of the project]

[0004] Generally, the technology of this disclosure allows a portion of a GPU driver in a host process to be exposed to a GPU driver in a guest process. In one embodiment, a guest kernel-mode virtual input / output (I / O) driver (e.g., a GPU driver backend in the guest) is coupled with a host user-mode virtual I / O device (e.g., a GPU driver frontend in the host).

[0005] In embodiments having a first type of host OS (e.g., Microsoft® Windows®) and a second type of guest OS (e.g., Android®), the technology of the present disclosure provides moving the user-mode portion of the GPU driver (e.g., the front-end) from the host OS to the guest OS. Instead of serializing the graphics APIs, those graphics APIs may call the guest user-mode GPU driver directly, with only communication over a channel between the guest kernel-mode virtual I / O driver and the host user-mode virtual I / O device being serialized. In embodiments where the host OS is Microsoft Windows, this channel is called the Windows Display Driver Model (WDDM), which is simpler and less redundant, and therefore, when used in this manner, reduces the serialization overhead for handling the graphics APIs.

[0006] Therefore, the described technology can improve the operation of the host computing system itself. Specifically, by performing an improved graphics rendering process, the host computing system can facilitate more optimized execution (in terms of latency, utilization of computing resources such as processor cycles, GPU cycles, memory, memory bandwidth, etc., and associated power consumption) through potential improvements over the technology provided by existing graphics APIs and GPU drivers. This, in turn, results in a better experience for users of applications running on the host computing system (e.g., faster graphics display).

[0007] In one example, various aspects of the technology relate to a method that includes: receiving one or more graphics commands from an application in a guest process in user mode of a guest process running on a computing system; triggering an operating system call in response to one or more graphics commands in user mode of the guest process; translating the operating system call into a first virtual buffer in kernel mode of the guest process; translating the first virtual buffer into an operating system call in user mode of a host process running on a computing system; and sending the operating system call to a graphics processing unit driver in kernel mode of the host process in user mode of the host process.

[0008] In other examples, various aspects of the technology relate to a device comprising memory for storing a host operating system and processing circuits for executing the host operating system, wherein the host operating system includes a guest process and a host process that, in the user mode of the guest process, receives one or more graphics commands from an application in the guest process; in the user mode of the guest process, triggers an operating system call in response to one or more graphics commands; in the kernel mode of the guest process, translates the operating system call into a first virtual buffer; in the user mode of the host process executed by the computing system, translates the first virtual buffer into an operating system call; and in the user mode of the host process, sends the operating system call to a graphics processing unit driver in the kernel mode of the host process.

[0009] In other examples, various aspects of the technology relate to a non-temporary computer-readable storage medium in which instructions are stored, and which, when executed, cause one or more processors to execute a host operating system, the host operating system including a guest process and a host process which, in the user mode of the guest process, receives one or more graphics commands from an application in the guest process; in the user mode of the guest process, triggers an operating system call in response to one or more graphics commands; in the kernel mode of the guest process, translates the operating system call into a first virtual buffer; in the user mode of the host process executed by the computing system, translates the first virtual buffer into an operating system call; and in the user mode of the host process, sends the operating system call to a graphics processing unit driver in the kernel mode of the host process.

[0010] Further examples disclose systems that include various means for performing each of the operations described herein.

[0011] Details of one or more embodiments are described in the accompanying drawings and the following description. Other features, purposes, and advantages of this disclosure will become apparent from the description and drawings, as well as from the claims. [Brief explanation of the drawing]

[0012] [Figure 1] This figure shows an exemplary host computing system that implements various forms of GPU driver partitioning according to various aspects of the technology described in this disclosure. [Figure 2] This figure shows an exemplary host computing system that implements various forms of GPU driver partitioning according to various aspects of the technology described in this disclosure. [Figure 3]This figure shows the interaction between a guest process and a host process in various aspects of the technology described in this disclosure. [Figure 4] This diagram illustrates the transmission of graphics command calls from a guest process to a host process using various aspects of the technology described in this disclosure. [Figure 5] This figure illustrates the transmission of graphics command responses from a host process to a guest process using various aspects of the technology described in this disclosure. [Modes for carrying out the invention]

[0013] Figure 1 shows an exemplary host computing system 100 that implements various forms of GPU driver partitioning according to various aspects of the technology described herein. An application running in a guest process (such as a video game) typically makes calls to display graphic information on the host computing system's display. Graphics virtualization typically involves serializing graphics application programming interfaces (APIs) (e.g., OpenGL, Vulkan, or D3D12 for rendering 2D and 3D vector graphics) across the host OS hypervisor boundary and replaying those APIs in the host process. This approach is usually taken because these graphics APIs are independent of the host computing system hardware, host OS, and / or guest OS. While these APIs are well-defined, they are often redundant and complex, and the serialization and deserialization processes of these APIs consume considerable overhead. This disclosure describes an approach that can improve the efficiency of sending graphics command API calls (and responses) between the guest process and the host process by moving the user-mode portion of the GPU driver from the host process to the guest process.

[0014] Operating systems typically have two basic modes in which they can execute programs: user mode and kernel mode. All user processes operate under user mode. In user mode, processes can access memory directly without having to make system calls. However, access via virtual memory and paging is restricted, so each user-mode process can only access a subset of physical memory through a virtual address range controlled by the kernel. User-mode processes generally cannot access other hardware resources. When a computing system starts up, it begins in kernel mode. Kernel mode allows direct access to all underlying hardware resources. In kernel mode, all memory addresses are accessible, and all processor instructions are executable.

[0015] As shown in Figure 1, the host computing system 100 may represent any type of computing system capable of running a virtual environment that supports the execution of independent and separate virtual machines through the same underlying hardware of the host computing system 100 in an isolated (or in other words, permission-restricted) manner. Examples of the host computing system 100 may include servers, distributed servers, personal computers, workstations, self-learning machines (e.g., neural networks), mobile devices (e.g., mobile phones, smartphones, other cellular handsets, tablet computers), internet appliances, smart televisions (TVs), digital versatile disc (DVD) players, compact disc (CD) players, digital video recorders (DVRs), Blu-ray® players, video game consoles, personal video recorders, set-top boxes, headsets (e.g., Extended Reality (XR) headsets (including augmented reality (AR) headsets, virtual reality (VR) headsets, mixed reality (MR) headsets, artificial intelligence (AI) enabled headsets, etc.)), smartwatches, AI pins, or other wearable devices, or any other type of computing device.

[0016] The host computing system 100 may include processor circuits for executing instructions to perform processing. As used herein, a processor circuit is defined to include (i) one or more special-purpose electrical circuits structured to perform a specific operation and comprising one or more semiconductor-based logic devices (e.g., electrical hardware implemented by one or more transistors), and / or (ii) one or more general-purpose semiconductor-based electrical circuits programmed with instructions to perform a specific operation and comprising one or more semiconductor-based logic devices (e.g., electrical hardware implemented by one or more transistors). Examples of processor circuits include programmed microprocessors, field-programmable gate arrays (FPGAs) capable of instantiating instructions, central processing units (CPUs), graphics processor units (GPUs), digital signal processors (DSPs), XPUs, or microcontrollers, and integrated circuits such as application-specific integrated circuits (ASICs). For example, an XPU may be implemented by a heterogeneous computing system comprising multiple types of processor circuits (e.g., one or more FPGAs, one or more CPUs, one or more GPUs, one or more DSPs, and / or combinations thereof), and by an application programming interface (API(multiple)) that can assign computing tasks to one or more of the multiple types of processing circuits best suited to performing the computing task(s).

[0017] As shown in the example in Figure 1, the host computing system 100 may run a host operating system (OS) 102. For the sake of ease of illustration, although not shown in the example in Figure 1, the host computing system 100 may also include a processor circuit, various controllers including one or more network interface cards (NICs), storage (e.g., cache, random access memory (RAM) (including variations thereof), memory such as flash memory, solid-state drives, hard disk drives, and other storage media), and other hardware to support the execution of the host OS 102.

[0018] The host OS 102 may be referred to as the “host” in the sense that it supports the execution of a virtual environment that facilitates the hosting of the guest process 120. The host OS 102 may include a host process (e.g., a hypervisor) 140 that manages the virtual environment with respect to managing access to the underlying hardware of the host computing system 100. The host process 140 may, for example, allocate storage from the underlying storage for use only by the guest VM 105, reserve processor cycles of one or more CPUs (or CPU cores) for use by the guest VM 105, reserve GPU cycles / pipelines for use by the guest VM 105, and so on. The host process 140 may then schedule the execution of the guest VM 105 through the underlying processing circuits of the host computing system 100, while maintaining restrictions through permissions that limit inter-VM interactions and effectively isolate the VM so as not to affect other VMs, the host OS 102, and / or the host computing system 100. The host process 140 can implement these restrictions to improve security with respect to the VM (from being tampered with by the host OS 102 and other VMs), as well as with respect to the host OS 102 and the host computing system 100.

[0019] As further illustrated in the example in Figure 1, the host OS 102 may include a UI module 116 that can manage user interaction with the host computing system 100. The UI module 116 may receive one or more instructions from the user, such as voice input or gesture input, when the user interacts with a user interface presented by UI hardware components (often indicated as "UIC"). The UI module 116 may also present graphics content rendered via a graphics software stack for consumption by the user of the host computing system 100.

[0020] As described above, the virtual environment may allow the guest VM 105 to run a guest process 120 separate from the host process 140 run by the host computing system 100. The guest process 120 may allow the execution of different applications (e.g., application 133) that are not available for execution by the host process 140. In other words, application 133 is native to the guest process 120 but not natively executable by the host process 140. These different applications may include various video games optimized for the guest process 120 (and for illustrative purposes, application 133 is assumed to be a video game and may be referred to as "video game 133," but application 133 may perform any desired function of displaying images on the display screen of the host computing system 100 using graphics commands). Therefore, guest VM105 emulates the native hardware architecture required to run guest process 120 (along with video game 133), thereby allowing video game 133 to run within a different hardware architecture (e.g., x86 hardware architecture) running the host OS102.

[0021] During operation, host process 140 may start the execution of guest process 120 to support the execution of application 133. Application 133 may be "native" in the sense that application 133 is programmed according to the same hardware architecture (e.g., a processing architecture such as a RISC-based architecture) on which guest process 120 is configured to execute.

[0022] Guest process 120 may interface with host process 140 to start the execution of graphics rendering operations as a process separate from guest process 120, and thus may have different permissions to reduce security risks of host computing system 100 and / or host OS 102.

[0023] As described in this disclosure, the GPU driver running in the guest process may be partitioned into two parts: a guest user-mode GPU driver 142 and a guest kernel-mode virtual I / O driver 144. The corresponding GPU driver running in host process 140 within host OS 102 of host computing system 100 may also be partitioned into two parts: a host user-mode virtual I / O device 146 and a host kernel-mode GPU driver 147.

[0024] Guest process  120 may represent a guest graphics software stack that includes guest user-mode GPU driver 142 and guest kernel-mode virtual I / O driver 144. Host process 140 may represent a host graphics software stack that includes host user-mode virtual I / O device 146 and host kernel-mode GPU driver 147 that executes and maps the OS API stream 154 received from guest kernel-mode virtual I / O device 144 according to a standardized graphics API to render the graphics content stored in GPU memory 148B.

[0025] Guest process 120 includes application 133. Application 133 may issue a graphics command API call to virtual user mode GPU driver 142. Generally, guest user mode GPU driver 142 receives a graphics API call from application 133 and issues an OS API call to guest kernel mode virtual I / O driver 144. Guest kernel mode virtual I / O driver 144 converts the OS API call into a virtual I / O command buffer and sends a pointer to the virtual I / O command buffer to host user mode virtual I / O device 146. Host user mode virtual I / O device 146 reconverts the virtual I / O command buffer into an OS API call and issues an OS API call to host kernel mode GPU driver 147. Host kernel mode GPU driver receives the OS API call, communicates with the GPU hardware, and executes the command in shared memory.

[0026] The guest kernel-mode virtual I / O driver 144 may configure the guest process 120 to support memory mapping between the guest process 120 and the host process 140 in order to facilitate the execution of a graphical rendering API used by the application 133 to render graphics (another term referring to graphics content). The guest kernel-mode virtual I / O driver 144 may configure the host process 120 either directly (to make the mapped GPU memory 148A available to the guest process 120) or indirectly via the host OS hypervisor 104. The guest kernel-mode virtual I / O driver 144 may also interface with the host user-mode virtual I / O device 146 to configure mapped GPU memory 148B of the host computing system 100 that references the same physical memory as the mapped GPU memory 148A. In this way, the same physical underlying memory of the host computing system 100 is "mapped" between the guest process 120 and the host process 140 (for example, by pointers or other logical abstractions that facilitate access to the same underlying memory).

[0027] By mapping memory in this way, application 133 may be able to output various graphics elements necessary for rendering graphics (e.g., meshes, point clouds, textures, images, videos, etc.) to the mapped GPU memory 148A. The host user-mode virtual I / O device 146 may receive an OS API stream 154 that references the mapped GPU memory 148A, but for memory mapping purposes, the host user-mode virtual I / O device 146 (running as a separate and independent host process 140 in the isolated virtual machine 105B) may instead execute the OS API stream 154 that references the mapped GPU memory 148B via the host kernel-mode GPU driver 147. In this way, the host graphics software stack can be isolated to a separate virtual machine while still maintaining the appropriate memory types required by the standardized graphics API.

[0028] The techniques described herein may improve the operation of the host computing system 100 itself. Specifically, the host computing system 100 may be able to identify when the host process 140 can be run as an isolated and restricted process, potentially reducing security risks that may arise if the guest OS 132 allows the execution of a malicious application. By running the host process 140 separately, the host computing system 100 may also facilitate more optimized execution (with respect to latency, utilization of computing resources such as processor cycles, GPU cycles, memory, memory bandwidth, etc., and associated power consumption) through potential improvements provided by a standardized graphics API.

[0029] Figure 2 shows exemplary host computing systems that implement various modes of partitioning the GPU driver according to various aspects of the technology described herein. Figure 2 shows only one example of host computing system 200, and many other examples of host computing system 200 may be used in other cases and may include a subset of the components included in the exemplary host computing system 200 or additional components not shown in Figure 2. Host computing system 200 may represent one example of host computing system 100 shown in the example of Figure 1.

[0030] As shown in the example in Figure 2, the host computing system 200 includes one or more processors 260, one or more storage devices 262, one or more communication units 264, and one or more user interface components (UICs) 266, each of which is interconnected by a communication channel 268. The processors 260 can implement the functions of a processor circuit and / or execute instructions associated with the host computing system 200. Examples of processors 260 include application processors, display controllers, auxiliary processors, one or more sensor hubs, and any other hardware configured to function as a processor, processing unit, or processing device, including a CPU (which may have one or more "cores") and the GPU described above. In this regard, the processor 260 may represent both a CPU and a GPU, which may be integrated (meaning they are packaged into a shared CPU / GPU chip architecture and often share integrated memory, buffers, memory buses, etc.) or dedicated (meaning the GPU is separate from the CPU chip architecture and therefore does not inherently share memory, buffers, memory buses, etc.).

[0031] The memory device 262 may represent one or more memories and / or storage devices configured to store information for processing during the operation of the host computing device 200. In some examples, the memory device 262 is temporary memory, meaning that the primary purpose of the memory device 262 is not long-term storage. The memory device 262 may be configured as volatile memory for short-term storage of information, and therefore, when the power is turned off, the stored contents may not be retained. Examples of volatile memory include random-access memory (RAM), dynamic random-access memory (DRAM), static random-access memory (SRAM), and other forms of volatile memory known in the art.

[0032] The storage device 262 may, in some examples, include one or more machine-readable storage media. The storage device 262 may include one or more non-temporary machine-readable storage media. The storage device 262 may be configured to store larger amounts of information than is typically stored by volatile memory. The storage device 262 may be further configured as a non-volatile memory space for long-term storage of information, where the information can be retained after power on / off cycles. Examples of non-volatile memory include magnetic hard disks, optical disks, flash memory, or electrically programmable memory (EPROM) or electrically erasable and programmable memory (EEPROM).

[0033] The storage device 262 may store program instructions and / or information (e.g., data) associated with the host OS 202 (an example being host OS 102), including the host process 240 (shown in Figure 2, representing an example of host process 140), the UI module 116 (not shown in Figure 2), and any other software executable by the processor 260. The storage device 262 may include memory configured to store data or other information associated with the host OS 202 (an example being host OS 102), including the host process 240 (shown in Figure 2, representing an example of host process 140), the UI module 116 (not shown in Figure 2), and any other software executable by the processor 260.

[0034] The guest process 220 (including application 233, guest user-mode GPU driver 242, and guest kernel-mode virtual I / O driver 244) may be stored separately in the storage device 262, again logically indicated to show that the components of the guest process 220 run as part of different separate processes (as described above with respect to the example in Figure 1).

[0035] Guest process 220 may represent an example of guest process 120, guest user-mode GPU driver 242 and guest kernel-mode virtual I / O driver 244 represent examples of guest user-mode GPU driver 142 and guest kernel-mode virtual I / O driver 144, respectively, and application 233 represents an example of application 133. In this regard, these components in Figure 2 are similar to or may be the same as the components described above with respect to Figure 1, but may be shown in the context of an exemplary underlying hardware architecture of the host computing system 200, where, for illustrative purposes, the hardware architecture is assumed to conform to an x86 processing architecture (including a motherboard, memory, and / or other supporting components for implementing the x86 hardware architecture necessary to implement virtualization in the manner described herein).

[0036] A communication unit 264 may represent one or more units configured to communicate with an external device over one or more wired and / or wireless networks by transmitting and / or receiving network signals over one or more networks. Examples of communication units 264 include network interface cards (e.g., Ethernet® cards), optical transceivers, radio frequency transceivers, Global Positioning Satellite (GPS) receivers, cellular transceivers, or any other type of device capable of transmitting and / or receiving data. Other examples of communication units 264 may include shortwave radios, cellular data radios, wireless network radios, and Universal Serial Bus (USB) controllers.

[0037] UIC266 can be implemented using a variety of technologies. For example, UIC266 can function as an input device using a presence-aware input screen, such as a resistive touchscreen, surface acoustic wave touchscreen, capacitive touchscreen, projected capacitive touchscreen, pressure-sensitive screen, acoustic pulse-recognition touchscreen, or other presence-aware display technology. As further illustrated in the example in Figure 2, UIC266 may include one or more input components 270 and one or more output components 272.

[0038] One or more input components 270 of the host computing system 200 may receive input. Examples of inputs include haptic input, voice input, and video input. One example of an input component 270 may include a presence-aware input device (e.g., a touch-sensitive screen, a presence-aware display), a mouse, a keyboard, a voice response system, a video camera, a microphone, or any other type of device for detecting input from a human or machine. In some examples, an input component 270 may include one or more position sensors (GPS component, Wi-Fi component, cellular component), one or more temperature sensors, one or more motion sensors (e.g., an accelerometer, a gyroscope), one or more pressure sensors (e.g., a barometer), one or more ambient light sensors, and one or more other sensors (e.g., a microphone, a camera, an infrared proximity sensor, a hygrometer, etc.). Other sensors may include, to give some other non-limiting examples, a heart rate sensor, a magnetometer, a glucose sensor, a hygrometer sensor, an olfactory sensor, a compass sensor, a step counter sensor.

[0039] One or more output components 272 of the host computing system 200 may generate outputs. Examples of outputs include haptic outputs, audio outputs, and video outputs. One example of an output component 272 of the host computing system 200 may include a portable storage device (PSD), a sound card, a video graphics adapter card, a speaker, a cathode ray tube (CRT) monitor, a liquid crystal display (LCD), an organic light-emitting diode (OLED) display, or any other type of device for generating outputs to a human or machine.

[0040] While UIC266 is shown as an internal component of the host computing system 200, it may also represent an external component that shares a data path with the host computing system 200 to transmit and / or receive inputs and outputs. For example, in one example, UIC266 represents an embedded component of the host computing system 200 located within and physically connected to an external package of the host computing system 200 (e.g., a display on a mobile phone). In another example, UIC266 represents an external component of the host computing system 200 located outside the package or housing of the host computing system 200 and physically separated from the package or housing of the host computing system 200 (e.g., a monitor, projector, etc., that shares a wired and / or wireless data path with the host computing system 200).

[0041] Figure 3 illustrates the interaction between a guest process 120 and a host process 140 in various aspects of the technology described herein. In operation 302, application 133 makes one or more graphics command API calls to guest user-mode GPU driver 142. In response to at least one of the one or more graphics API calls received from application 133, guest user-mode GPU driver 142 triggers an OS API call (some graphics API calls do not result in the triggering of an OS API call), and in operation 304, makes an OS API call to guest kernel-mode virtual I / O driver 144. In operation 306, guest kernel-mode virtual I / O driver 144 translates the OS API call into a virtual I / O (virtio) command buffer stored in one or more of the storage devices 262. In operation 308, guest kernel-mode virtual I / O driver 144 sends the addresses of the virtio command buffer and the virtio response buffer to host user-mode virtual I / O driver 146. Next, the guest kernel-mode virtual I / O driver 144 blocks until the host process 140 returns a response. In operation 310, the host user-mode virtual I / O driver 146 translates the OS API call from the virtio command buffer. In operation 312, the host user-mode virtual I / O driver 146 makes an OS API call to the host kernel-mode GPU driver 147.

[0042] Optionally, the host kernel-mode GPU driver 147 may then send one or more graphics commands to the GPU (not shown in Figure 3) based at least in part on OS API calls. Optionally, in response to receiving graphics commands, the GPU may send one or more responses back to the host kernel-mode GPU driver 147.

[0043] When an OS API call is executed, the host kernel-mode GPU driver 3147, in operation 314, sends an OS API response (which may optionally include one or more graphics command responses) to the host user-mode virtual I / O driver 146. The host user-mode virtual I / O driver 146, in operation 316, converts the OS API response to a virtio response buffer and, in operation 318, sends the address of the virtio response buffer to the guest kernel-mode virtual I / O driver 144. The guest kernel-mode virtual I / O driver 144 then, in operation 320, converts the OS API response from the virtio response buffer and, in operation 322, sends the OS API response to the guest user GPU driver 142. Finally, in operation 324, the guest user-mode GPU driver 142 converts the OS API response to one or more graphics command API responses and, in operation 324, sends the graphics command API responses to the application 133.

[0044] The sequence above illustrates the processing of synchronous graphics command API calls, but some graphics command API calls can be processed asynchronously.

[0045] Figure 4 illustrates the transmission of graphics commands from a guest process to a host process according to various aspects of the technology described herein. In block 402 of Method 400, the user mode of the guest process 120 (e.g., guest user-mode GPU driver 142) receives one or more graphics commands from application 133. In block 404, the user mode of the guest process 120 (e.g., guest user-mode GPU driver 142) triggers an operating system call (e.g., to guest kernel-mode virtual I / O driver 144) in response to one or more graphics commands. In block 406, the kernel mode of the guest process 120 (e.g., guest kernel-mode virtual I / O driver 144) translates the operating system call into a virtual I / O command buffer. In block 408, the kernel mode of the guest process 120 (e.g., guest kernel-mode virtual I / O driver 144) sends the address of the virtual I / O command buffer to the user mode of the host process 140 (e.g., host user-mode virtual I / O driver 146). In block 410, the user mode of the host process 140 (e.g., the host user mode virtual I / O driver 146) translates the virtual I / O command buffer into an operating system call. In block 412, the user mode of the host process 140 (e.g., the host user mode virtual I / O device 146) sends the operating system call to the kernel mode of the host process (e.g., the host kernel mode GPU driver 147).

[0046] Figure 5 illustrates the transmission of graphics command responses from a host process to a guest process according to various embodiments of the technology described herein. In block 502 of Method 500, the kernel mode of the host process 140 (e.g., the host kernel-mode GPU driver 147) sends an operating system call response to a virtual I / O device in the user mode of the host process (e.g., the host user-mode virtual I / O device 146). In block 504, the user mode of the host process 140 (e.g., the host user-mode virtual I / O driver 146) translates the operating system call into a virtual I / O response buffer. In block 506, the user mode of the host process 140 (e.g., the host user-mode virtual I / O device 146) sends the address of the virtual I / O response buffer to the kernel mode of the guest process 120 (e.g., the guest kernel-mode virtual I / O driver 144). In block 508, the kernel mode of the guest process 120 (e.g., the guest kernel-mode virtual I / O driver 144) translates the virtual I / O response buffer into an operating system call response. In block 510, the kernel mode of the guest process 120 (e.g., the guest kernel mode virtual I / O driver 144) sends an operating system call response to the GPU driver in user mode of the guest process 120 (e.g., the guest user mode GPU driver 142). In block 512, the user mode of the guest process 120 (e.g., the guest user mode GPU driver 142) sends one or more graphics command responses to the application 133.

[0047] Therefore, the techniques described herein improve the operation of the host computing system 100 by reducing the amount of API calls processed between the guest process 120 and the host process 140.

[0048] In this way, various aspects of the technology described herein may enable the following embodiments.

[0049] Embodiment 1 is a method that includes: receiving one or more graphics commands from an application in a guest process in user mode of a guest process executed by a computing system; triggering an operating system call in response to the one or more graphics commands in user mode of the guest process; translating the operating system call into a first virtual buffer in kernel mode of the guest process; translating the first virtual buffer into the operating system call in user mode of a host process executed by the computing system; and sending the operating system call to a graphics processing unit driver in kernel mode of the host process in user mode of the host process.

[0050] Example 2. The method according to Example 1, comprising sending the address of the first virtual buffer from the guest process to the host process in response to translating the operating system call to the first virtual buffer.

[0051] Example 3. The method according to Example 1, wherein the guest process emulates a first operating system, the host process executes a second operating system, and the first operating system is different from the second operating system.

[0052] Example 4. The method according to Example 1, wherein the graphics processing unit driver in kernel mode of the host process sends one or more graphics processing unit commands to the graphics processing unit based at least in part on the operating system call.

[0053] Example 5. The method according to Example 4, wherein the graphics processing unit driver in kernel mode of the host process receives one or more responses from the graphics processing unit to one or more graphics processing unit commands.

[0054] Example 6. The method according to Example 1, comprising: sending an operating system call response to a virtual device in the user mode of the host process in the kernel mode of the host process; converting the operating system call response to a second virtual buffer in the user mode of the host process; converting the second virtual buffer to the operating system call response in the kernel mode of the guest process; and sending the operating system call response to a virtual graphics processing unit driver in the user mode of the guest process in the kernel mode of the guest process.

[0055] Example 7. The method according to Example 6, comprising sending one or more graphics command responses to the application in the user mode of the guest process.

[0056] Example 8. The method according to Example 6, comprising sending the address of the second virtual buffer to the guest process in response to translating the operating system call response to the second virtual buffer.

[0057] Embodiment 9 is an apparatus comprising a memory for storing a host operating system and a processing circuit for executing the host operating system, wherein the host operating system includes a guest process and a host process that, in the user mode of the guest process, receive one or more graphics commands from an application of the guest process; in the user mode of the guest process, trigger an operating system call in response to the one or more graphics commands; in the kernel mode of the guest process, translate the operating system call into a first virtual buffer; in the user mode of the host process executed by the computing system, translate the first virtual buffer into the operating system call; and in the user mode of the host process, transmit the operating system call to a graphics processing unit driver in the kernel mode of the host process.

[0058] Example 10. The apparatus according to Example 9, comprising a processor circuit that transmits the address of the first virtual buffer from the guest process to the host process in response to translating the operating system call to the first virtual buffer.

[0059] Example 11. The apparatus according to Example 9, wherein the guest process emulates an operating system different from the host operating system.

[0060] Example 12. The apparatus according to Example 9, further comprising a processor circuit that, by the kernel-mode graphics processing unit driver of the host process, sends one or more graphics processing unit commands to the graphics processing unit based at least in part on the operating system call.

[0061] Example 13. The apparatus according to Example 12, further comprising a processor circuit that receives one or more responses from the graphics processing unit to the one or more graphics processing unit commands by the kernel-mode graphics processing unit driver of the host process.

[0062] Example 14. The apparatus according to Example 9, comprising a processor circuit that, in the kernel mode of the host process, transmits an operating system call response to a virtual device in the user mode of the host process; in the user mode of the host process, converts the operating system call response to a second virtual buffer; in the kernel mode of the guest process, converts the second buffer to the operating system call response; and in the kernel mode of the guest process, transmits the operating system call response to a virtual graphics processing unit driver in the user mode of the guest process.

[0063] Example 15. The apparatus according to Example 14, further comprising the processor circuit that transmits one or more graphics command responses to the application in the user mode of the guest process.

[0064] Example 16. The apparatus according to Example 9, comprising a processor circuit that transmits the address of the second virtual buffer to the guest process in response to translating the operating system call response to the second virtual buffer.

[0065] Embodiment 17 is a non-temporary computer-readable storage medium in which instructions are stored, wherein when the instructions are executed, one or more processors cause a host operating system to execute a host operating system, the host operating system includes a guest process and a host process, the host operating system which, in the user mode of the guest process, receives one or more graphics commands from an application in the guest process, in the user mode of the guest process, triggers an operating system call in response to the one or more graphics commands, in the kernel mode of the guest process, translates the operating system call into a first virtual buffer, in the user mode of the host process executed by the computing system, translates the first virtual buffer into the operating system call, and in the user mode of the host process, transmits the operating system call to a graphics processing unit driver in the kernel mode of the host process.

[0066] Example 18. A non-temporary computer-readable storage medium according to Example 17, which includes stored instructions, the instructions, when executed, cause one or more processors to transmit the address of the first virtual buffer from the guest process to the host process in response to translating the operating system call to the first virtual buffer.

[0067] Example 19. A non-temporary computer-readable storage medium according to Example 17, which includes a stored instruction, the instruction, when executed, causes one or more processors to: send an operating system call response in the kernel mode of the host process to a virtual device in the user mode of the host process; convert the operating system call response into a second virtual buffer in the user mode of the host process; convert the second virtual buffer into the operating system call response in the kernel mode of the guest process; and send the operating system call response to a virtual graphics processing unit driver in the user mode of the guest process in the kernel mode of the guest process.

[0068] Example 20. A non-temporary computer-readable storage medium according to Example 17, which includes stored instructions, which, when executed, cause one or more processors to send one or more graphics command responses to the application in the user mode of the guest process.

[0069] In one or more examples, the described functions may be implemented in hardware, software, firmware, or a combination thereof. If implemented in software, these functions may be stored in or transmitted via a computer-readable medium as one or more instructions or codes and executed by a hardware-based processing unit. The computer-readable medium may include computer-readable storage media corresponding to tangible media such as data storage media, or communication media including any medium that facilitates the transfer of computer programs from one location to another, for example, according to a communication protocol. Thus, the computer-readable medium may generally correspond to (1) non-transient tangible computer-readable storage media, or (2) communication media such as signals or carrier waves. The data storage medium may be any available medium that can be accessed by one or more computers or one or more processors to obtain instructions, codes, and / or data structures for implementing the techniques described herein. A computer program product may include computer-readable media.

[0070] As an example, and not an limitation, such computer-readable storage media may include RAM, ROM, EEPROM, CD-ROM, or other optical disk storage devices, magnetic disk storage devices, or other magnetic storage devices, flash memory, or any other media that can be used to store desired program code in the form of instructions or data structures and that are accessible by a computer. Also, any connection is properly called computer-readable media. For example, if instructions are transmitted from a website, server, or other remote source using coaxial cable, fiber optic cable, twisted pair, digital subscriber line (DSL), or wireless technologies such as infrared, radio, and microwave, then coaxial cable, fiber optic cable, twisted pair, DSL, or wireless technologies such as infrared, radio, and microwave are included in the definition of media. However, it should be understood that computer-readable storage media and data storage media do not include connections, carriers, signals, or other temporary media, but instead refer to non-temporary, tangible storage media. As used herein, the terms "disk" and "disc" include compact discs (CDs), laser discs, optical discs, digital multipurpose discs (DVDs), floppy disks (registered trademark), and Blu-ray discs, where a "disk" typically reproduces data magnetically, and a "disc" reproduces data optically using a laser. Any combination of the above is also included in the scope of computer-readable media.

[0071] Instructions may be executed by one or more processors, such as one or more digital signal processors (DSPs), general-purpose microprocessors, application-specific integrated circuits (ASICs), field-programmable logic arrays (FPGAs), or other equivalent integrated or discrete logic circuits. Therefore, the term “processor” as used herein may refer to any of the aforementioned structures or any other structure suitable for implementing the technology described herein. Furthermore, in some embodiments, the functions described herein may be provided within dedicated hardware and / or software modules. The technology can also be fully implemented in one or more circuits or logic elements.

[0072] The technology of this disclosure can be implemented in a variety of devices or apparatus, including wireless handsets, integrated circuits (ICs), or sets of ICs (e.g., chipsets). While this disclosure describes various components, modules, or units to highlight the functional aspects of devices configured to perform the disclosed technology, implementation by different hardware units is not necessarily required. Rather, as described above, the various units may be combined within hardware units, or they may be provided by a collection of interoperating hardware units, including one or more processors as described above, in combination with appropriate software and / or firmware.

[0073] Various aspects of this disclosure are described. These and other aspects are included in the following claims.

Claims

1. In user mode of a guest process executed by a computing system, the system receives one or more graphics commands from an application in the guest process. In the user mode of the guest process, trigger an operating system call in response to one or more graphics commands. In the kernel mode of the guest process, the operating system call is translated into a first virtual buffer, In the user mode of the host process executed by the computing system, the first virtual buffer is converted into the operating system call, A method comprising sending the operating system call from the user mode of the host process to a graphics processing unit driver running in the kernel mode of the host process.

2. The method according to claim 1, comprising sending the address of the first virtual buffer from the guest process to the host process in response to translating the operating system call to the first virtual buffer.

3. The method according to any one of claims 1 to 2, wherein the guest process emulates a first operating system, the host process executes a second operating system, and the first operating system is different from the second operating system.

4. The method according to any one of claims 1 to 3, comprising sending one or more graphics processing unit commands to the graphics processing unit based at least in part on the operating system call by the kernel-mode graphics processing unit driver of the host process.

5. The method according to claim 4, further comprising the host process receiving one or more responses from the graphics processing unit to one or more graphics processing unit commands by the kernel-mode graphics processing unit driver.

6. The host process, in its kernel mode, sends an operating system call response to a virtual device in the host process's user mode. In the user mode of the host process, the operating system call response is converted into a second virtual buffer. In the kernel mode of the guest process, the second virtual buffer is converted into the operating system call response, The method according to any one of claims 1 to 5, comprising sending the operating system call response to a virtual graphics processing unit driver in user mode of the guest process in the kernel mode of the guest process.

7. The method according to claim 6, comprising sending one or more graphics command responses to the application in the user mode of the guest process.

8. The method according to claim 6, comprising sending the address of the second virtual buffer to the guest process in response to translating the operating system call response to the second virtual buffer.

9. Memory for storing the host operating system, A device comprising a processing circuit for executing the host operating system, The aforementioned host operating system is In the user mode of the guest process, receive one or more graphics commands from the application of the guest process, In the user mode of the guest process, trigger an operating system call in response to one or more graphics commands. In the kernel mode of the guest process, the operating system call is translated into a first virtual buffer, In the user mode of the host process executed by the computing system, the first virtual buffer is converted into the operating system call, A device including a guest process and a host process that perform the following actions in the user mode of the host process: sending the operating system call to a graphics processing unit driver running in the kernel mode of the host process.

10. The apparatus according to claim 9, further comprising a processor circuit that transmits the address of the first virtual buffer from the guest process to the host process in response to translating the operating system call into the first virtual buffer.

11. The apparatus according to any one of claims 9 to 10, wherein the guest process emulates an operating system different from the host operating system.

12. The apparatus according to any one of claims 9 to 12, further comprising a processor circuit that transmits one or more graphics processing unit commands to a graphics processing unit based at least partially on the operating system call by the graphics processing unit driver in kernel mode of the host process.

13. The apparatus according to claim 12, further comprising the processor circuit that receives one or more responses to one or more graphics processing unit commands from the graphics processing unit by the kernel-mode graphics processing unit driver of the host process.

14. The host process, in its kernel mode, sends an operating system call response to a virtual device in the host process's user mode. In the user mode of the host process, the operating system call response is converted into a second virtual buffer. In the kernel mode of the guest process, the second virtual buffer is converted into the operating system call response, The apparatus according to any one of claims 9 to 13, further comprising a processor circuit that performs the following: sending the operating system call response to a virtual graphics processing unit driver in user mode of the guest process in kernel mode of the guest process.

15. A non-temporary computer-readable storage medium having stored instructions, wherein, when executed, the instructions cause one or more processors to perform any of the methods according to claims 1 to 8.

Images