CN108804199A - 图形处理器虚拟化方法及装置 - Google Patents

Abstract

本申请提供一种图形处理器虚拟化方法及装置，该方法应用于主机内核中加载的GPU主管理层，该方法包括：将图形子系统的共享资源划分为多个资源区域，在该主机内核启动阶段，为主机内核中加载的内核GPU驱动层分配一资源区域，在每个虚拟机内核启动阶段，分别为每个虚拟机内核中加载的内核GPU驱动层分配一资源区域，获取并依次转发发送者发送的服务请求以及接收并返回GPU的服务响应，该发送者包括主机和/或虚拟机。该技术方案中，发送者(虚拟机和/或主机)的服务请求只需经过内核中加载的GPU主管理层进行转发，无需经过多个中间层的拷贝和调用，在实现共享GPU的同时，提高了虚拟机的处理效率。

Description

图形处理器虚拟化方法及装置

技术领域

本申请涉及计算机技术领域，尤其涉及一种图形处理器虚拟化方法及装置。

背景技术

随着图形处理器(Graphics Processing Unit，GPU)性能的不断提升，GPU不再局限于图形处理，其在浮点运算和并行运算方面的优势也越来越明显。在GPU虚拟化之后，运行在数据中心服务器上的多个虚拟机能够实例共享同一GPU处理器进行图形运算的技术越来越广泛。

目前，GPU虚拟化共享方法主要是通过在虚拟机操作系统的用户层构建一个截获层来实现。具体的，在虚拟机需要使用GPU资源时，利用构建的截获层在API层拦截虚拟机的图形渲染请求，并将该图形渲染需求发送给主机，由主机的接收层转发给主机的API层，由该API层转发给用户层驱动，由用户层驱动转发给内核层驱动，由内核层驱动控制GPU根据该图形渲染请求执行图形渲染，执行结果再按照转发路径返回给虚拟机。

由上可知，上述方法中虚拟机与主机之间参与图形渲染请求的中间层次非常多，图形渲染请求和执行结果的返回均需要经过多次拷贝，导致虚拟机的处理效率低。

发明内容

本申请提供一种图形处理器虚拟化方法及装置，以在MIPS架构下实现GPU共享，解决虚拟机处理效率低的问题。

本申请第一方面提供的一种图形处理器虚拟化方法，应用于主机内核中加载的GPU主管理层，所述方法包括：

将图形子系统的共享资源划分为多个资源区域；

在所述主机内核启动阶段，为所述主机内核中加载的内核GPU驱动层分配一资源区域，在每个虚拟机内核启动阶段，分别为每个虚拟机内核中加载的内核GPU驱动层分配一资源区域；

获取并依次转发发送者发送的服务请求，以及接收并返回GPU的服务响应，所述发送者包括主机和/或虚拟机。

在本申请的一实施例中，所述获取并依次转发所述发送者发送的服务请求，以及接收并返回GPU的服务响应，包括：

获取所述发送者发送的服务请求；

根据预设的调度策略将所述服务请求发送给GPU，以使得所述GPU根据所述服务请求生成处理结果和服务响应；

接收所述GPU返回的服务响应并将所述服务响应发送给所述服务请求对应的发送者，以使所述发送者根据所述服务响应从所述GPU获取所述处理结果。

在本申请的上述实施例中，在所述获取所述发送者发送的服务请求之后，还包括：

检查所述服务请求是否满足合法性要求；

所述根据预设的调度策略将所述服务请求发送给GPU，以使得所述GPU根据所述服务请求生成处理结果和服务响应，包括：

当所述服务请求满足合法性要求时，根据预设的调度策略将所述服务请求发送给GPU，以使得所述GPU根据所述服务请求生成处理结果和服务响应。

在本申请的上述实施例中，所述根据预设的调度策略将所述服务请求发送给GPU，包括：

在所述发送者为主机时，直接按照预设的调度策略将所述服务请求发送给GPU；

在所述发送者为虚拟机时，将所述虚拟机内核中内核GPU驱动层的虚拟机物理地址转换为主机物理地址并按照预设的调度策略将所述服务请求发送给所述GPU。

在本申请的另一实施例中，所述将图形子系统的共享资源划分为多个资源区域，包括：

根据人工划分方案将所述图形子系统的共享资源划分为多个资源区域；或者

根据自动分配方式将所述图形子系统的共享资源划分为多个资源区域。

在本申请的上述实施例中，所述图形子系统的资源包括：寄存器空间和内存；

所述内存包括：系统内存、图形转换表GTT和显存，所述图形子系统的共享资源，包括：地址分配在无需经过内存管理单元MMU虚实地址转换操作对应处理器区域中的所述GTT和所述显存。

本申请第二方面提供的一种图形处理器虚拟化装置，所述装置包括主机内核中加载的GPU主管理层，所述装置包括：

区域划分模块，用于将图形子系统的共享资源划分为多个资源区域；

区域分配模块，用于在所述主机内核启动阶段，为所述主机内核中加载的内核GPU驱动层分配一资源区域，在每个虚拟机内核启动阶段，分别为每个虚拟机内核中加载的内核GPU驱动层分配一资源区域；

请求处理模块，用于获取并依次转发发送者发送的服务请求，以及接收并返回GPU的服务响应，所述发送者包括主机和/或虚拟机。

在本申请的一实施例中，所述请求处理模块，包括：获取单元和收发单元；

