理清虚拟机和虚拟机监视器的类别

　　大家在谈到虚拟机时可能会有不同的看法：编程的朋友肯定对JVM不会陌生，JVM本身就是一种虚拟机；而喜欢系统虚拟软件的朋友则对VMware、Xen和微软这些虚拟化厂家的虚拟化产品有着更实际的理解。大家只知道它们是不同类别的虚拟机，但是它们之间是如何分类的呢？哪种虚拟机与Intel VT和AMD-V的关联性最大呢？

　　两类不同的虚拟机

　　根据笔者的理解，虚拟机可以分为进程虚拟机和系统虚拟机两大类，进程虚拟机支持ABI——用户指令加上系统调用；系统虚拟机则支持完整的ISA——包括用户指令和系统指令。在这个分类方法中，又可以根据客户机和本地机(Host Machine，在虚拟化资料中也常常称其为宿主机)是否使用了相同的ISA进行次级细分。

　　虚拟机大致可分为两大类，并可进一步细分

　　为了简化讲解，我们只考虑和硬件虚拟化关系最为密切的、在相同ISA情况下的系统虚拟机(右图中黑框圈选的地方，因为大部分读者接触不到不同ISA指令集转换的情况)分类情况。前面我们提到的VMware、Xen的虚拟软件产品都属于系统虚拟机类别，而Intel VT和AMD-V等x86硬件辅助虚拟化技术能够提升系统虚拟机的执行性能。

　　三种虚拟机监视器(VMM)

　　大家谈到虚拟化时最常用的一个词就是VMM(也称作Hypervisor，虚拟机监控器，基本上大家可以认为就是前文讲到的那个虚拟化层，抽象层的替代品)，在系统虚拟机中虚拟软件常常被称为VMM，VMM在虚拟机中可以算是最为关键的组件，对于系统虚拟机的分类就是对虚拟机监视器(VMM)的分类。VMM一般有三种类型，分别是独立(Type-1)、宿主(Type-2)和混合(Hybrid)类型。不论是哪一种系统虚拟机模型，只要它能够提供对Intel VT和AMD-V的支持，都可以在一定程度上减少虚拟化软件带来的性能开销(早期的RISC硬件辅助虚拟化除外)。

虚拟软件把一个硬件平台上的ISA翻译成另一个，以构成系统虚拟机。

  Type-1型VMM直接安装在物理机器上，运行在最高特权模式下，而客户机系统则运行在特权较少的模式上。这种虚拟机在很多方面都是很高效的，但明显的缺点是要考虑的方面较多(比如各种驱动程序)，所以设计比较复杂，VMware的ESX server就属于这种类型。

  Type-2型VMM类似于在操作系统上安装的应用程序，VMM可以依赖主机操作系统提供设备驱动和其它底层服务，因此不需要考虑大量的设备驱动问题，VMM体积较小。大家最常用的VMware Workstation和JVM都属于此类型，这种虚拟机的缺点是会损失一些效率，因为当请求操作系统服务时要通过更多的软件层次，来回的次数也更多。

  混合型是Type-1和Type-2的结合体，在这个类型中VMM和主机操作系统处于平行关系，微软的Virtual Server 2005R2以及最近非常受大家关注的Xen就是混合型的典范。

　　小知识：ISA和ABI

　　ISA是Instruction Set Architecture的简写，译为指令集体系结构。在这个结构中有两个部分是和虚拟机密切相关的，一个是用户指令集(User ISA),另一个是系统指令集(Syetem ISA)。

　　用户指令集是应用程序可直接调用的，而系统指令集则是操作系统才能看到的，负责管理硬件资源。ABI是Application Binary Interface的简写，译为应用二进制接口。它包括两个主要组件，一个是用户指令集，另一个则是系统调用接口(System Calls)。

　　x86体系虚拟化遭遇ISA set缺陷

　　Popek和Goldberg在1974年发表的那篇论文中给出了一个真正的VMM必须满足的三个条件：高效性、资源控制和同质性。高效性是指所有的安全指令都可以在本地硬件上直接运行而不需要VMM的干预或仿真，资源控制是指任何客户机软件都不能改变它可用的系统资源分配，同质性是指抛开性能略微下降的因素，虚拟机上执行的任何程序的行为必须和在本地机器上运行一样。这里面我们之所以重点关注高效性，是因为x86指令集系统本身存在问题——有少部分指令不能在以前的虚拟化环节中进行正常VMM陷入，导致指令执行失败，使得这个条件难以满足。要理解其中的问题，我们首先要了解CPU虚拟化的基本原理、特权级别和敏感指令。

VMM通常分为三种类型

　　CPU虚拟化

　　在VMM对硬件资源虚拟化的过程中，CPU虚拟化是非常重要的一个环节。CPU虚拟化是为物理机器上的每一个虚拟机提供一个或者多个虚拟CPU(简称VCPU)，每个VCPU分时复用物理CPU，在任意时刻一个物理CPU只能被一个VCPU使用。VMM要在整个过程中合理分配时间片以及维护所有VCPU的状态(资深一些的读者应该会联想到现代多任务操作系统中TSS工作机理以及超线程技术中涉及到的上下文切换，是不是有似曾相识的感觉呢？)，当进行VCPU切换时，要保存当前VCPU的状态，将被调度的VCPU状态载入物理CPU，可见如何保证VCPU的正确运行和合理调度是CPU虚拟化技术中需要解决的问题。

