用于对来宾虚拟机的硬件资源进行虚拟化的专用虚拟机

摘要

计算系统包括图形处理单元(GPU)、以及主处理电路，所述主处理电路用于执行计算机程序指令以形成：管理程序、控制虚拟机(VM)以及用于图形处理的专用渲染VM。来宾VM的应用程序根据诸如直接3D等的图形API生成图形命令和数据。渲染VM包括GPU本地的图形驱动器，并且控制VM向渲染VM指派对GPU的直通访问。渲染VM经由VM间通信信道从应用程序接收图形信息，并且渲染VM使用图形驱动器控制GPU以执行图形渲染。使用渲染VM使得能够在无需迫使控制VM使用兼容操作系统的情况下实现本地图形性能。本技术通常可应用于专用VM对硬件资源的虚拟化。

说明书

技术领域

本发明涉及计算机系统领域，并且在一个方面，涉及诸如计算机 图形单元等的专用硬件资源的处理。

背景技术

在计算机图形领域，使用专用图形处理单元或GPU来提供对某 些图形操作的基于硬件的加速是已知的。举例说明，现代的GPU可以 执行诸如以下各项的操作：纹理映射、高速多边形渲染以及具有高度 平行的结构的硬件电路中的描影，以得到高处理吞吐量。GPU执行的 处理通常用于在图形显示器上渲染应用程序的图形图像的目的。GPU 对于很多图形密集的计算机应用尤其有用，例如包括：视频游戏以及 高级图形合成和编辑工具。

发明内容

有效地使用采用“虚拟化”技术的计算机系统(即，具有主机硬 件和支持运行多个虚拟计算机或“虚拟机”(VM)的软件的计算机系 统)中的GPU或类似专用硬件资源可能是有挑战的。GPU不像存储 器或存储设备一样可分割，因此基于此，不能指派GPU以由不同的 VM使用。

用于GPU虚拟化的一种方式用于基于所谓的XEN架构的虚拟计 算系统中，该XEN架构表征了开源管理程序和运行Linux操作系统的 控制VM。Linux提供了对称作OpenGL的图形应用编程界面(API) 的本地支持。运行操作系统的系统通常利用称作DirectX 的族的不同图形API。具体地，用于三维图形的特定DirectX API被称 作“Direct 3D”或“D3D”。在来宾VM正在运行Windows的XEN虚 拟计算系统中，采用称作“Wine”的开源转换程序来提供D3D API 与OpenGL之间的转换是必要的。Wine程序被部署在控制VM中，并 且来宾VM配置有特殊的驱动器，该特殊的驱动器将由应用程序生成 的D3D功能调用路由到控制VM。在控制VM，Wine使用OpenGL 操作来处理D3D功能调用。

然而，与针对GPU使用本地D3D驱动器的系统相反，使用转换 程序和单独的图形API(例如，Wine和OpenGL)可能施加性能惩罚。 首先是转换过程本身，其赋予额外延迟并且可能减少图形吞吐量。此 外，由D3D而非OpenGL提供的功能必须以某种备选方式运行，例如， 某种形式的仿真，这相对于GPU辅助的运行可能显著地降低性能。将 期望诸如XEN系统等的基于Linux的虚拟计算系统提供对Windows  D3D API的支持，而不会过分地牺牲图形性能。

公开了用于对诸如图形硬件等的专用硬件资源进行虚拟化的技 术，其克服了如上所述的现有虚拟化技术的限制，从而在无需降低性 能的转换和仿真的情况下提供了部署灵活性。虽然该技术可能在诸如 基于XEN的平台等的开源平台中特别有用，但是它更一般地可应用 于基于其他架构的系统。

在一个方面，所公开的计算系统包括：图形处理单元，以及主处 理电路，该主处理电路可操作以执行形计算机程序指令以形成：管理 程序、控制虚拟机、和用于图形处理的专用渲染虚拟机。与在传统虚 拟计算平台中一样，管理程序提供了对计算系统的硬件的虚拟化，而 控制虚拟机管理计算系统的渲染虚拟机和来宾虚拟机。技术支持通过 来宾虚拟机的应用程序对图形处理单元的共享使用，其中，来宾虚拟 机的应用程序根据诸如D3D API等的指定图形API生成图形信息(通 常包括图形命令和图形数据)。

