Container access to graphics processing unit resources

Abstract

Systems and methods for container access to graphics processing unit (GPU) resources are disclosed herein. In some embodiments, a computing system can include a physical GPU and a kernel mode driver circuit to communicatively couple with the physical GPU to create a plurality of emulated GPUs and a corresponding plurality of device nodes. Each device node can be associated with a single corresponding user-side container to enable communication between the user-side container and the corresponding emulated GPU. Other embodiments can be disclosed and / or claimed.

Description

[0001] This application is a divisional application of the same patent application, filed on May 29, 2015, with application number 201580079299.7. Technical Field

[0002] Embodiments of this disclosure generally relate to the field of computing systems, and more specifically to container access to graphics processing unit resources. Background Technology

[0003] Containers have been used to access non-graphics processing unit (GPU) computing resources, such as central processing unit (CPU) resources, memory and storage devices, and network functions. However, the unique challenges involved in using containers in GPU-intensive applications make GPU containerization an open challenge. Attached Figure Description

[0004] The embodiments will be readily understood from the following detailed description taken in conjunction with the accompanying drawings. For ease of description, similar reference numerals denote similar structural elements. The embodiments are shown in the figures by way of example rather than limitation.

[0005] Figure 1 This is a block diagram of a computing system including a container that is communicatively coupled to a simulated GPU, according to various embodiments.

[0006] Figure 2 It is according to various embodiments having a display manager and a scheduler Figure 1 A block diagram of an embodiment of the computing system.

[0007] Figure 3 It is a virtual machine having communicative coupling with a simulated GPU, according to various embodiments. Figure 1 A block diagram of an embodiment of the computing system.

[0008] Figure 4 It is based on various embodiments and has multiple kernel-mode drivers. Figure 1 A block diagram of an embodiment of the computing system.

[0009] Figure 5 This is a flowchart of a kernel-side method, according to various embodiments, for enabling user-side containers to utilize the resources of a physical GPU.

[0010] Figure 6 This is a flowchart of a user-side method, according to various embodiments, for enabling a user-side container to utilize the resources of a physical GPU.

[0011] Figure 7 This is a block diagram of an exemplary computing device that can be used to practice the various embodiments described herein. Detailed Implementation

[0012] This document discloses systems and methods for container access to graphics processing unit (GPU) resources. For example, in some embodiments, a method for enabling multiple user-side containers to utilize the resources of a physical GPU may include providing a kernel-mode driver to create multiple emulated GPUs and corresponding device nodes, wherein the multiple emulated GPUs are communicatively coupled to a physical GPU; and associating each device node with a single corresponding user-side container such that communication between the user-side container and the corresponding emulated GPU can utilize the resources of the physical GPU.

[0013] The various embodiments disclosed herein can provide GPU acceleration in containers through driver self-emulation. Containers (also known as "software containers") provide operating system-level virtualization in computing systems. Systems that use containers instead of traditional virtual machines (VMs) may exhibit higher density, faster provisioning, and better performance, making containers a powerful, lightweight alternative to virtualization technologies in certain applications.

[0014] As mentioned above, containers have been used to access non-GPU computing resources, such as central processing unit (CPU) resources, memory and storage devices, and network functions. These subsystems are managed by the kernel and typically have well-abstracted resources and simple interfaces exposed to the user side of the computing system. In particular, different namespaces can give each user-side process a separate system view, isolated from other processes, and include separate mount points, process identifiers (PIDs), inter-process communication (IPC), network resources, and time resources, etc. As a result, namespaces enable the containerization of these non-GPU computing resources for individual users. The "cgroup" feature in the Linux kernel restricts, interprets, and isolates resource usage by multiple processes, and can further enforce resource restrictions, priority ordering, interpretation, and control in different namespaces. Therefore, multiple containers can be well isolated.

[0015] However, the unique challenges involved in using containers in GPU-intensive applications have remained an open challenge. In particular, the complex interface between the GPU's kernel-mode driver (KMD) and user-mode driver (UMD) means the graphics subsystem is far more complex than those discussed above. Interfaces and graphics subsystems are often vendor-specific, resulting in poorly abstracted resources exposed to the UMD, requiring an order of magnitude more options to be specified than those for the subsystems discussed above. For example, a typical graphics driver in Linux might include approximately 70 commonly used Direct Render Manager (DRM) Input / Output Control (IOCTL) options and approximately 40 vendor-specific IOCTL options. Each IOCTL results in a complex code path within the graphics driver, which ultimately translates into thousands of registers in the GPU. Creating namespaces or using cgroups for such a large set of interface and device attributes requires a very detailed, intrusive, and device-specific set of modifications, touching almost every code path / data structure within the KMD. This is a massive undertaking that can lead to an almost unmanageable maintenance burden. Furthermore, the ability to port a solution from one GPU to another is limited or nonexistent.

[0016] These challenges have limited or excluded the use of containers in graphics-intensive scenarios. These scenarios might include using multiple people and client devices (e.g., personal computers, phones, tablets); remote desktops or workstations running GPU-intensive computer-aided drafting (CAD) software; cloud applications providing media transcoding, video conferencing, set-top boxes, or other software-as-a-service; cloud gaming; and visual understanding (e.g., facial recognition, deep learning). Some of these scenarios may require full GPU capabilities (e.g., 3D graphics, video, and GPU computing), while others may only require a subset of GPU capabilities. Typically, hypervisor-based virtualization (e.g., running an entire operating system within a virtual machine) is used in these scenarios.

[0017] At most, "containerization" is attempted by dedicating a physical GPU to a single container, without requiring multiple containers to share the GPU's resources. Some previous methods have attempted to run applications in multiple containers and allow these applications to access GPU resources, but the lack of isolation between applications in different containers introduces significant security risks.

[0018] Some embodiments disclosed herein provide containerized graphics in a secure and isolated manner, thereby achieving good Quality of Service (QoS) control. Specifically, this paper discloses a driver self-emulation method in which multiple emulated GPU instances can be generated. Each GPU instance can be securely isolated and dedicated when used by the user-side container. This can enable GPU acceleration within the container while maintaining robust isolation in terms of both security and performance. Using the method disclosed herein, the difficulty of containerizing UMDs with complex interfaces to KMDs is eliminated; instead, emulated GPUs can be containerized and communicate with physical GPUs using known techniques.