所述获取单元，用于获取所述发送者发送的服务请求；

所述收发单元，用于根据预设的调度策略将所述服务请求发送给GPU，以使得所述GPU根据所述服务请求生成处理结果和服务响应，以及接收所述GPU返回的服务响应并将所述服务响应发送给所述服务请求对应的发送者，以使所述发送者根据所述服务响应从所述GPU获取所述处理结果。

在本申请的上述实施例中，所述请求处理模块，还包括：检查单元；

所述检查单元，用于在所述获取单元获取所述发送者发送的服务请求之后，检查所述服务请求是否满足合法性要求；

所述收发单元，用于根据预设的调度策略将所述服务请求发送给GPU，以使得所述GPU根据所述服务请求生成处理结果和服务响应，具体为：

所述收发单元，具体用于在所述服务请求满足合法性要求时，根据预设的调度策略将所述服务请求发送给GPU，以使得所述GPU根据所述服务请求生成处理结果和服务响应。

在本申请的上述实施例中，所述收发单元，用于根据预设的调度策略将所述服务请求发送给GPU，具体为：

所述收发单元，具体用于在所述发送者为主机时，直接按照预设的调度策略将所述服务请求发送给GPU，在所述发送者为虚拟机时，将所述虚拟机内核中内核GPU驱动层的虚拟机物理地址转换为主机物理地址并按照预设的调度策略将所述服务请求发送给所述GPU。

在本申请的另一实施例中，所述区域划分模块，具体用于根据人工划分方案将所述图形子系统的共享资源划分为多个资源区域；或者

所述区域划分模块，具体用于根据自动分配方式将所述图形子系统的共享资源划分为多个资源区域。

在本申请的上述实施例中，所述图形子系统的资源包括：寄存器空间和内存；

所述内存包括：系统内存、图形转换表GTT和显存，所述图形子系统的共享资源，包括：地址分配在无需经过内存管理单元MMU虚实地址转换操作对应处理器区域中的所述GTT和所述显存。

本申请实施例提供的图形处理器虚拟化方法及装置，该方法应用于主机内核中加载的GPU主管理层，该方法包括：将图形子系统的共享资源划分为多个资源区域，在该主机内核启动阶段，为主机内核中加载的内核GPU驱动层分配一资源区域，在每个虚拟机内核启动阶段，分别为每个虚拟机内核中加载的内核GPU驱动层分配一资源区域，获取并依次转发发送者发送的服务请求，以及接收并返回GPU的服务响应，该发送者包括主机和/或虚拟机。该技术方案中，利用在主机内核中加载的GPU主管理层划分和分配图形子系统的共享资源，发送者(虚拟机和/或主机)的服务请求只需经过内核中加载的GPU主管理层进行转发，无需经过多个中间层的拷贝和调用，在实现共享GPU的同时，提高了虚拟机的处理效率。

附图说明

为了更清楚地说明本申请实施例或现有技术中的技术方案，下面将对实施例或现有技术描述中所需要使用的附图作一简单地介绍，显而易见地，下面描述中的附图是本申请的一些实施例，对于本领域普通技术人员来讲，在不付出创造性劳动性的前提下，还可以根据这些附图获得其他的附图。

图1为本申请提供的图形处理器虚拟化方法实施例一的流程示意图；

图2为本申请提供的图形处理器虚拟化方法实施例二的流程示意图；

图3为本申请提供的图形处理器虚拟化方法的架构示意图；

图4为本申请提供的图形处理器虚拟化装置实施例一的结构示意图；

图5为本申请提供的图形处理器虚拟化装置实施例二的结构示意图。

具体实施方式

为使本申请实施例的目的、技术方案和优点更加清楚，下面将结合本申请实施例中的附图，对本申请实施例中的技术方案进行清楚、完整地描述，显然，所描述的实施例是本申请一部分实施例，而不是全部的实施例。基于本申请中的实施例，本领域普通技术人员在没有作出创造性劳动前提下所获得的所有其他实施例，都属于本申请保护的范围。

无内部互锁流水级的微处理器(Microprocessor without Interlocked PipedStages，MIPS)是目前较流行的一种精简指令集计算机(Reduced Instruction SetComputer，RISC)，机制是尽量利用软件办法避免流水线中的数据相关问题。其中，MIPS 64位处理器中存在部分地址空间，该部分地址空间可以不经过内存管理单元(MemoryManagement Unit，MMU)的虚实地址转换便可以被使用，该特性结合交叉开关的使用能够实现对图形子系统内存的快速映射和管理，进而可使虚拟机高效直接的访问图形子系统的内存。

在现有虚拟机机制下，由于图形子系统本身的特殊性(比如，拥有自己的页表和内存，并且需要与系统内存交互)，虚拟机需要利用图形子系统的资源时，可以利用主机上设置的插槽通过硬件直通方式为每个虚拟机配置一个GPU，从而利用配置的GPU处理对应的虚拟机的服务请求(比如，图形渲染请求)，这种方式保证了每个虚拟机的处理速度，虚拟机的性能好。但每个虚拟机都需配置一个GPU，不仅使得构建成本高，而且由于主机的插槽数量有限，主机能够配置的GPU的数量有限，使得主机能够支持的虚拟机的数量受到限制。

