读《VMM-Independent Graphics Acceleration》[1]

这篇文章主要介绍了VMGL，基于OpenGL的独立于VMM和GPU的虚拟化图形加速的解决方案。在作了一些背景知识介绍后，作者对VMGL进行了说明解释，并对其进行了性能评测，最后介绍了相关工作并给出未来的设想。

对于浮点运算，GPU性能要比x86架构的CPU好一个数量级。所以，在对图形处理有要求的应用中，GPU是必须的。而目前在虚拟机中，对GPU的虚拟化存在一些难处。

1.GPU的硬件接口都有专利保护，许多技术细节都被视为商业机密，而这些细节对于虚拟一个GPU来说又是有用的。

2.由于硬件接口是非公开的，GPU制造商随着他们产品的更新换代对这些接口作了很大的改动。因此，对这么多种类的接口进行虚拟存在难度。

3.设备驱动的闭源性（closed-source）使得一个VM的设备驱动不能被另一个VM所用。

总之，一个硬部件的虚拟化需要一个统一的接口标准，如x86指令集，或磁盘的IDE和SCSI接口，而GPU缺少这样的标准。

VMGL对OpenGL软件接口进行了虚拟化，是在API层面上的虚拟化。这样，VMGL能同时支持多个guest OS，支持不同厂商提供的GPU，并有暂停和恢复功能，此外对多核也有支持。经过对它的性能评价，其性能要比用软件实现好两个数量级,而比起物理机其性能最多下降14%甚至持平。

图1展示了VMGL的体系结构，这包括3个模块：VMGL库、VMGL stub和VMGL 窗口服务扩展（VMGL X server extension）。在guest Os中，用VMGL库作为OpenGL的替代者。当应用程序启动时，在host Os端启动一个VMGL stub。当guest中的应用程序发出GL相关命令时，VMGL库则通过回环连接的网络传输把命令转发给VMGL stub。每个应用程序都有一个不同的VMGL stub，而且每个stub在host中都作为一个独立的进程。

在host端有一个基于VNC的查看器，它显示有guest产生的2D输出，并捕获用户输入并传回给guest。guest的2D输出由一个X服务器产生，X服务器对虚拟2D帧缓冲区写入。如果没有虚拟帧缓冲，2D输出就有一个VNC X server产生。他们修改了VNC查看器，使之于VMGL stub交互。

为了整合查看器（viewer）的2D输出和VMGL stub的3D GL输出，在guest端增加了一个VMGL扩展。当扩展把信息传给stub后，stub把当前用户不可见的冗余信息去除，把结果与window整合，再传回guest。

VMGL中传统的GLX被WireGL代替以高其性能。

VMGL支持VM的暂停、恢复功能，让用户会话被打断后能在不同计算机间移动。恢复后的图形状态和暂停前一样，而且保持硬件加速的能力。VMGL是通过一个叫影子驱动（shadow driver）的方法来实现的。当guest运行时，VMGL不断测探GL命令，以保持对一个应用程序整个OpenGL状态的跟踪。恢复VMGL保存的应用程序OpenGL状态的同时，VMGL在host端创建一个新stub。

VMGL保存应用程序管理的所有OpenGL上下文（context），以及当前和这些上下文相关的所有窗口。对每一个上下文，保存一下3类状态：

1.全局上下文状态：包括当前矩阵栈、光源、可视属性等。

2.纹理状态：包括像素数据和参数如边界颜色。

3.显示列表：包括一系列以压缩格式存储在GPU存储器中的OpenGL调用。

实现OpenGL状态恢复的代码是在用户空间(userspace)实现的，这样使OS和VMM保持独立。而且，OpenGL状态独立于它在GPU内存中的形式，与哪个厂生产的GPU无关，唯一的限制是恢复时目标机显卡需提供源机的一个超集，目标机支持的东西要包括源机支持的东西。

接下来是对VMGL的性能评测，证实了VMGL的确是个好东西。

作者从这几个角度，进行了评估：性能、移植性、暂停和恢复、对分辨率敏感程度、对多核的敏感程度、可扩展性。所用的benchmark包括游戏和娱乐，有4个：Quake 3、Enemy、Unreal、Mplayer。测试对象有物理机、用Mesa OpenGL库来软件实现3D加速的guest OS、用VMGL实现的guest OS。而且分别在高分辨率和低分辨率两种情况下进行了对比。

1.性能。用软件实现的3D加速性能要比其他情况差两个数量级，而用VMGL实现的性能最多比物理机差14%，甚至持平。

2.移植性。VMM移植性：Xen 在完全硬件虚拟化情况下的性能最差，Xen在硬件虚拟化时的半虚拟化性能和Xen半虚拟化性能最好，VMware Workstation性能与二者接近。guest Os间的移植性：在FreeBSD、OpenSolaris和Linux下性能都不错，明显比软件实现的图形加速效果好。

3.暂停和恢复。暂停时保存的OpenGL状态文件大小从十几兆到70兆不等。恢复时间从零点几秒到两秒多不等。这都说明暂停和恢复的效果是很好的。

4.对屏幕分辨率的敏感程度。出乎意料的是对于Xen+VMGL，高分辨率比低分辨率更合适。在除Enemy外的3个benchmark中，增高的分辨率并没有明显影响其性能，其性能和物理机和接近。

5.对多核处理器的敏感程度。在双核情况下，网络利用率、CPU利用率、帧率都明显高于单核的情况。显然，VMGL更适合多核。

6.可扩展性（scalability）。随应用程序负载增加，可扩展性下降。

最后介绍了一下相关工作和他们还未完成的工作，并作了总结。

别人的一些解决方案有驱动VM（driver VM），即授权一个VM去直接操作GPU硬件。这样host也扮演驱动VM的角色。这样做的好处是避免不同domain的访问冲突，但同时也会降低安全性，而且能直接访问硬件的VM不能被安全的挂起（suspend）或被迁移到另外一个没有驱动支持的机器上。

另外的一些图形虚拟化集中在性能上，而不是提供VMM或guest Os的独立性。

他们的工作目前集中在VMM和guest Os的可移植性上，所以没有进行以牺牲可移植性性能为代价的性能优化。作者准备通过在更高层面上的并发来实现对某些高要求的应用进行优化，以便使其性能更接近物理机。

目前，VM和OpenGL stub间总的带宽成为性能瓶颈。舍弃网络传输，用共享内存可以缓解该瓶颈。

最后，作者相信把VMGL移植到Windows和Mac Os上是没有障碍的，而且Direct3D API也可以用和OpenGL相似的方法被虚拟化。

[1] H. Andres Lagar-Cavilla, Niraj Tolia, M. Satyanarayanan, Eyal de Lara. ACM Press, Jun. 2007. Proceedings of the 3rd international conference on Virtual execution environments.