[0019] In some embodiments, the emulated GPU in the computing system can be generated by a KMD. The emulated GPU can have the same characteristics as the physical GPU in the computing system. Each emulated GPU can be associated with a unique device node, which is exclusively owned by a single container on the user side. The same driver code can run on top of both the emulated GPU and the physical GPU (e.g., having substantially the same low-level I / O hooks). Security isolation can be centrally enforced at the emulated GPU level (e.g., in a self-emulator). Each container can only access its own emulated GPU, thus enabling strict isolation. Performance isolation can be enforced when the emulated GPU issues GPU commands to a scheduler, which can then extend existing QoS policy enforcement techniques to applications within the container. Various embodiments in these and others are discussed in detail here.

[0020] In the following detailed description, reference is made to the accompanying drawings, which form a part thereof, wherein similar reference numerals always denote similar parts, and wherein illustrative embodiments that can be practiced are shown. It should be understood that other embodiments may be used and structural or logical changes may be made without departing from the scope of this disclosure.

[0021] Various operations can be described sequentially as a plurality of discrete actions or operations in a manner most helpful for understanding the claimed subject matter. However, the order of description should not be construed as implying that these operations are necessarily order-dependent. In particular, these operations may not be performed in the order presented. The described operations may be performed in a different order than the described embodiments. Various additional operations may be performed in additional embodiments or the described operations may be omitted.

[0022] For the purposes of this disclosure, the term "or" is used as an inclusive term to indicate at least one of the components coupled with the term. For example, the phrase "A or B" means (A), (B), or (A and B); the phrase "A, B or C" means (A), (B), (C), (A and B), (A and C), (B and C), or (A, B and C).

[0023] The description may use the phrases "in one embodiment" or "in an embodiment," which may each refer to one or more of the same or different embodiments. Furthermore, the terms "comprising," "including," "having," etc., used with respect to embodiments of this disclosure are synonyms.

[0024] As used herein, the term "circuit" can refer to, is a part of, or includes, an application-specific integrated circuit (ASIC), electronic circuit, processor (shared, dedicated, or grouped), or memory (shared, dedicated, or grouped) that executes one or more software or firmware programs, combinational logic circuits, or other suitable hardware components that provide the said functionality. As used herein, the terms "driver" and "driver circuit" can include circuits that are programmed or otherwise configured to operate and / or control a particular hardware device (e.g., a graphics processing unit).

[0025] Figure 1 This is a block diagram of a computing system 100 including multiple containers 106 on the user side 102. Each container 106 is communicatively coupled to an emulated GPU 122 on the kernel side 104 of the computing system 100. Each container 106 may include a user-mode GPU driver (UMD) 110 and one or more software applications 108 communicating with the UMD 110. The UMD 110 may communicate with the emulated GPU 122 on a kernel-mode GPU driver (KMD) 114 via a UMD-KMD interface 112 and a device node 116 (e.g., / dev / dri / card0 or another card number in a Linux system). The KMD 114 may be communicatively coupled to a physical GPU 128. The device node 116 may exchange control data (e.g., mode settings, resolution, cache mode, etc.) with the emulated GPU 122 on a control path 118 and render data on a rendering path 120 (e.g., via a command buffer containing GPU commands to be parsed by the GPU). Conversely, KMD 114 can exchange control data on control path 124 and render data on rendering path 126 with the help of physical GPU 128. In some embodiments, control path 124 and rendering path 126 can be duplexed and share a common path.

[0026] A simulated GPU 122 can be generated using any of many known techniques. For example, methods such as XenGT have been used to achieve GPU acceleration in a VM by generating a fully simulated GPU device model within a Linux graphics driver. This GPU device model can be used to provide a simulated GPU 122 and can be easily ported to any operating system. Using the XenGT method, the operation of the simulated GPU 122 can be expected to approach native performance for typical graphics workloads, and is almost identical to native performance for typical media workloads. Additionally, the use of containers instead of VMs avoids the pitfalls of hypervisor usage (because containers can directly call the simulated GPU device model from the driver code). Although XenGT has been discussed above, any suitable existing GPU device model can be used to generate a simulated GPU, therefore, this article will not discuss the techniques used to generate simulated GPUs further.

[0027] KMD 114 can be configured to create one or more emulated GPUs 122 and corresponding one or more device nodes 116. In use, each device node 116 can be associated with a single corresponding user-side container 106, and communication between the user-side container 106 and the corresponding emulated GPU 122 can be implemented to allow one or more applications 108 of the user-side container 106 to utilize the graphics processing resources of the physical GPU 128.

[0028] In some embodiments, the computing system 100 may include a graphics memory (not shown) partitioned among a plurality of emulated GPUs 122. The graphics memory may be used for pixel loading or, for example, as a write command buffer. In other embodiments, the graphics memory for the emulated GPUs 122 may be dynamically and centrally allocated in the KMD 114 (e.g., as is typically done for host applications).

[0029] In some embodiments, the emulated GPU 122 may emulate the physical GPU 128. In some embodiments, the emulated GPU 122 may support a set of features that are a correct subset of the features supported by the physical GPU 128. For example, the emulated GPU 122 may represent a “simplified” GPU relative to the physical GPU 128 (e.g., exposing fewer features to user space than the physical GPU 128). In some embodiments, the emulated GPU 122 may not emulate the physical GPU 128; see below. Figure 4 Examples of these embodiments are discussed.

[0030] Figure 2 According to various embodiments Figure 1 A block diagram of an embodiment of the computing system 100, including a display manager 134 and a scheduler 130. (Refer to the above...) Figure 1 The subject of discussion Figure 2 The computing system 100 includes multiple containers 106 on the user side 102, each container 106 being communicatively coupled to an emulated GPU 122 on the kernel side 104. Each container 106 may include a user-mode GPU driver (UMD) 110 and one or more software applications 108 communicating with the UMD 110. The UMD 110 may also communicate with the emulated GPU 122 of the KMD 114 via a UMD-KMD interface 112 and a device node 116. (See above reference...) Figure 1 The KMD 114 can be communicatively coupled to the physical GPU 128. Device node 116 can exchange control data with the emulated GPU 122 on control path 118 and render data on rendering path 120. Conversely, KMD 114 can exchange control data with the physical GPU 128 on control path 124 and render data on rendering path 126. KMD 114 can be configured to create one or more emulated GPUs 122 and corresponding one or more device nodes 116. In use, each device node 116 can be associated with a single corresponding user-side container 106, and communication between the user-side container 106 and the corresponding emulated GPU 122 can be implemented to allow one or more applications 108 of the user-side container 106 to utilize the graphics processing resources of the physical GPU 128.