此外，对于背景技术中利用虚拟机操作系统用户层构建的截获层来截获虚拟机的图形渲染请求，进而经过虚拟机中各层次和主机各层次的转发，最后由主机的内核层驱动控制GPU根据图形渲染请求执行图形渲染，并将执行结果再按照转发路径返回给虚拟机。这种方式参与中间层次多，数据需要经过多次拷贝，虚拟机的处理效率低。此外，由于虚拟机发送的图形渲染请求需要经过主机和虚拟机之间的应用接口拷贝到主机进行处理，若主机和虚拟机之间的应用接口不匹配，则主机则无法获取到该图形渲染请求，使得虚拟机无法实现图形渲染功能，致使出现虚拟机功能错误的问题。

针对上述问题，本申请提供了一种图形处理器虚拟化方法及装置，用于在MIPS架构下实现GPU共享，解决虚拟机处理效率低和虚拟机功能可能错误的问题。下面，通过具体实施例对本申请的技术方案进行详细说明。

需要说明的是，下面这几个具体的实施例可以相互结合，对于相同或相似的概念或过程可能在某些实施例中不再赘述。

图1为本申请提供的图形处理器虚拟化方法实施例一的流程示意图。本实施例通过主机内核在启动阶段加载的GPU主管理层来实现。具体的，如图1所示，本实施例提供的图形处理器虚拟化方法，其应用于主机内核中加载的GPU主管理层，相应的，该方法包括如下步骤：

步骤101、将图形子系统的共享资源划分为多个资源区域。

在本实施例中，主机内核在启动阶段会加载一个GPU主管理层，利用该GPU主管理层管理主机中图形子系统的资源。具体的，GPU主管理层首先获取主机在启动阶段时管理和分配所有资源的控制权，其次根据实际情况对图形子系统的共享资源进行划分，得到多个资源区域。

可选的，为了避免每个虚拟机的相互干扰，上述得到的多个资源区域与多个设备一一对应，即每个资源区域分别对应一个设备，该设备为主机或者虚拟机。

值得说明的是，本实施例并不限定GPU主管理层划分图形子系统共享资源的方式以及得到的资源区域数量，其可以是GPU主管理层根据图形子系统中共享资源的总大小按照预设划分规则将其划分为预设的若干资源区域。可选的，该预设划分规则可以是均匀分配，也可以是按照资源区域大小由大到小或由小到大的顺序分配，只要分配后的资源区域大小能够满足主机和/或虚拟机的任务需求均可，每种划分规则均属于本申请的保护范围。

GPU主管理层实际上是一个软件层，其主机内核在启动阶段是在主机原有的内核GPU驱动层下面新加载的一层，主机和/或虚拟机对图形子系统的所有操作，实际都是由主机和/或虚拟机对应的内核GPU驱动层记录，而当主机和/或虚拟机获得GPU的使用权时，主机和/或虚拟机对图形子系统的所有操作由GPU主管理层实际完成。

在实际应用中，GPU主管理层在设备的内核启动阶段(该设备包括主机和虚拟机)均会根据每个设备的注册情况为每个设备分配一段资源，该资源可以是寄存器空间或内存空间(该内存空间包括GPU中的显存(Video Random Access Memory，VRAM)和图形转换表(Graphics Translation Table，GTT))等。因而，GPU主管理层需要首先获取图形子系统在主机启动阶段所有资源分配的控制权，进而实现图形子系统的共享资源的划分。

步骤102、在主机内核启动阶段，为该主机内核中加载的内核GPU驱动层分配一资源区域，在每个虚拟机内核启动阶段，分别为每个虚拟机内核中加载的内核GPU驱动层分配一资源区域。

在本实施例中，主机内核启动阶段还会加载一个内核GPU驱动层，后续利用该内核GPU驱动层获取主机发送的服务请求，因而将图形子系统的共享资源划分为多个资源区域后，GPU主管理层便给主机的内核GPU驱动层分配一资源区域，其余资源区域留给虚拟机使用。

同理，每个虚拟机在内核启动阶段也均会加载一个内核GPU驱动层，后续利用该内核GPU驱动层获取虚拟机发送的服务请求。当虚拟机的内核GPU驱动层加载完毕之后，GPU主管理层将为每个内核GPU驱动层分别分配一资源区域。可选的，GPU主管理层为每个内核GPU驱动层分配一块独占的GTT内存区域和一个独占的显示内存区域。GPU主管理层利用地址空间中的保留位来区分不同虚拟机。

可选的，在主机或虚拟机使用图形子系统的资源时，该主机或该虚拟机中与图形子系统有关的所有数据都分别存储在分配的资源区域内。

值得说明的是，GPU主管理层属于主机的一部分，因而无论图形子系统的资源如何分配，最终图形子系统的所有资源仍处于主机的控制下，只是控制者从原来的内核GPU驱动层变成了主机中新加载的GPU主管理层。在本实施例中，MIPS 64位处理器理论可以寻址2的64次方的地址空间，这远远超出了实际需要，很多的CPU只实现了40位的寻址空间，地址空间中多出来的位均默认是0，即保留位。

步骤103、获取并依次转发发送者发送的服务请求，以及接收并返回GPU的服务响应，该发送者包括主机和/或虚拟机。

在本实施例中，在主机和/或虚拟机申请利用图形子系统的资源，比如，主机和/或虚拟机申请图形子系统执行其图形渲染时时，首先主机和/或虚拟机向GPU主管理层发送服务请求(比如，图形渲染操作对应图形渲染请求)，相应的，主机对应的主机内核中的内核GPU驱动层、虚拟机对应的虚拟机内核中的内核GPU驱动层分别获得服务请求，由主机内核中的内核GPU驱动层记录主机对GPU的操作和GPU的运行状态，由虚拟机内核中的内核GPU驱动层记录虚拟机对GPU的操作和GPU的运行状态，并分别将各自的服务请求提交给GPU主管理层，以使GPU主管理层获取主机和/或各虚拟机发送的服务请求。