渲染虚拟机包括图形处理单元本地的图形驱动器，并且控制虚拟 机向渲染虚拟机指派了对图形处理单元的直通访问。也即是说，渲染 虚拟机能够直接与GPU进行通信以控制其操作，而无需像对其他硬件 资源所进行的那样通过管理程序进行虚拟化。渲染虚拟机经由虚拟机 间通信信道从应用程序接收图形信息，并且使用图形驱动器基于图形 信息控制图形处理单元的操作以执行图形渲染操作。

由于渲染VM与控制VM分离，因此它可以使用支持本地图形驱 动器(例如，Windows)的操作系统，而控制VM可以使用可能不与 驱动器兼容但是具有诸如开源可用性等的其他优点的不同操作系统 (例如，Linux)。控制VM不直接参与图形处理，使得不同图形API 之间的性能降低的转换不必要。此外，由于其专门的属性，因此渲染 虚拟机可以实现为相对低功能的机器——它可能不需要诸如网络接入、 复杂的文件系统、用户界面等的功能。因此，它可以使用所谓的“嵌 入式”操作系统，所谓的“嵌入式”操作系统与通常在通用VM中使 用的全功能操作系统相比不那么资源密集且不那么昂贵。

所公开的技术已经广泛地应用于其他类型的硬件资源的虚拟化。

附图说明

通过如附图所示的对本发明的特定实施例的以下描述，前述和其 他目的、特征和优点将显而易见，在附图中，相似的附图标记贯穿不 同的视图指代相同的部分。

图1是计算机系统的框图；

图2(a)至图2(c)是图形用户界面显示屏的示意图；

图3是计算机系统的某些元件的框图；以及

图4是计算机系统的某些操作的流程图。

具体实施方式

图1示出了具有硬件资源(或硬件)集10和软件实现的组件的 计算机，软件实现组件包括管理程序12和虚拟机(VM)集合，VM 集合被示出为控制VM 14、渲染VM 16和一个或多个来宾VM 18(示 出了两个来宾VM 18-1和18-2)。管理程序12、控制VM 14和渲染 VM 16是特许的系统组件，这意味着它们通常有权直接访问硬件10 中的一些或全部，而来宾VM 18相对不享有特权，并且依赖于特权系 统组件为了其对硬件10的使用的虚拟化和其他功能。硬件10通常包 括一个或多个处理器、存储器、和提供功能互连以在这些组件之间进 行数据传递的一个或多个高速数据总线。为了便于本文参考，这些组 件的集合被称作“主处理电路”，其反映了处理包括管理程序12和VM 14-18的软件实现组件的计算机程序指令的功能。硬件10通常还包括 I/O电路，I/O电路可以包括例如网络接口电路、存储设备(例如，闪 存或磁盘)、以及针对用户接口设备(例如，定点设备、键盘和图形显 示设备)的接口电路。

如图所示，硬件10包括视频接口电路(VIDEO INTFC)19，其 包括图形处理单元(GPU)20。视频接口电路19提供了针对诸如LCD 显示器(未示出)等的图形显示设备的接口。GPU 10包括专用于执行 图形渲染操作的电路。这种电路也可以称作“图形加速器”。具体地， 在一个实施例中，GPU 20包括三维(3-D)渲染的能力。

控制VM 14是用于管理和控制计算机(包括实例化渲染VM 16 和来宾VM 18以及配置和控制其操作的某些方面)的专用VM。通过 控制连接22在图1中指示了该控制功能。

控制VM 14可以备选地称作“控制域”、“域0”或“dom0”，后 面的名字可以应用于向连续实例化的VM给予相应序号0、1、2…… 的系统。控制VM 14还例如通过“控制台”或本领域中众所周知的类 似的用户界面程序向计算机的人工操作员提供界面。在一个实施例中， 控制VM 14运行Linux操作系统。下面描述控制VM 14的某些具体 的功能。

来宾VM 18通常是全功能VM，其优选地尽可能接近完全虚拟化， 这意味着它们可以在相对于非虚拟化形式具有较少改变的情况下运行 软件(特别是操作系统)。如图所示，每一个来宾VM 18包括操作系 统(O/S)24和一个或多个应用程序(APPL)26。在一个实施例中， 操作系统24可以是在个人计算机中使用的操作系统。应当 注意的是，不同的来宾VM 18可以运行不同类型的操作系统24。