[0031] like Figure 2 As shown, one or more emulated GPUs 122 may be included in the self-emulator 132 of KMD 114 along with the display manager 134. The self-emulator 132 may be configured to generate GPU device models for use as emulated GPUs 122. In embodiments where the emulated GPU 122 can be generated with the same or equivalent characteristics as the physical GPU 128, the KMD (i.e., KMD 114) for the physical GPU 128 is capable of generating multiple driver instances to manage both the emulated GPU 122 and the physical GPU 128. In some embodiments, the emulated GPU 122 may include the exact same features as the physical GPU 128, so the same graphics driver can run seamlessly on both. Each driver instance may include its own device node 116, which may be specifically assigned to a particular container 106, as described above. Minimal changes can be made to translate low-level driver input / output interfaces (e.g., i915_read / write IOCTL) into callbacks directly within the emulated GPU 122. Each container 106 can be constrained to access only its own emulated GPU 122, and the self-emulator 132 can ensure that the emulated GPU 122 does not interfere with other emulated GPUs 122 (e.g., by controlling CPU page table mapping and GPU scan commands).

[0032] The computing system 100 may also include one or more applications 136 and UMD 138 that are not included in a software container. Application 136 may communicate with UMD 138, which in turn may communicate with device node 116 of KMD 114 via UMD-KMD interface 140. Device node 116 may then exchange control data with physical GPU 128 using conventional techniques (e.g., unemulated GPUs) and render data using scheduler 130. Therefore, the computing system 100 can accommodate both containerized and non-containerized applications (simultaneously or at different times) utilizing the resources of physical GPU 128.

[0033] KMD 114 may include a scheduler 130. Scheduler 130 may be communicatively coupled to the emulated GPU 122 and the physical GPU 128. Scheduler 130 may provide rendering data on rendering path 142. Scheduler 130 may provide a command submission interface for the emulated GPU 122 and may implement cgroup or similar functionality. In some embodiments, scheduler 130 may be configured to enforce a quality of service (QoS) policy when the emulated GPU 122 uses the physical GPU 128 (e.g., by applying a cgroup policy in a manner similar to that typically applied to host applications). For example, based on a service level agreement between the end user and the cloud service provider regarding container capabilities, the QoS policy may include different weights assigned to different emulated GPUs 122. Scheduler 130 may then schedule commands from each emulated GPU 122 based on the assigned weights or using any suitable conventional techniques for QoS scheduling (e.g., a particular emulated GPU 122 is allocated a certain percentage of resources based on its total weight). In some embodiments, scheduler 130 may be configured to enforce a security isolation policy on the emulated GPU 122. As used herein, "isolation policy" may refer to a stored set of requirements regarding permissible interactions and / or exposures between one emulated GPU 122 and another.

[0034] The self-emulator 132 of the KMD 114 may include a display manager 134. The display manager 134 may be coupled to the frame buffers (not shown) of each of a plurality of user-side containers 106 to selectively bring different frame buffers to the control path 124 for the physical GPU 128. This feature may be particularly advantageous in a setup where each of the plurality of containers 106 runs a full graphics stack (e.g., including an x ​​server and window manager). Such a setup may occur in tablet and telephone virtualization, or in-vehicle infotainment (IVI) virtualization. When a user wishes to switch from viewing the contents of a first container to viewing the contents of a second container, the second container can be brought to the "foreground" by bringing its frame buffer to the control path 124 of the physical GPU 128 (and the first container can be sent to the "background" by decoupling its frame buffer from the control path 124). Frame buffers may be brought to the control path 124, for example, via a full-mode setting or via a frame buffer switch and panel accessory (the latter typically faster than the former).

[0035] As per the above reference Figure 1 In some embodiments, as described above. Figure 2 The computing system 100 may include a graphics memory (not shown) partitioned among multiple emulated GPUs 122. The graphics memory may be used for pixel loading or, for example, as a write command buffer. In some embodiments, Figure 2 The simulated GPU 122 can emulate the physical GPU 128. In some embodiments, the simulated GPU 122 can support a set of features that are a proper subset of the features supported by the physical GPU 128. In some embodiments, the simulated GPU 122 does not emulate the physical GPU 128; see below for reference. Figure 4 Examples of such embodiments are discussed.

[0036] Figure 3 According to various embodiments Figure 1 A block diagram of an embodiment of the computing system 100, having a virtual machine (VM) 150 communicatively coupled to a simulated GPU 122. Figure 1 The computing system 100 can be based on a Type 2 management program model. (See above reference.) Figure 1 The subject of discussion Figure 3The computing system 100 includes multiple containers 106 on the user side 102 of a main computing device 144, each container 106 being communicatively coupled to an emulated GPU 122 on the kernel side 104. Each container 106 may include a user-mode GPU driver (UMD) 110 and one or more software applications 108 communicating with the UMD 110. The UMD 110 may in turn communicate with the emulated GPU 122 of the KMD 114 of the main computing device 144 via a UMD-KMD interface 112 and a device node 116. (Refer to the above) Figure 1 The KMD 114 can be communicatively coupled to the physical GPU 128. Device node 116 can exchange control data with the emulated GPU 122 on control path 118 and render data on rendering path 120. Conversely, the KMD 114 can exchange control data with the physical GPU 128 on control path 124 and render data on rendering path 126. The KMD 114 can be configured to create one or more emulated GPUs 122 and corresponding one or more device nodes 116. In use, each device node 116 can be associated with a single corresponding user-side container 106, and communication between the user-side container 106 and the corresponding emulated GPU 122 can be implemented to allow one or more applications 108 of the user-side container 106 to utilize the graphics processing resources of the physical GPU 128. One or more emulated GPUs 122 can be included, along with a display manager 134, in a self-emulator 132 of the KMD 114 on the host computing device 144. The computing system 100 may also include one or more applications 136 and UMD 138 not included in the software container of the host computing device 144, as referenced above. Figure 2 The KMD 114 may include a scheduler 130 and / or a display manager 134, which may employ the methods described above. Figure 2 The form of any embodiment discussed. See above references. Figure 1 In some embodiments, as described above. Figure 2 The computing system 100 may include a graphics memory (not shown) partitioned among multiple emulated GPUs 122. The graphics memory may be used for pixel loading or, for example, as a write command buffer. In some embodiments, Figure 2 The simulated GPU 122 can emulate the physical GPU 128. In some embodiments, the simulated GPU 122 can support a set of features that are a proper subset of the features supported by the physical GPU 128. In some embodiments, the simulated GPU 122 does not emulate the physical GPU; see below for reference. Figure 4 Examples of such embodiments are discussed.