可选的，在本实施例中，GPU主管理层获取到每个服务请求之后，会将满足预设条件的每个服务请求转发给图形处理器(graphics processing unit，简称GPU)，以使GPU根据该服务请求执行相应的处理。进一步的，当GPU处理完某个服务请求之后将生成一服务响应，该服务响应至少包括：请求响应结果(执行完成或执行失败)，在执行完成时，该服务响应还包括：处理数据存储位置、处理数据大小等信息，在执行失败时，该服务响应还包括：失败原因等。本实施例并不限定服务响应包括的具体内容，其可根据实际情况进行确定。

可选的，GPU生成服务响应之后，将其发送给GPU主管理层，该GPU主管理层便将服务响应返回给服务请求的发送者(主机或虚拟机)，以告知发送者执行结果。

具体的，对于图形子系统的共享资源，比如，存储空间(VRAM和GTT)，GPU主管理层检查获取到的服务请求满足预设条件后，则将GPU的部分资源分别与发送者的内核GPU驱动层申请到的资源进行绑定。

对于寄存器空间，GPU主管理层分别为发送者的内核GPU驱动层申请一段寄存器空间，将发送者的寄存器空间指向这段寄存器空间，而不是简单指向GPU的实际寄存器空间。即这意味着虚拟机或主机对GPU寄存器空间的所有操作，均不是立即生效的，实际上是由GPU主管理层对图形子系统进行操作的，而发送者实际上只是将修改了分配给对应内核GPU驱动层的寄存器空间(一段内存区域)。

值得说明的是，GPU的工作模式是由GPU的寄存器控制，因此共享GPU需要对GPU的寄存器状态现场进行备份和恢复，在每次为虚拟机或主机进行切换之前，主机的内核GPU驱动层需要保存当前的GPU状态，然后在即将运行的虚拟机或主机执行完成后恢复到主机或虚拟机最后一次挂起之前的工作状态。

可选的，对于已经分配给虚拟机内核GPU驱动层或主机内核GPU驱动层的图形子系统资源(如显存和GTT内存)，GPU主管理层是否收回由应用程序编程接口(ApplicationProgramming Interface，API)和虚拟GPU驱动层来决定，并且即使为某个任务分配的图形子系统资源(显存和GTT内存)释放了，该图形子系统资源仍为该虚拟机占有，也就是说，对于主机来说这部分资源仍是被占用的，主机不能使用。

其中，API是一些预先定义的函数，其目的是提供应用程序与开发人员基于某软件或硬件可以访问一组例程的能力，而又无需访问源码或理解内部工作机制的细节。

本申请实施例提供的图形处理器虚拟化方法，应用于主机内核中加载的GPU主管理层，该方法包括：将图形子系统的共享资源划分为多个资源区域，并在该主机内核启动阶段，为主机内核中加载的内核GPU驱动层分配一资源区域，在每个虚拟机内核启动阶段，分别为每个虚拟机内核中加载的内核GPU驱动层分配一资源区域，最后获取并依次转发发送者发送的服务请求，以及接收并返回GPU的服务响应，该发送者包括主机和/或虚拟机。该技术方案中，发送者(虚拟机和/或主机)的服务请求只需经过内核中加载的GPU主管理层进行转发，无需经过多个中间层的拷贝和调用，在实现共享GPU的同时，提高了虚拟机的处理效率。

进一步的，上述技术方案中，由于虚拟机的服务请求可以直接经过虚拟机内核直接传递给主机内核，无需经过虚拟机和主机之间的应用接口进行拷贝调用，避免了在处理过程中因主机和虚拟机的应用程序接口不匹配造成的虚拟机功能错误的问题。

进一步的，在上述实施例的基础上，上述步骤103(获取并依次转发发送者发送的服务请求，以及接收并返回GPU的服务响应，该发送者包括主机和/或虚拟机)可以通过如下方式实现，具体参见图2所示实施例。

图2为本申请提供的图形处理器虚拟化方法实施例二的流程示意图。如图2所示，在本实施例提供的图形处理器虚拟化方法中，上述步骤103，可包括如下步骤：

步骤201、获取上述发送者发送的服务请求。

在本实施例中，发送者(主机和/或虚拟机)发送服务请求之后，该服务请求首先被发送者的内核GPU驱动层获取，由内核GPU驱动层记录发送者对GPU的操作和GPU的运行状态之后，再提交给GPU主管理层，从而使GPU主管理层获取到该服务请求。

步骤202、根据预设的调度策略将上述服务请求发送给GPU，以使得GPU根据该服务请求生成处理结果和服务响应。

当GPU主管理层获取到多个服务请求之后，可以按照预设的调度策略将上述服务请求发送给GPU。可选的，该预设的调度策略可以是时间片轮转的方式，即接收到服务请求的时间先后顺序，也可以是服务请求的优先级从高到低的顺序。当然，该预设的调度策略还可以是其他的执行方式，本实施例并不对其进行限定。