操作系统24被示出为包括图形“伪驱动器”(PSEUDO DRV)28， 其经由虚拟机间(VM间)通信信道30可操作地耦合到渲染VM 16。 使用来宾VM 18中的第一VM间(V到V)信道接口(V-V)31和渲 染VM 16中的第二VM间信道接口33来实现VM间通信信道30(下 面分别将它们称作“客户端型”和“服务器型”)。在这一方面，操作 系统24被专门修改以在诸如图1中所示的虚拟化计算系统等的虚拟化 计算系统中运行。在非虚拟化设置中，操作系统通常包括图形驱动器， 该图形驱动器可操作地直接耦合到诸如GPU等的图形处理电路，从而 以相对低的等级控制图形操作的执行(例如，对参数和操作码进行编 程、对操作的状态和完成进行监控等)。相比之下，伪驱动器28主要 用于经由VM间通信信道30在应用程序26与渲染VM 16之间仅传递 图形命令、响应和数据(统称为“图形信息”)。通过渲染VM 16和 GPU 20来对图形命令进行实际处理，如下所述。

渲染VM 16是向来宾VM 18提供图形处理能力的专用VM。向 渲染VM 16指派对GPU 20的直接“直通”访问32，这意味着本地驱 动器(NTV DRV)34如在传统的非虚拟化设置中一样控制GPU 20并 且与GPU 20直接进行通信，而无需管理程序12提供虚拟化。由于渲 染VM 16的特殊目的的属性，渲染VM 16采用没有来宾VM 18的操 作系统26那么实用的操作系统36。例如，操作系统36可能不能支持 传统的文件系统或丰富的用户界面，并且操作系统36可能仅支持有限 的存储并且提供很少或不提供用户扩展性。在一个实施例中，操作系 统36可以是所谓的“嵌入式”或“实时”操作系统，用于各种专用计 算设备的类型包括本领域中众所周知的蜂窝电话。在一个实施例中， 操作系统36可以是嵌入式操作系统的Windows嵌入式簇的成员。

操作系统36被示出为包括VM间信道接口33，每一个VM间信 道接口33可操作地耦合到相应的VM间通信信道30和本地驱动器34。 在操作中，每一个VM间信道接口33与其相应的VM间信道接口31 互补地操作，从而实现经由VM间通信信道30在本地驱动器34与应 用程序26之间传递图形信息。

在图1中，管理程序12和VM 14-18被示出为与硬件10分离， 这是为了描述的目的的典型且有用的描绘。应当理解的是，这些软件 实现组件在其运行期间实际上包括主处理电路。因此，当执行管理程 序的指令时，管理程序12例如包括硬件10的主处理电路。类似的描 述可应用于VM 14-18。

图1的布置可能特别适合于与具有图形密集工作量的应用程序26 (例如，视频游戏)一起使用。在该情况下，它可以是个人设备，例 如，台式机、控制台、或移动平台。但是，布置也可以用于服务器型 计算设备，例如，针对在服务器上执行的应用程序提供渲染图形的远 程显示的服务器。

在现有系统中，已知的是在控制VM内提供图形驱动器以向来宾 VM提供对图形硬件的共享访问(例如，使用与VM间信道30类似的 VM间信道)。这种控制VM可以采用Linux操作系统，并且利用该 Linux操作系统，开源图形驱动器根据所谓的OpenGL应用编程界面 (API)操作。相比之下，来宾VM可以使用其他操作系统，例如， 簇的可以使用称作DirectX的专有簇的不同图形API的操作 系统，该图形API的一个版本被称作Direct 3D或“D3D”，并且用于 三维图形渲染。在这些类型的系统中，必须采用称作Wine的转换程 序以在D3D与OpenGL API之间转换。因为并非D3D提供的所有图 形功能都在OpenGL中可用，因此这些系统中的图形性能通常低于针 对图形硬件使用本地D3D驱动器的非虚拟化系统。

图1的结构的优点之一是能够针对GPU 20使用本地驱动器34(例 如，D3D驱动器)，然而，驱动器可能不与控制VM 14的操作系统(例 如，Linux)兼容。本地驱动器34被置于专用渲染VM 16中，该专用 渲染VM 16使用兼容的操作系统(例如，Windows)，并且控制VM 14 建立VM间通信信道30以使得能够在来宾VM 18与共享的本地驱动 器34之间传递图形信息(例如，D3D功能调用和数据)。还向本地驱 动器34提供对GPU 20的直通访问，如上所述。使用基于Linux的控 制VM 14不会影响图形性能，这是因为它不像使用OpenGL和Wine 的现有系统中一样直接参与图形处理。