[0037] As mentioned above, Figure 3The computing system 100 may include a VM 150. The VM 150 may include one or more software applications 158 communicating with a UMD 160. The VM 150 may also include a KMD 164 having a device node 166. The UMD 160 may communicate with the device node 166 in a similar manner to that discussed above with reference to the UMD 110 and device node 116. The VM 150 may run on a hypervisor 170, which may be communicatively positioned between the VM 150 and the host computing device 144. Specifically, the hypervisor 170 may be communicatively coupled to one of the emulated GPUs 122 and may facilitate the transfer of control data on control path 178 and the rendering of data on rendering path 180 from the KMD 164 to the emulated GPU 122. Therefore, Figure 3 The computing system 100 can accommodate containerized and VM-based applications (simultaneously or at different times) utilizing the resources of physical GPUs 128. This hybrid or “hybrid” scenario provides new flexibility when configuring the computing system 100.

[0038] Figure 4 According to various embodiments Figure 1 A block diagram of an embodiment of a computing system 100 having multiple kernel-mode drivers arranged in a "nested" configuration. Figure 4 The computing system 100 includes a physical GPU designated as a physical GPU-A 128. Figure 4 The computing system 100 also includes a container 406 on the user side 102, which is communicatively coupled to an emulated GPU 422 designated as the emulated GPU-B 422 on the kernel side 104. Figure 4 The computing system 100 also includes a container 446 on the user side 102, which is communicatively coupled to an emulated GPU designated as an emulated GPU-C 472 on the kernel side 104. Figure 4 In the computing system 100, GPU-A, GPU-B, and GPU-C can represent different GPUs (e.g., GPUs with different capabilities and associated different drivers). Figure 4 The use of three different GPUs in the computing system 100 is merely illustrative, and any suitable number of GPUs can be used according to the techniques discussed herein.

[0039] Container 406 may include a UMD 410 and one or more software applications 408 communicating with the UMD 410. The UMD 410 may communicate via a UMD-KMD interface 412 with a device node 416 of a KMD (designated KMD-B 414) for an emulated GPU-B 422 on the kernel side 104. As shown, device node 416 may be positioned between the UMD 410 and the emulated GPU-B 422 along a communication path between the application 408 and the physical GPU-A 128. KMD-B 414 communicates with the emulated GPU-B 422 to exchange control data on control path 418 and render data on rendering path 420. The emulated GPU-B 422 may be included in a self-emulator 432 of the KMD (designated KMD-A 114) for the physical GPU-A 128.

[0040] Container 446 may include UMD 460 and one or more software applications 448 communicating with UMD 460. UMD 460 may communicate with device node 466 of KMD (designated KMD-C464) for an emulated GPU-C 472 on kernel side 104 via UMD-KMD interface 462. As shown, device node 466 may be set up between UMD 460 and emulated GPU-C 472 along a communication path between application 448 and physical GPU-A128. KMD-C 464 communicates with emulated GPU-C472 to exchange control data on control path 468 and render data on rendering path 470. Emulated GPU-C472 may be included in self-emulator 432 of KMD-A 114.

[0041] As referenced above Figure 1As discussed, the KMD-A 114 can be communicatively coupled to the physical GPU-A 128. The KMD-A 114 can exchange control data with the physical GPU-A 128 on control path 124 and render data on rendering path 126. The KMD-A 114 can be configured to create one or more emulated GPUs (422 and 472) and corresponding one or more device nodes (416 and 466). In use, each device node (416 and 466) can be associated with a single corresponding user-side container (406 and 446, respectively), and communication between the user-side container (406 and 446, respectively) and the corresponding emulated GPU (422 and 472, respectively) can be implemented to allow one or more applications (408 and 448, respectively) of the user-side container (406 and 446, respectively) to utilize the graphics processing resources of the physical GPU-A 128. As described above, the self-emulator 432 may include a display manager 134. The computing system 100 may also include one or more applications 136 and UMD 138 not included in a software container of the host device 144, as referenced above. Figure 2 The KMD-A 114 may include a scheduler 130 and / or a display manager 134, which may employ the methods described above. Figure 2 The form of any embodiment discussed. See above references. Figure 1 In some embodiments, as described above. Figure 2 The computing system 100 may include graphics memory (not shown) partitioned among multiple emulated GPUs (e.g., emulated GPUs 422 and 472). The graphics memory may be used for pixel loading or as, for example, a write command buffer. In some embodiments, Figure 2 The simulated GPU 122 can simulate the physical GPU 128.

[0042] exist Figure 4 In the computing system 100, the emulated GPU-B 422 may not emulate the physical GPU-A 128. Similarly, the emulated GPU-C 472 may not emulate the physical GPU-A 128, and the GPUs emulated by the emulated GPU-B 422 and the emulated GPU-C 472 may not be the same GPU. However, by using the driver nesting method shown, different graphics drivers can run on the emulated GPU 122. Additional transformations can be applied, for example, to command formats and display attributes.

[0043] In some embodiments, the above reference Figure 3 The hybrid VM container approach discussed and the above references Figure 4The nested driver methods discussed can be combined in any desired arrangement within a single computing system. More generally, any suitable embodiments of the examples disclosed herein can be combined with other embodiments disclosed herein to generate computing systems within the scope of this disclosure.