在本实施例中，GPU主管理层将获取到的服务请求发送给GPU之后，GPU则对该服务请求进行处理，生成处理结果以及服务响应。该处理结果包括GPU对服务请求处理后得到的处理数据等，服务响应至少包括请求响应结果等。

步骤203、接收GPU返回的服务响应并将该服务响应发送给服务请求对应的发送者，以使发送者根据服务响应从GPU获取上述处理结果。

在本实施例中，GPU生成服务响应之后会将该服务响应返回给GPU主管理层，进而由GPU主管理层将其发送给服务请求的发送者，告知其执行结果。当发送者接收到服务请求执行完成的服务响应时，该发送者根据服务响应中携带的处理数据存储位置、处理数据大小等信息到GPU到获取服务请求对应的处理结果。

本实施例提供的图形处理器虚拟化方法，GPU主管理层首先获取上述发送者发送的服务请求，再根据预设的调度策略将上述服务请求发送给GPU，以使得GPU根据该服务请求生成处理结果和服务响应，最后接收GPU返回的服务响应并将该服务响应发送给服务请求对应的发送者，以使发送者根据服务响应从GPU获取上述处理结果，从而完成发送者的服务请求，无需经过多个中间层的拷贝和调用，提高了发送者的处理效率。

值得说明的是，从上述步骤103中的记载内容可知，GPU主管理层获取到每个服务请求之后，会对满足预设条件的每个服务请求进行转发处理，即GPU主管理层在获取到主机或虚拟机的服务请求之后，还需要对获取到的服务请求进行条件判断，比如，进行服务请求的合法性验证。因而，在图2所示实施例提供的图形处理器虚拟化方法中，在上述步骤201之后，即获取上述发送者发送的服务请求之后，该方法还可以包括如下步骤：

检查上述服务请求是否满足合法性要求。

在本实施例中，由于GPU主管理层可能获取到的服务请求比较多，为了保证GPU运行的服务请求均是合法的，进而保证GPU运行的安全性，因而，当GPU主管理层获取到发送者(各虚拟机和/或主机)发送的服务请求后，该GPU主管理层还需要判断每个服务请求是否合法。

举例来说，该服务请求可以是图形渲染请求。渲染(Render)在电脑绘图中是指用软件从模型生成图像的过程，该模型对于三维物体的描述可以用严格定义的语言或者数据结构实现，它包括几何、视点、纹理以及照明信息，该图像是数字图像或者位图图像。

作为一种示例，在本实施例中，GPU还可能被其他应用程序编程接口(ApplicationProgramming Interface，API)调用作其他工作，即上述服务请求还可以是通用计算服务，也就是说，现代GPU不仅可以加速图形运算，还可以被开放图形库(Open GraphicsLibrary，openGL)等API调用作通用运算，两者的执行流程相似。

相应的，上述步骤202可通过如下方式实现：

当上述服务请求满足合法性要求时，根据预设的调度策略将该服务请求发送给GPU，以使得GPU根据该服务请求生成处理结果和服务响应。

可选的，由于不合法的服务请求可能会对GPU以及主机带来危害，在本实施例中，GPU主管理层需要将不满足合法性要求的服务请求舍弃，而将满足合法性要求的每个服务请求按照预设的调度策略依次进行依次转发，并在每个服务请求执行完成后，GPU主管理层对服务请求的发送者返回中断(服务响应)，告知其执行结果。

在本实施例中，GPU主管理层在获取到发送者的服务请求之后，还检查每个服务请求是否满足合法性要求，并只依次转发满足合法性要求的服务请求，这样可以保证GPU处理的服务请求均能够满足合法性，从而可保证GPU和主机运行的安全性。

作为一种示例，在本实施例中，由于需要利用同一个GPU执行主机或虚拟机发送的满足合法性要求的多个服务请求，因此为了保证主机或虚拟机的功能，GPU主管理层通过时间片轮转的方式循环转发该多个服务请求。

可选的，GPU在每次执行前需要恢复到上次执行虚拟机或主机发送的服务请求时的状态，上次执行虚拟机或主机发送的服务请求时的状态由内核GPU驱动层保存，内核GPU驱动层会记录对应发送者最后一次获得GPU执行权限时的GPU工作状态，然后由GPU主管理层转发对应发送者的服务请求，并在本次转发操作对应的时间片用完后，内核GPU驱动层则将GPU的状态重新保存，供下次虚拟机或主机获得CPU执行权限时执行。

在本实施例中，时间片即GPU分配给各个程序的时间，每个线程被分配一个时间段，称作它的时间片，即该进程允许运行的时间，使各个程序从表面上看是同时进行的。

进一步的，由于服务请求的发送者不同，GPU主管理层对不同发送者的服务请求的处理操作具有一定的差异。具体的，在上述实施例图2所示实施例的基础上，对于上述步骤202中根据预设的调度策略将上述服务请求发送给GPU可具体通过如下方式实现：

可选的，作为一种示例，在上述发送者为主机时，直接按照预设的调度策略将服务请求发送给GPU。

可选的，作为另一种示例，在上述发送者为虚拟机时，将虚拟机内核中内核GPU驱动层的虚拟机物理地址转换为主机物理地址并按照预设的调度策略将服务请求发送给GPU。