图2(a)至图2(c)从用户的角度提供了对计算机系统的操作的 简化描述。具体地，其中的每一个表示图形显示设备(例如，LCD显 示器)在操作期间的屏幕。图2(a)示出了用于由控制VM 14执行 的系统控制程序的形成用户界面的一部分的控制屏幕40。屏幕40尤 其由用户使用以选择来宾VM 18中的哪一个是“聚焦的”，即，具有 出现在显示设备上的图形输出并且接受来自用户输入设备(键盘、鼠 标等)的输入。控制屏幕40可以具有区域42，诸如图标、下拉菜单 等的控制特征可以位于该区域42中和/或可以从该区域42激活诸如图 标、下拉菜单等的控制特征。它还可以包括表示正在运行的VM(在 该情况下，针对两个来宾VM 18-1和18-2)的相应图标44(44-1和 44-2)。用户通过激活相应的图标44来选择聚焦(focus)。如图所示， 激活图标44-1使来宾VM 18-1的屏幕46-1被显示(图2(b))，而激 活图标44-2使来宾VM 18-2的屏幕46-2被显示(图2(c))。在所示 的示例中，屏幕46-1包括位于来宾VM 18-1的桌面背景上的两个窗 口48、50，而屏幕46-2显示了针对来宾VM 18-2的一个大窗口52。 通过在图2(b)和图2(c)的状态中的任意一个下的显示，可以仅使 用键盘(例如，通过表示系统级控制命令的一系列键)或使用鼠标(通 过使鼠标来到屏幕边缘以使控制屏幕或工具栏出现)来完成用于改变 聚焦的用户命令。

图3示出了被垂直布置以反映相对于图1的应用程序26和GPU 20的功能位置的参与图形处理的组件集。在上部位置，伪驱动器28 面对应用26。每一个伪驱动器28与客户端型VM间接口31进行通信， 客户端型VM间接口31进而经由相应的VM间通信信道30与服务器 型VM间接口33进行通信。每一个服务器型VM间接口33与控制 GPU 20的操作的本地驱动器34进行通信。

图4是示出了图1的计算机的相关操作(具体地，渲染VM 16 的图形相关操作)的简化流程图。在60，渲染VM 16经由VM间通 信信道30从来宾VM 18的应用程序26接收图形信息。图形信息符合 图形处理单元20支持的图形API，例如，上述D3D图形API。如上 所述，渲染VM 16采用针对VM间通信信道30的服务器型VM间接 口33。使用VM间通信信道30的传输消息来发送图形信息。

在62，服务器型VM间接口33向本地驱动器34传递接收的图形 信息。

在64，本地驱动器34使用接收的图形信息控制图形处理单元20 的操作以执行图形渲染操作。该控制可以具有以下形式：对参数和操 作码进行编程、对操作的状态和完成进行监控等，如上所述。

在诸如图1中所示的系统中(其中，GPU 20是本地视频接口电 路19的一部分)，GPU 20的渲染操作的结果可以表示要在本地显示设 备(例如，上述屏幕42、46)上显示的屏幕。在一些情况下，可以以 不同的方式使用结果。一种一般的备选方式是使用远程显示设备，即， 本地应用26生成要在附接到另一物理计算机的显示设备上显示的屏 幕图形信息。在该情况下，可以将渲染操作的结果返回请求应用26， 例如，以使应用26能够将结果发送到将显示结果的另一计算机。渲染 结果的其他后端处理是可能的。

虽然上述描述集中于具体地用于支持图形操作的方法和装置，但 是可以对其进行略微一般化以针对除了图形操作之外的操作提供对硬 件资源的共享访问。关于GPU，例如，越来越多地针对非图形任务使 用现代GPU，其采用由GPU在硬件中执行的矢量计算和其他计算。 在这种类型的使用中，GPU可以称作“通用GPU”。关于图1的结构， 为了支持该使用的唯一主要修改是驱动器28和34支持应用程序24 不论使用什么API来访问硬件资源。

所公开的技术还可以被一般化为利用专用VM(与渲染VM 18类 似)，其与控制VM 14相比，与来宾VM 18更兼容。在这一方面，假 设来宾VM 18采用第一种类型的操作系统(例如，Windows)，而控 制VM 14使用不同类型的第二操作系统(例如，Linux)，并且在第二 操作系统下不存在或者仅存在有限的对系统功能的支持，其中，第一 操作系统更充分地支持系统功能。在该情况下，系统功能(或针对系 统功能的控制软件，例如，设备驱动器)可以被部署在运行第一操作 系统的专用VM(与渲染VM 16类似)上，并且VM间通信方案可以 用于使得能够从来宾VM 18访问功能。该布置使基于第二操作系统的 虚拟化计算机能够以本地方式支持第一操作系统的功能。