[0044] Figure 5 This is a flowchart of a kernel-side method 500 for enabling user-side containers to utilize the resources of a physical GPU, according to various embodiments. For ease of illustration, method 500 is discussed below with reference to computing system 100. It will be appreciated that although the operations of method 500 (and other methods described herein) are arranged in a specific order and each is shown once, in various embodiments, one or more of the operations may be repeated, omitted, or performed out of order. For illustrative purposes, the operations of method 500 may be described as being performed by circuitry on the kernel side 104 of computing system 100, but method 500 can be performed by any suitably configured device.

[0045] At 502, circuitry on the kernel side 104 of computing system 100 can provide a KMD (e.g., KMD 114) to create multiple emulated GPUs (emulated GPU 122) and corresponding multiple device nodes (e.g., device node 116). The multiple emulated GPUs can be communicatively coupled to a physical GPU (e.g., physical GPU 128).

[0046] At 504, the circuitry on the kernel side 104 of the computing system 100 can associate each device node with a single corresponding user-side container (e.g., container 106) so that communication between the user-side container and the corresponding emulated GPU can utilize the resources of the physical GPU.

[0047] Figure 6 This is a flowchart of a user-side method 600 for enabling a user-side container to utilize the resources of a physical GPU, according to various embodiments. For ease of explanation, method 600 can be discussed below with reference to computing system 100. In particular, for illustrative purposes, the operation of method 600 can be described as being performed by circuitry on the user side 102 of computing system 100, but method 600 can be performed by any appropriately configured device.

[0048] At 602, circuitry on the user side 102 of the computing system 100 can associate a user-side container (e.g., container 106) with a kernel-side device node (e.g., device node 116). The kernel-side device node may correspond to an emulated GPU (e.g., emulated GPU 122) of a KMD (e.g., KMD 114), and the emulated GPU may be communicatively coupled to a physical GPU (e.g., physical GPU 128).

[0049] At 604, the circuitry on the user side 102 of the computing system 100 allows one or more software applications (e.g., software application 108) in the user-side container to utilize the resources of the physical GPU via the kernel-side device node and the emulated GPU.

[0050] Suitable embodiments disclosed herein can be readily applied to computing systems in which the physical GPU 128 is a GPU with single root input / output virtualization (SR-IOV) capability. Multiple emulated GPUs (e.g., emulated GPU 122) can be managed in the same manner as virtualization in an SR-IOV GPU system. Furthermore, the emulation device method disclosed herein can be extended beyond emulated GPUs and can be used for containerizing other subsystems, such as storage devices. This can overcome some shortcomings of existing methods for managing these subsystems. For example, existing mounting namespace techniques cannot provide quantum control across containers, and extending file systems is a complex task. However, generating emulated storage devices may address these shortcomings and provide a simple solution.

[0051] Figure 7 This is a block diagram of an exemplary computing device 700, which is applicable to practicing various disclosed embodiments. For example, computing device 700 may be used as computing system 100 or as host computing device 144. In some embodiments, components of computing device 700 may be distributed across multiple physical device housings or locations, while in other embodiments, components of computing device 700 may be included in a single housing or location.

[0052] Computing device 700 may include multiple components, including one or more processors 704 and at least one communication chip 706. In various embodiments, processor 704 may include a processor core. In various embodiments, at least one communication chip 706 may also be physically and electrically coupled to processor 704. In another implementation, communication chip 706 may be part of processor 704. In various embodiments, computing device 700 may include a printed circuit board (PCB) 702. For these embodiments, processor 704 and communication chip 706 may be disposed thereon. In alternative embodiments, various components may be coupled without using PCB 702.

[0053] Depending on its application (e.g., container and GPU applications), computing device 700 may include other components that may or may not be physically and electrically coupled to PCB 702. These other components include, but are not limited to, random access memory (RAM) 708, volatile memory (e.g., dynamic RAM (DRAM)), non-volatile memory (e.g., read-only memory 710, also known as "ROM", one or more hard disk drives, one or more solid-state drives, one or more compact disk drives, and / or one or more digital universal disk drives), flash memory 712, input / output (I / O) controller 714, digital signal processor (not shown), cryptographic processor (not shown), and graphics processor 716 (e.g., physical GPU). 728), one or more antennas 718, touchscreen display 720, touchscreen controller 722, other displays (such as liquid crystal displays, cathode ray tube displays, and e-ink displays, not shown), battery 724, audio codec (not shown), video codec (not shown), global positioning system (GPS) device 728, compass 730, accelerometer (not shown), gyroscope (not shown), speaker 732, camera 734, and mass storage devices (such as hard disk drives, solid-state drives, compact discs (CDs), digital versatile discs (DVDs)) (not shown), any other required sensors (not shown), etc. In various embodiments, processor 704 may be integrated with other components on the same die to form a system-on-a-chip (SoC). Any memory devices discussed herein may include Figure 7 As shown or referenced Figure 7 Any one or more of the memory devices discussed in this article.

[0054] In various embodiments, volatile memory (e.g., RAM 708), non-volatile memory (e.g., ROM 710), flash memory 712, and mass storage devices may include instructions that, in response to execution by one or more processors 704, cause computing device 700 to perform as referenced herein. Figure 1-6All or selected aspects of the described process. For example, one or more memory components such as volatile memory (e.g., RAM 708), non-volatile memory (e.g., ROM 710), flash memory 712, and mass storage devices may be computer-readable media comprising temporary and / or persistent (e.g., non-temporary) copies of instructions that, in response to execution by one or more processors 704, cause computing device 700 to implement all or selected aspects of the process described herein. Memory accessible to computing device 700 may include one or more storage devices that are physically part of a device on which computing device 700 is mounted and / or one or more storage devices that can be accessed by computing device 700 but are not necessarily part of computing device 700. For example, storage devices may be accessible by computing device 700 over a network via communication chip 706. In some embodiments, instructions may be embodied in computer-readable, temporary, non-tangible media, such as signals.