具体的，由于GPU主管理层只能对主机的物理地址进行寻址，因而，对于主机发送的满足合法性要求的服务请求，GPU主管理层可以直接按照预设的调度策略将服务请求发送给GPU，而对于虚拟机发送的满足合法性要求的服务请求，由于虚拟机内核中内核GPU驱动层的虚拟机物理地址并不是主机的物理地址，因此GPU主管理层在按照预设的调度策略转发获取到的虚拟机的服务请求时，需要将虚拟机物理地址转换为主机物理地址，这样GPU主管理层才会转发该服务请求，以使GPU对其进行接收并处理。

该技术方案在GPU主管理层获取到发送者发送的满足合法性要求的服务请求时，若该发送者为虚拟机，则直接按照预设的调度策略将上述服务请求发送给GPU，而在发送者为虚拟机时，首先将虚拟机内核中内核GPU驱动层的虚拟机物理地址转换为主机物理地址再按照预设的调度策略将服务请求发送给GPU，这样能够保证GPU主管理层在执行服务请求中的主体一致性，保证服务请求的执行。

可选的，在上述实施例的基础上，对于上述步骤101中将图形子系统的共享资源划分为多个资源区域的实现方式有多种，以下介绍两者资源划分方式：

作为一种示例，根据人工划分方案将图形子系统的共享资源划分为多个资源区域。

具体的，操作者必须首先了解虚拟机和所要执行任务的大体情况，例如，共享图形子系统资源的虚拟机的个数，每个虚拟机所要执行任务所需的资源大小等，进而操作者可根据虚拟机的任务需求制定一划分方案(定义为人工划分方案)，因此在对图形子系统的共享资源进行划分时，GPU主管理层可根据上述操作者制定的人工划分方案将图形子系统的共享资源划分为多个资源区域。

该划分方式得到的每个资源区域基本上能够满足虚拟机的任务需求，但是其要求操作者对虚拟机和所执行的任务有较深的理解，对操作者的专业能力要求比较高。

作为另一种示例，根据自动分配方式将图形子系统的共享资源划分为多个资源区域。

在本实施例中，若操作者对虚拟机以及虚拟机要执行的任务不太了解，可以选择GPU主管理层自动分配方式进行划分，因而在需要对图形子系统的共享资源进行划分时，GPU主管理层则会按照设定的自动分配方式得到一常规资源分配方案，进而按照该资源分配方案将图形子系统的共享资源划分为多个资源区域。这种分配方式适合对虚拟机不太了解的操作者。

可选的，在本实施例提供的图形处理器虚拟化方法中，上述图形子系统的资源包括：寄存器空间和内存。

其中，该内存包括：系统内存、图形转换表GTT和显存。

上述图形子系统的共享资源，包括：地址分配在无需经过内存管理单元MMU虚实地址转换操作对应处理器区域中的GTT和显存。

具体的，对于寄存器空间，根据上述步骤103中的加载可知，GPU主管理层将发送者的寄存器空间指向GPU主管理层为发送者的内核GPU驱动层申请的这段寄存器空间，进而实现寄存器空间的共享。

图形子系统的内存可分为三部分，包括系统内存、GTT、显存(VRAM)。由于系统内存仅供CPU使用，GPU不会使用，不需要作特殊处理。由于CPU和GPU都可能会访问GTT和显存，因而需要将GTT和显存的资源划分为不同的区域，进而使不同的虚拟机使用不同的区域资源。

其中，图形转换表GTT是一段被CPU和GPU的页表同时映射，CPU和GPU都能访问到的一段内存。显存又称帧存储器、刷新存储器，也是CPU和GPU均能访问到的一段内存。

在MIPS 64处理器中，图形子系统的GTT和VRAM的地址分配在MIPS64中地址直接映射的区域(该区域可以不需要查询页表，物理地址和逻辑地址存在直接映射关系，而其他区域需要MMU查询页表才能得到)，这样有效简化了主机和/或虚拟机使用图形子系统内存的流程。其中，MMU是CPU中用来管理虚拟存储器、物理存储器的控制线路，同时也负责虚拟地址映射为物理地址以及提供硬件机制的内存访问授权，属于多用户多进程操作系统。

在本实施例中，通过GPU主管理层将图形子系统的VRAM和GTT都划分为若干资源区域后，分别从中各抽出一个资源区域给主机使用，VRAM和GTT中其余的资源区域保留给虚拟机使用。

在上述任一实施例的基础上，图3为本申请提供的图形处理器虚拟化方法的架构示意图。如图3所示，该架构示意图包括主机用户层、主机内核和图形子系统硬件。

具体的，该架构示意图可以理解为其是主机的一种布局示意图，即主机包括主机用户层、主机内核以及图形子系统硬件等部分。

在本实施例中，所有的GPU控制命令(包括执行图形渲染请求和分配显存资源)都由主机内核中的GPU主管理层(新增的中间层)管理。该GPU主管理层将图形子系统的共享资源划分为若干区域(未示出)，不同虚拟机或主机进程通过交叉开关配置后分别访问各自不同的物理地址。GPU主管理层可以将上述不同的物理地址反馈给虚拟机或主机进程，进而虚拟机或主机可直接使用各自的物理地址(经过交叉开关转换)访问分配给各自的GTT和VRAM显存。当数据准备完后，虚拟机或主机向GPU主管理层提交服务请求(图形渲染请求)，等待GPU主管理层为其分配可用的时间片。

值得说明的是，该图3仅示出了主机和/或虚拟机使用图形子系统的共享资源时的使用数据流的示意图，关于GPU主管理层对图形子系统共享资源的划分和分配流程，该图3中并未示出。