Type-2型VMM更易使用但是会损失一定效率

　　特权级别

　　大部分的现代计算机体系结构都有两个或两个以上的特权级别，用来分隔内核和应用软件。以x86为例，为了得到更高的保护控制，在x86的保护模式下定义了当前特权级别(Current Previleged Level，简称CPL)，一共有四个特级层次(0 to 3)被定义，我们一般称之为Ring。Ring后面的数字越大特权越小，我们的操作系统一般都运行在Ring0上，而Ring1和2一般用来支持设备驱动，Ring3上面跑的就是应用软件了。而在现在的x86处理器中，64位架构已经非常普遍，64位CPU因为必须支持页表模式，所以只有两个特权级别，我们可以简单理解为Ring0和Ring3(实际上另有明确定义)，这种模型我们常称为0/3模型。

　　系统中有一些关键操作指令只能在最高特权级别上执行，它们一般被称为特权指令，特权指令仅仅在当前的特权级别为零时(CPL=0)才会执行。如果在非特权级别上试图执行特权指令，将生成一个一般保护异常(这通常会生成一个应用程序错误)，而非特权指令则可以在任何一个权限级别执行。

　　敏感指令中的漏网之鱼

　　在虚拟化世界的VMM模型中，我们可以看到所有的客户机操作系统都运行在非特权模式下，即非Ring0级。因为Guest OS已经不处在特权级别，所以存在一部分原本应该在特权级别执行但现在因为层级权限不够必须转交VMM进行处理的指令，这部分指令就叫敏感指令。

x86的敏感指令中明显有一部分漏网之鱼

　　而根据Popek和Goldberg的定义，指令集支持虚拟化的前提是：所有敏感指令都是特权指令。很可惜x86指令集不能满足这个要求，这是它和RISC架构相比的一个不足。

　　在IBM之类的RISC指令集方面，因为敏感指令全部是特权指令，所以敏感指令的执行都可以被VMM捕获，而在x86方面，因为有一部分敏感指令不属于特权指令，变成了非特权指令，而非特权指令在较低的特权级别上是可以直接执行的，也就是说VMM不会处理这些指令。这样就势必会带来问题，试想一个不受虚拟化软件层控制的指令却工作在虚拟化层之上，这是怎样一个情景？x86至少有十几条敏感指令是不会引发异常的非特权指令，在IA-32指令集中，我们称这些非特权级别的敏感指令为临界指令，它们可以分成两类：

　　敏感寄存器指令：它们读取或者修改敏感寄存器和(或者)敏感内存数据区所存放的内容，比如时钟寄存器、中断寄存器。

        1.SGDT、SIDT、SLDT
        2.SMSW
        3.PUSHF、POPF

　　保护系统指令：涉及存储保护系统、内存或者地址定位系统。

        1.LAR、LSL、VERR、VERW
        2.POP
        3.PUSH
        4.CALL、JMP、INT n、RET
        5.STR
        6.MOV

　　临界指令实例讲解

　　我们用一个实际的例子来解释x86指令集的虚拟化漏洞。SMSW指令(取机器状态字的指令)是为了向下兼容老式处理器，这个指令应该由操作系统完成，也就是说需要Ring0才可以，但很可惜它没有被放在特权指令中。在虚拟化环境中，客户机操作系统都工作在非特权层次上(一般为Ring1或者Ring3)，前面我们讲到非特权指令在较低特权级别时可以不被VMM捕获而直接执行。

不同的特权级别满足不同程序运行的需求

　　客户机操作系统在执行这个指令时，直接取到的是真实机器的值(假设取值1为保护模式，0为实模式)，现在的VMM一般都工作在保护模式下，如果客户机操作系统正好运行在实模式下，那么问题就出来了，SMSW取到的值是1，表示系统运行在保护模式下，而不是真正的客户机操作系统的实模式的返回值0，这显然是不正确的。

　　写在最后

　　讲到这里，大家应该对虚拟化和虚拟机的定义以及VMM有了一个整体的认识，也搞明白了x86指令集为什么是不可虚拟化架构，这为我们更好地理解后续要讲解的硬件辅助虚拟化奠定了一定的理论基础。下一次我们就给大家讲解传统CPU虚拟化模型的技术(特权解除和先陷入后模拟)以及软件CPU虚拟化和硬件CPU辅助虚拟化的解决方法，敬请关注！

　　MC特约评论员 林昊翔（虚拟化技术爱好者）

　　虚拟化技术优势日益体现，不仅大幅度降低了IT支出成本、减少能源浪费，而且还极大地增强了系统整体安全性和可靠性。软硬件厂商未来可能携手提高虚拟化产品的自身性能以及提供更丰富的功能。基于主机操作系统的虚拟机产品以及硬件虚拟化技术得到更广泛应用。硬件厂商在操作模式间的转换速度、TLB性能、内存虚拟化和I/O虚拟化等方面加以改进和完善；软件厂商则利用二进制动态翻译及程序行为分析的技术减小性能开销，利用内存和存储的重复删除技术降低资源开销。而分布式文件系统和分布式共享内存等技术的引入将有助于打造一个高可用、高容错的分布式虚拟化软件平台，便于虚拟机的部署和动态迁移。