[0055] The communication chip 706 can enable wired and / or wireless communication for transmitting data to and from the computing device 700. The term "wireless" and its derivatives can be used to describe circuits, devices, systems, methods, technologies, communication channels, etc., that can transmit data over a non-solid medium using modulated electromagnetic radiation. This term does not imply that the associated devices do not contain any wires, although in some embodiments they may not contain any wires. The communication chip 706 can implement any of a variety of wireless standards or protocols, including but not limited to IEEE 02.20, General Packet Radio Service (GPRS), Evolved Data Optimized (Ev-DO), Evolved High-Speed ​​Packet Access (HSPA+), Evolved High-Speed ​​Downlink Packet Access (HSDPA+), Evolved High-Speed ​​Uplink Packet Access (HSUPA+), Global System for Mobile Communications (GSM), Enhanced Data Rate for GSM Evolution (EDGE), Code Division Multiple Access (CDMA), Time Division Multiple Access (TDMA), Digital Enhanced Cordless Telecommunications (DECT), Bluetooth, Wi-Fi, Long Term Evolution (LTE), its derivatives, and any other wireless protocols designated as 2G, 3G, 4G, and others. The computing device 700 may include multiple communication chips 706. For example, the first communication chip 706 can be dedicated to shorter-range wireless communications such as Wi-Fi and Bluetooth, while the second communication chip 706 can be dedicated to longer-range wireless communications such as GPS, EDGE, GPRS, CDMA, WiMAX, LTE, Ev-DO, and others.

[0056] In various implementations, computing device 700 may be a laptop computer, netbook, notebook computer, ultrabook, wearable device, smartphone, tablet computer, personal digital assistant, ultra-mobile PC, mobile phone, desktop computer, server, printer, scanner, monitor, set-top box, entertainment control unit (e.g., game console), digital camera, portable music player, or digital video recorder. In other implementations, computing device 700 may be any other electronic device that processes data.

[0057] The following paragraphs describe examples of various embodiments.

[0058] Example 1 is a computing system comprising: a physical graphics processing unit (GPU); and kernel-mode driver circuitry for communicatively coupling with the physical GPU to create multiple emulated GPUs and corresponding multiple device nodes, wherein each device node is associated with a single corresponding user-side container to enable communication between the user-side container and the corresponding emulated GPU.

[0059] Example 2 can include the topics of Example 1, and can also specify that each emulated GPU simulates a physical GPU.

[0060] Example 3 may include the subject of any of Examples 1-2, and may also specify that each user-side container includes a user-mode driver for communicating with the corresponding emulated GPU via the corresponding device node.

[0061] Example 4 may include the subject of Example 3, and may also specify that each user-side container includes one or more software applications that communicate with a user-mode driver, and each of the one or more software applications utilizes the resources of a physical GPU.

[0062] Example 5 may include the subject of any of Examples 1-4, and may also specify kernel-mode driver circuitry including a display manager to couple with the frame buffer of each of the multiple user-side containers to selectively bring different frame buffers to the control path of the physical GPU.

[0063] Example 6 may include the subject of any of Examples 1-5, and may also specify that the kernel-mode driver circuitry includes a scheduler that communicates with multiple emulated GPUs and physical GPUs.

[0064] Example 7 can include the topics of Example 6, and can also specify that the scheduler enforces the quality of service policy on the emulated GPU using the physical GPU.

[0065] Example 8 can include themes from any of Examples 6-7, and can also specify that the scheduler enforces a security isolation policy for the emulated GPU.

[0066] Example 9 may include the subject of any of Examples 1-8, and may also include graphics memory partitioned among multiple emulated GPUs.

[0067] Example 10 may include the subject of Example 9, and may also specify the graphics memory for pixel loading or as a write command buffer.

[0068] Example 11 may include the subject of any of Examples 1-10, and may also specify that the simulated GPU supports a first set of GPU features, the physical GPU supports a second set of GPU features, and the first set is a proper subset of the second set.

[0069] Example 12 may include the subject of any of Examples 1-10, and may also include: a hypervisor coupled to one of the multiple emulated GPUs; and a virtual machine that runs on the hypervisor to communicate with one of the multiple emulated GPUs.

[0070] Example 13 can include the subject of Example 12, and can also specify that the virtual machine includes a kernel-mode GPU driver and a user-mode GPU driver.

[0071] Example 14 may include the subject of any of Examples 1-13, and may also specify that the first emulated GPU does not emulate a physical GPU, the first device node is associated with the first emulated GPU, the kernel-mode driver circuit is a first kernel-mode driver circuit, and the computing system further includes a second kernel-mode driver circuit arranged such that the second kernel-mode driver circuit is positioned in a communication path between the user-mode driver circuit and the first kernel-mode driver circuit.

[0072] Example 15 may include the subject of Example 14, and may also include a first user-side container that includes a user-mode driver that communicates with a second kernel-mode driver circuit.

[0073] Example 16 is one or more computer-readable media containing instructions that, in response to execution by one or more processing devices of a computing system, cause the computing system to: provide a kernel-mode driver to create a plurality of emulated graphics processing units (GPUs) and corresponding plurality of device nodes, wherein the plurality of emulated GPUs are communicatively coupled to a physical GPU; and associate each device node with a single corresponding user-side container such that communication between the user-side container and the corresponding emulated GPU can utilize the resources of the physical GPU.

[0074] Example 17 can include the topics of Example 16, and can also specify that each emulated GPU simulates a physical GPU.

[0075] Example 18 may include the subject of any of Examples 16-17, and may also specify that each user-side container includes a user-mode driver for communicating with the corresponding emulated GPU via the corresponding device node.

[0076] Example 19 may include the subject of Example 18, and may also specify that each user-side container includes one or more software applications that communicate with the user-mode driver, and each of the one or more software applications utilizes the resources of the physical GPU.

[0077] Example 20 may include the subject of any of Examples 16-19, and may also specify that, when executed by one or more processing devices of the computing system, the instructions further cause the computing system to: couple the frame buffer of each of the plurality of user-side containers to selectively bring different frame buffers to the control path of the physical GPU.

[0078] Example 21 may include the subject of any of Examples 16-20, and may also specify instructions that, when executed by one or more processing devices of the computing system, further cause the computing system to: provide a scheduler to communicate with multiple emulated GPUs and physical GPUs.