其中，本实施例以主机上集成两个虚拟机进行说明，实际上是，虚拟机1和虚拟机2集成在主机用户层以调用GPU执行其服务请求。作为一种示例，如图3所示，图形子系统硬件中的VRAM1和GTT1分配给主机占用，VRAM2和GTT2分配给虚拟机1占用，VRAM3和GTT3分配给虚拟机2占用，且主机、虚拟机1和虚拟机2的数据流如图3所示。

此外，如图3所示，主机用户层的应用程序通过GPU用户层驱动、位于主机内核上的内核GPU驱动层连接到GPU主管理层，虚拟机1和虚拟机2上的应用程序分别通过各自的GPU用户层驱动、内核GPU驱动层连接到主机内核中的KVM，再连接到GPU主管理层，由GPU主管理层统一实现GPU控制流的控制。

其中，基于内核的虚拟机(Kernel-based Virtual Machine，KVM)是一个内核态的虚拟机模块，其能够为硬件虚拟化提供了很多支持，虚拟机能够通过KVM使用硬件的很多高级虚拟化特性(例如，影子页表等)，若无KVM用户态的虚拟机只能用纯软件虚拟化方案，效率很低，因而本实施例中通过使用KVM提高了虚拟机的运行效率。

下述为本申请装置实施例，可以用于执行本申请方法实施例。对于本申请装置实施例中未披露的细节，请参照本申请方法实施例。

图4为本申请提供的图形处理器虚拟化装置实施例一的结构示意图。本实施例提供的图形处理器虚拟化装置，包括：主机内核中加载的GPU主管理层。如图4所示，该装置包括：区域划分模块401、区域分配模块402和请求处理模块403。

该区域划分模块401，用于将图形子系统的共享资源划分为多个资源区域。

该区域分配模块402，用于在所述主机内核启动阶段，为所述主机内核中加载的内核GPU驱动层分配一资源区域，在每个虚拟机内核启动阶段，分别为每个虚拟机内核中加载的内核GPU驱动层分配一资源区域。

该请求处理模块403，用于获取并依次转发发送者发送的服务请求，以及接收并返回GPU的服务响应，所述发送者包括主机和/或虚拟机。

本申请实施例提供的图形处理器虚拟化装置，可用于执行如图1所示方法实施例的技术方案，其实现原理和技术效果类似，此处不再赘述。

可选的，在上述实施例的基础上，图5为本申请提供的图形处理器虚拟化装置实施例二的结构示意图。如图5所示，在本实施例中，上述请求处理模块403，包括：获取单元501和收发单元502。

其中，该获取单元501，用于获取所述发送者发送的服务请求。

该收发单元502，用于根据预设的调度策略将所述服务请求发送给GPU，以使得所述GPU根据所述服务请求生成处理结果和服务响应，以及接收所述GPU返回的服务响应并将所述服务响应发送给所述服务请求对应的发送者，以使所述发送者根据所述服务响应从所述GPU获取所述处理结果。

本申请实施例提供的图形处理器虚拟化装置，可用于执行如图2所示方法实施例的技术方案，其实现原理和技术效果类似，此处不再赘述。

可选的，在上述图5所示实施例的基础上，上述请求处理模块403，还包括：检查单元。

该检查单元，用于在所述获取单元501获取所述发送者发送的服务请求之后，检查所述服务请求是否满足合法性要求。

相应的，上述收发单元502，用于根据预设的调度策略将所述服务请求发送给GPU，以使得所述GPU根据所述服务请求生成处理结果和服务响应，具体为：

上述收发单元502，具体用于在所述服务请求满足合法性要求时，根据预设的调度策略将所述服务请求发送给GPU，以使得所述GPU根据所述服务请求生成处理结果和服务响应。

可选的，在上述实施例中，所述收发单元502，用于根据预设的调度策略将所述服务请求发送给GPU，具体为：

所述收发单元502，具体用于在所述发送者为主机时，直接按照预设的调度策略将所述服务请求发送给GPU，在所述发送者为虚拟机时，将所述虚拟机内核中内核GPU驱动层的虚拟机物理地址转换为主机物理地址并按照预设的调度策略将所述服务请求发送给所述GPU。

进一步的，作为一种示例，上述区域划分模块401，具有用于根据人工划分方案将所述图形子系统的共享资源划分为多个资源区域。

作为另一种示例，上述区域划分模块401，具有用于根据自动分配方式将所述图形子系统的共享资源划分为多个资源区域。

可选的，上述图形子系统的资源包括：寄存器空间和内存。

所述内存包括：系统内存、图形转换表GTT和显存，所述图形子系统的共享资源，包括：地址分配在无需经过内存管理单元MMU虚实地址转换操作对应处理器区域中的所述GTT和所述显存。

本领域普通技术人员可以理解：实现上述各方法实施例的全部或部分步骤可以通过程序指令相关的硬件来完成。前述的程序可以存储于一计算机可读取存储介质中。该程序在执行时，执行包括上述各方法实施例的步骤；而前述的存储介质包括：ROM、RAM、磁碟或者光盘等各种可以存储程序代码的介质。

最后应说明的是：以上各实施例仅用以说明本申请的技术方案，而非对其限制；尽管参照前述各实施例对本申请进行了详细的说明，本领域的普通技术人员应当理解：其依然可以对前述各实施例所记载的技术方案进行修改，或者对其中部分或者全部技术特征进行等同替换；而这些修改或者替换，并不使相应技术方案的本质脱离本申请各实施例技术方案的范围。