[0079] Example 22 can include the topics of Example 21, and can also specify that the scheduler enforces the quality of service policy on the emulated GPU using the physical GPU.

[0080] Example 23 may include the subject of any of Examples 21-22, and may also specify that the scheduler enforces a security isolation policy for the emulated GPU.

[0081] Example 24 may include the subject of any of Examples 16-23, and may also specify that, when executed by one or more processing devices of a computing system, the instructions further cause the computing system to partition graphics memory among multiple emulated GPUs.

[0082] Example 25 may include the subject of Example 24, where the graphics memory will be used for pixel loading or as a write command buffer.

[0083] Example 26 may include the subject of any of Examples 16-25, and may also specify that the simulated GPU supports a first set of GPU features, the physical GPU supports a second set of GPU features, and the first set is a proper subset of the second set.

[0084] Example 27 may include the subject of any of Examples 16-26, and may also specify that, when executed by one or more processing devices of the computing system, the instructions further cause the computing system to: create a second emulated GPU communicatively coupled to the physical GPU; and associate the second emulated GPU with a virtual machine to enable communication between the virtual machine and the corresponding emulated GPU.

[0085] Example 28 may include the topics of Example 27, and may also specify that the virtual machine includes a kernel-mode GPU driver and a user-mode GPU driver.

[0086] Example 29 may include the subject of any of Examples 16-28, and may also specify that the first emulated GPU does not emulate a physical GPU, the first emulated GPU is associated with a first device node, the kernel-mode driver is a first kernel-mode driver, and the instructions further cause the computing system, when executed by the one or more processing devices of the computing system, to: provide a second kernel-mode driver, the second kernel-mode driver being arranged such that the second kernel-mode driver is positioned in a communication path between a user-mode driver and a first kernel-mode driver in a user-side container.

[0087] Example 30 may include the subject of Example 29, and may also specify that the first user-side container includes a user-mode driver for communicating with the second kernel-mode driver.

[0088] Example 31 is one or more computer-readable media containing instructions that, in response to execution by one or more processing devices of a computing system, cause the computing system to: associate a user-side container with a kernel-side device node, wherein the kernel-side device node corresponds to an emulated graphics processing unit (GPU) of a kernel-mode driver and the emulated GPU is communicatively coupled to a physical GPU; and allow one or more software applications in the user-side container to utilize the resources of the physical GPU via the kernel-side device node and the emulated GPU.

[0089] Example 32 can include the subject of Example 31, and can also specify that each emulated GPU simulates a physical GPU.

[0090] Example 33 may include the subject of any of Examples 31-32, and may also specify that the kernel-mode driver includes a display manager to couple with the frame buffer of the user-side container to selectively bring the frame buffer to the control path of the physical GPU.

[0091] Example 34 may include the subject of any of Examples 31-33, and may also specify that the kernel-mode driver includes a scheduler that communicates with both the emulated GPU and the physical GPU.

[0092] Example 35 may include the topics of Example 34, and may also specify the scheduler to enforce the quality of service policy for the use of physical GPUs by the emulated GPUs.

[0093] Example 36 may include the subject of any of Examples 34-35, and may also specify that the scheduler enforces a security isolation policy for the emulated GPU.

[0094] Example 37 may include the subject of any of Examples 34-36, and may also specify that the simulated GPU supports a first set of GPU features, the physical GPU supports a second set of GPU features, and the first set is a proper subset of the second set.

[0095] Example 38 may include the subject of any of Examples 31-37, and may also specify that: the emulated GPU does not emulate the physical GPU; the kernel-mode driver is a first kernel-mode driver; as part of allowing one or more software applications in a user-side container to utilize the resources of the physical GPU via a kernel-side device node and the emulated GPU, one or more software applications in a user-side container are allowed to utilize the resources of the physical GPU via a kernel-side device node, the emulated GPU, and the second kernel-mode driver; and the device node is positioned between the second kernel-mode driver and the emulated GPU in the communication path.

[0096] Example 39 may include the topic of Example 38, and may also specify that the user-side container includes a user-mode driver for communicating with the second kernel-mode driver.

[0097] Example 40 is a method for enabling multiple user-side containers to utilize the resources of a physical graphics processing unit (GPU), comprising: providing a kernel-mode driver to create multiple emulated GPUs and corresponding multiple device nodes, wherein the multiple emulated GPUs are communicatively coupled to a physical GPU; and associating each device node with a single corresponding user-side container such that communication between the user-side container and the corresponding emulated GPU can utilize the resources of the physical GPU.

[0098] Example 41 can include the subject of Example 40, and can also specify that each emulated GPU simulates a physical GPU.

[0099] Example 42 may include the subject of any of Examples 40-41, and may also specify that each user-side container includes a user-mode driver for communicating with the corresponding emulated GPU via the corresponding device node.

[0100] Example 43 may include the subject of Example 42, and may also specify that each user-side container includes one or more software applications that communicate with a user-mode driver, and each of the one or more software applications utilizes the resources of the physical GPU.

[0101] Example 44 may include the subject of any of Examples 40-43, and may also include frame buffers coupled to each of the multiple user-side containers to selectively bring different frame buffers to the control path of the physical GPU.

[0102] Example 45 may include the subject of any of Examples 40-44, and may also include providing a scheduler to communicate with multiple emulated GPUs and physical GPUs.

[0103] Example 46 can include the topics of Example 45, and can also specify that the scheduler enforces the quality of service policy on the emulated GPU using the physical GPU.

[0104] Example 47 may include the subject of any of Examples 45-46, and may also specify that the scheduler enforces a security isolation policy for the emulated GPU.

[0105] Example 48 may include the subject of any of Examples 40-47, and may also include partitioning of graphics memory across multiple emulated GPUs.

[0106] Example 49 may include the subject of Example 48, and may also specify that the graphics memory is used for pixel loading or as a write command buffer.

[0107] Example 50 may include the subject of any of Examples 40-49, and may also specify that the emulated GPU supports a first set of GPU features, the physical GPU supports a second set of GPU features, and the first set is a proper subset of the second set.

[0108] Example 51 may include the subject of any of Examples 40-50, and may also include: creating a second emulated GPU communicatively coupled to a physical GPU; and associating the second emulated GPU with a virtual machine to enable communication between the virtual machine and the corresponding emulated GPU.

[0109] Example 52 can include the subject of Example 51, and can also specify that the virtual machine includes a kernel-mode GPU driver and a user-mode GPU driver.

[0110] Example 53 may include the subject of any of Examples 40-52, and may also specify that the first emulated GPU does not emulate a physical GPU, the first emulated GPU is associated with a first device node, the kernel-mode driver is a first kernel-mode driver, and the method further includes: providing a second kernel-mode driver arranged such that the second kernel-mode driver is positioned in a communication path between a user-mode driver and a first kernel-mode driver in a user-side container.

[0111] Example 54 may include the subject of Example 53, and may also specify that the first user-side container includes a user-mode driver for communicating with the second kernel-mode driver.

[0112] Example 55 is a method for enabling a user-side container to utilize the resources of a physical graphics processing unit (GPU), comprising: associating the user-side container with a kernel-side device node, wherein the kernel-side device node corresponds to an emulated GPU of a kernel-mode driver and the emulated GPU is communicatively coupled to the physical GPU; and allowing one or more software applications in the user-side container to utilize the resources of the physical GPU via the kernel-side device node and the emulated GPU.

[0113] Example 56 may include the subject of Example 55, where each simulated GPU emulates a physical GPU.

[0114] Example 57 may include the subject of any of Examples 55-56, and may also specify that the kernel-mode driver includes a display manager to couple with the frame buffer of the user-side container to selectively bring the frame buffer to the control path of the physical GPU.

[0115] Example 58 may include the subject of any of Examples 55-57, and may also specify that the kernel-mode driver includes a scheduler that will communicate with both the emulated GPU and the physical GPU.

[0116] Example 59 can include the topics of Example 58, and can also specify that the scheduler enforces the quality of service policy for emulated GPUs using physical GPUs.

[0117] Example 60 may include the subject of any of Examples 58-59, and may also specify that the scheduler enforces a security isolation policy for the emulated GPU.

[0118] Example 61 may include the subject of any of Examples 58-60, and may also specify that the emulated GPU supports a first set of GPU features, the physical GPU supports a second set of GPU features, and the first set is a proper subset of the second set.

[0119] Example 62 may include the subject of any of Examples 55-61, and may also specify that: the emulated GPU does not emulate the physical GPU; the kernel-mode driver is a first kernel-mode driver; as part of allowing one or more software applications in a user-side container to utilize the resources of the physical GPU via the kernel-side device node, the emulated GPU, and the second kernel-mode driver; and the second kernel-mode driver is positioned between the user-mode driver and the first kernel-mode driver in the communication path.

[0120] Example 63 may include the subject of Example 62, wherein the user-side container includes a user-mode driver for communicating with a second kernel-mode driver.

[0121] Example 64 is one or more computer-readable media having instructions thereon, which, in response to execution by one or more processing devices of a computing system, cause the computing system to perform a method of any one of Examples 40-63.

[0122] Example 65 is an apparatus that includes a unit for performing the method of any one of Examples 40-63.

Claims

1. A server, comprising: A physical graphics processing unit (GPU) is used to support a first set of features and to implement single root input / output virtualization (SR-IOV). A circuit module is configured to implement a first driver for engaging with the physical GPU. The first driver provides access to a plurality of virtualization functions simulating the physical GPU. A first virtualization function supports a second set of features, a second virtualization function supports a third set of features, the second and third sets of features being different subsets of the first set of features supported by the physical GPU, and the first virtualization function being associated with a virtual machine. A scheduler for enforcing a quality of service policy for executing one or more commands provided by the plurality of virtualization functions using the physical GPU; as well as A management program for engaging the first virtualization function in the virtualization functionality with a second driver implemented by the virtual machine, the second driver for providing access to a second set of features supported by the first virtualization function in the virtualization functionality.

2. The server according to claim 1, further comprising the virtual machine and the second driver.

3. The server of claim 2, wherein the virtual machine is used to execute one or more applications, the one or more applications being used to communicate with the second driver.

4. The server according to claim 1 further includes a printed circuit board.

5. The server of claim 4, wherein the printed circuit board includes the physical GPU.

6. A system-on-a-chip device, comprising: The first circuit module is used to implement the first set of graphics processing unit (GPU) features and to implement single root input / output virtualization (SR-IOV). as well as A second circuit module is configured to implement a first driver to engage with the first circuit module. The first driver provides access to multiple virtualization functions emulating the first set of GPU features. A first virtualization function supports a second set of GPU features, a second virtualization function supports a third set of GPU features, and the second and third sets of GPU features are distinct subsets of the first set of GPU features. The first virtualization function is associated with a virtual machine. The second circuit module engages with a hypervisor that communicates with a second driver implemented by the virtual machine. The second driver provides access to the second set of GPU features supported by the first virtualization function. The second circuit module enforces a quality of service policy for executing one or more commands provided by the multiple virtualization functions using the first circuit module.

7. The device according to claim 6, further comprising the management program.

8. A method comprising: A first driver is implemented to engage with a physical graphics processing unit (GPU) for supporting a first set of features, the physical GPU for implementing single root input / output virtualization (SR-IOV), the first driver for providing access to multiple virtualization functions emulating the physical GPU, a first virtualization function for supporting a second set of features, a second virtualization function for supporting a third set of features, the second set of features and the third set of features being different subsets of the first set of features supported by the physical GPU, the first virtualization function being associated with a virtual machine; For using the physical GPU to execute one or more commands provided by the plurality of virtualization functions, a quality of service policy is enforced. as well as In conjunction with the hypervisor, the hypervisor communicates with a second driver implemented by the virtual machine, the second driver providing access to the second set of features supported by the first virtualization function in the virtualization functionality.

9. The method according to claim 8, further comprising implementing the management program.

10. The method of claim 8, wherein the virtual machine is used to execute one or more applications, the one or more applications being used to communicate with the second driver.

11. A computer-readable medium comprising instructions that, when executed, cause at least one processor to perform the method according to any one of claims 8-10.

12. An apparatus comprising a unit for performing the method according to any one of claims 8-10.

Images