Claims (12)

1.一种图形处理器虚拟化方法，其特征在于，应用于主机内核中加载的GPU主管理层，所述方法包括：

将图形子系统的共享资源划分为多个资源区域；

在所述主机内核启动阶段，为所述主机内核中加载的内核GPU驱动层分配一资源区域，在每个虚拟机内核启动阶段，分别为每个虚拟机内核中加载的内核GPU驱动层分配一资源区域；

获取并依次转发发送者发送的服务请求，以及接收并返回GPU的服务响应，所述发送者包括主机和/或虚拟机。

2.根据权利要求1所述的方法，其特征在于，所述获取并依次转发所述发送者发送的服务请求，以及接收并返回GPU的服务响应，包括：

获取所述发送者发送的服务请求；

根据预设的调度策略将所述服务请求发送给GPU，以使得所述GPU根据所述服务请求生成处理结果和服务响应；

接收所述GPU返回的服务响应并将所述服务响应发送给所述服务请求对应的发送者，以使所述发送者根据所述服务响应从所述GPU获取所述处理结果。

3.根据权利要求2所述的方法，其特征在于，在所述获取所述发送者发送的服务请求之后，还包括：

检查所述服务请求是否满足合法性要求；

所述根据预设的调度策略将所述服务请求发送给GPU，以使得所述GPU根据所述服务请求生成处理结果和服务响应，包括：

当所述服务请求满足合法性要求时，根据预设的调度策略将所述服务请求发送给GPU，以使得所述GPU根据所述服务请求生成处理结果和服务响应。

4.根据权利要求2或3所述的方法，其特征在于，所述根据预设的调度策略将所述服务请求发送给GPU，包括：

在所述发送者为主机时，直接按照预设的调度策略将所述服务请求发送给GPU；

在所述发送者为虚拟机时，将所述虚拟机内核中内核GPU驱动层的虚拟机物理地址转换为主机物理地址并按照预设的调度策略将所述服务请求发送给所述GPU。

5.根据权利要求1所述的方法，其特征在于，所述将图形子系统的共享资源划分为多个资源区域，包括：

根据人工划分方案将所述图形子系统的共享资源划分为多个资源区域；或者

根据自动分配方式将所述图形子系统的共享资源划分为多个资源区域。

6.根据权利要求5所述的方法，其特征在于，所述图形子系统的资源包括：寄存器空间和内存；

所述内存包括：系统内存、图形转换表GTT和显存，所述图形子系统的共享资源，包括：地址分配在无需经过内存管理单元MMU虚实地址转换操作对应处理器区域中的所述GTT和所述显存。

7.一种图形处理器虚拟化装置，其特征在于，所述装置包括主机内核中加载的GPU主管理层，所述装置包括：

区域划分模块，用于将图形子系统的共享资源划分为多个资源区域；

区域分配模块，用于在所述主机内核启动阶段，为所述主机内核中加载的内核GPU驱动层分配一资源区域，在每个虚拟机内核启动阶段，分别为每个虚拟机内核中加载的内核GPU驱动层分配一资源区域；

请求处理模块，用于获取并依次转发发送者发送的服务请求，以及接收并返回GPU的服务响应，所述发送者包括主机和/或虚拟机。

8.根据权利要求7所述的装置，其特征在于，所述请求处理模块，包括：获取单元和收发单元；

所述获取单元，用于获取所述发送者发送的服务请求；

所述收发单元，用于根据预设的调度策略将所述服务请求发送给GPU，以使得所述GPU根据所述服务请求生成处理结果和服务响应，以及接收所述GPU返回的服务响应并将所述服务响应发送给所述服务请求对应的发送者，以使所述发送者根据所述服务响应从所述GPU获取所述处理结果。

9.根据权利要求8所述的装置，其特征在于，所述请求处理模块，还包括：检查单元；

所述检查单元，用于在所述获取单元获取所述发送者发送的服务请求之后，检查所述服务请求是否满足合法性要求；

所述收发单元，用于根据预设的调度策略将所述服务请求发送给GPU，以使得所述GPU根据所述服务请求生成处理结果和服务响应，具体为：

所述收发单元，具体用于在所述服务请求满足合法性要求时，根据预设的调度策略将所述服务请求发送给GPU，以使得所述GPU根据所述服务请求生成处理结果和服务响应。

10.根据权利要求8或9所述的装置，其特征在于，所述收发单元，用于根据预设的调度策略将所述服务请求发送给GPU，具体为：

所述收发单元，具体用于在所述发送者为主机时，直接按照预设的调度策略将所述服务请求发送给GPU，在所述发送者为虚拟机时，将所述虚拟机内核中内核GPU驱动层的虚拟机物理地址转换为主机物理地址并按照预设的调度策略将所述服务请求发送给所述GPU。

11.根据权利要求7所述的装置，其特征在于，所述区域划分模块，具体用于根据人工划分方案将所述图形子系统的共享资源划分为多个资源区域；或者

所述区域划分模块，具体用于根据自动分配方式将所述图形子系统的共享资源划分为多个资源区域。

12.根据权利要求11所述的装置，其特征在于，所述图形子系统的资源包括：寄存器空间和内存；

所述内存包括：系统内存、图形转换表GTT和显存，所述图形子系统的共享资源，包括：地址分配在无需经过内存管理单元MMU虚实地址转换操作对应处理器区域中的所述GTT和所述显存。