Xen 虚拟机架构

　　[Abstract]
　　Xen 是一个基于开源软件组织的虚拟机监控器(即 Virtual Machine Monitor 简称 VMM)，可以允许在单一的物理机器上同时运行多个操作系统实例。

　　虚拟化技术概述

　　虚拟计算机的概念最早由 IBM 公司在上世纪六七十年代提出，并将其运用于 VM/370 系统中以共享昂贵的大型机系统(Main Frame)。之后的发展起起伏伏，一度由于分时操作系统的出现而处于停滞状态。上世纪九十年代随着 JAVA 虚拟机的推出，尤其是之后 Vmware 公司 Vmware ESXserver 和 Vmware workstation 虚拟机的推出，使对虚拟机技术的研究再次成为处理器设计人员、软件设计人员、服务器设计人员和网络安全设计人员的热门研究课题。

　　如图 1 所示，虚拟化技术通过在现有平台(机器)上添加一层薄的虚拟机监控程序(Virtual Machine Monitor，简称 VMM)软件而实现对系统的虚拟化，如虚拟处理器，虚拟内存管理器(MMU)和虚拟 I/O 系统等。虚拟机监控程序又被称之为监管程序(Hypervisor)。从应用程序的角度看，程序运行在虚拟机上同运行在其对应的实体计算机上一样。虚拟机技术使得一台物理计算机可以生成多个不同的虚拟机分别运行多个不同或相同的操作系统。虚拟机技术通过将不同的应用运行在不同的虚拟机上，可以避免不同应用程序之间的互相干扰，例如一个应用的崩溃不会影响到其它的应用等。这种由虚拟机技术实现的各个应用之间的完全隔离在服务器领域具有尤其重要的意义，同时虚拟机技术也可以使得企业、高校或研究所可以在不必购置大量物理计算机的情况下实现大规模的计算机网络以从事生产及研究，例如网络及网络应用研究，操作系统内核(Kernel)软件的开发和用户操作系统的开发等。

　　VMM 抽象的虚拟机的指令集(Instruction Set Architecture 简称 ISA)可以等同于它运行的物理机器，也可以作些微修改。当虚拟的指令集与物理的指令集相同时，该虚拟机可以运行没有任何修改的操作系统；而当两者不完全相同时，客户机的操作系统就必须在源代码级或二进制代码级作相应修改。根据是否需要修改客户机操作系统的源代码，虚拟化技术又可以分为(1)泛虚拟化(Paravirtualization)和(2)完全虚拟化(Full-virtualization)。完全虚拟化由于不需要修改客户机操作系统，因此具有很好的兼容性和同时支持异种操作系统或不同版本操作系统的能力。相反泛虚拟化技术则通常具有比完全虚拟化技术更好的性能。

　　泛虚拟化技术在最早的 IBM VM/370 上就已经使用，但它的使用仅仅是为了支持传统的操作系统，因此被限制在很小的范围。美国华盛顿大学计算机科学与工程系的 Steven D. Gribble 领导的 Denali 项目和英国剑桥大学计算机实验室的 Ian Pratt 和 Keir Fraster 领导的 Xen 项目组实现了 X86/PC 上的泛虚拟化，使泛虚拟化技术重新成为最热门的虚拟化技术之一。随着 Intel® 公司在 2005 年初推出基于处理器硬件的虚拟化技术(Intel® Virtualization Technology 简称 Intel®VT 技术)，支持未经修改的操作系统的完全虚拟化技术同泛虚拟化技术一样成为当今虚拟化领域中的两个主要研究方向。

　　Xen 虚拟机

　　Xen 是一个基于开源(Open Source)代码的系统虚拟机，最初基于 32 位 X86 体系结构而设计开发，支持同时运行多至约 100 个虚拟机。Xen 引入的管理接口(Hypercalls)和事件(Events)机制，以及预先定义的虚拟机和 VMM 之间的共享内存数据交换机制都使得新的客户机体系架构(Xen 虚拟机架构)具有更高的总体性能，但同时也就注定了它必须修改客户机操作系统源代码。

　　Xen 将客户机称之为虚拟域 (Domain)，其中 0 号虚拟域为服务域作为监控程序的扩展提供系统的管理服务。监控程序拥有部分硬件 IO 资源如定时器设备、中断设备PIC/Local APIC/IO APIC 等，其他虚拟域也可以拥有部分的 IO 资源，如硬盘网卡等。拥有物理设备的虚拟域称为隔离设备驱动域(Isolated Driver Domain)或简称设备驱动域(Driver Domain)。普通虚拟域只有虚拟设备而不拥有直接的硬件设备资源访问权。Xen 项目也将 Hypervisor 称为 Xen。

　　Xen 本身主要基于开源的 Linux 内核代码移植而来，同时运行其上的 XenLinux 也从 Linux 移植而来，意为支持 Xen 架构的Linux。同样支持 Xen 架构的 FreeBSD 和Windows XP 也能够在 Xen 上运行。应用程序(X86)均不需任何修改就可以在 Xen(X86) 上运行，如 Linux 应用程序可以在 XenLinux 上运行而 Windows XP 应用程序可以在 XenXP 上运行。

　　Xen 泛虚拟化体系结构

　　Xen 监管程序(hypervisor)运行在最高优先级(Ring 0)上，泛虚拟化的客户域运行在较低的优先级上(Ring1-3 )。Xen/X86 泛虚拟化域的内核运行在优先级 1 上，而应用程序仍然运行在优先级 3 上。Xen 服务虚拟域拥有对整个(或部分)物理系统资源的管理功能，如块设备，显示和输入输出等。

　　Xen 支持泛虚拟化域和完全虚拟化域的同时运行，如图 2 所示。虚拟域0(即服务虚拟域)作为 hypervisor 的扩充，直接拥有系统硬件输入输出设备(IO,DMA等)，也因此必须具有对这些设备响应的原生(Native)驱动程序。虚拟域0提供对整个系统的管理平台，也是一个设备驱动域。虚拟域1是一个设备驱动域拥有部分物理设备，因此也需要 Native 驱动程序以及向其它客户机提供后端设备驱动程序。虚拟域2是一个用户泛虚拟化域，它不具有物理硬件设备，相反通过虚拟设备(即前端设备驱动程序)向位于虚拟域 0 的后端设备驱动程序申请服务而实现对设备的访问。另外，未经修改的操作系统上也可以运行泛虚拟化的前端设备驱动程序以获取更高的性能。

　　事件通道(Event Channel)

　　事件通道是 Xen 用于虚拟域和 VMM 之间、虚拟域和虚拟域之间的一种异步事件通知机制。在 32 位 X86 架构下共有 1024 个事件通道，共分 8 组，每 128 个通道一组。Xen 架构上的物理中断 (pIRQ) 、 虚拟中断(vIRQ)、虚拟处理器间中断(vIPI)和虚拟域间通信(Inter Domain Communication 简称IDC)均通过事件通道实现。向事件通道发送消息会在每一个虚拟域的内部数据结构(evtchn_pending)中置位以便客户机处理。如果目标虚拟处理器正在运行则需要通过物理 IPI 打断当前虚拟机的执行，以及时响应异步事件。

　　Xen 架构上的物理中断等同于原生系统上的中断，使拥有原生设备的 Xen 虚拟域可以最大程度地利用原生操作系统(Linux)的设备驱动程序。事件通道机制使得 hypervisor 在向客户机异步通知时可以一次承载多个异步事件(含物理中断)，从而一次虚拟域与 hypervisor 之间的边界穿越可以使客户机批处理多个中断事件，大大提高了系统的总体性能。

　　泛虚拟域对虚拟中断和物理中断的处理完全一样，在 Linux 中它们都由 do_IRQ 中断服务程序处理。同时将整个系统的中断数目相应增加到 512 个，其中的前 256 个为物理中断使用以保持与原生系统的相似性，后 256 个为虚拟中断使用。

　　Hypervisor 服务(Hypercall)

　　Xen 虚拟域本身并不能直接访问本虚拟域以外的物理资源，包括 hypervisor 本身，但是虚拟域可以通过 hypercalls 向监管程序申请各种服务。Hypercalls 就如同传统操作系统下的系统调用，监管程序通过它向各虚拟域提供各种服务，如 MMU 更新(do_mmu_update)、dom0 操作(do_dom0_op)请求、虚拟处理器状态(do_vcpu_op)等等。在 32 位 X86 架构下 hypercall 通过 int 0x82 陷阱(trap)指令实现，因为传统操作系统本身并不使用 int 0x82(Linux 使用 int 0x80 作为系统调用指令，int 0x82 并未使用)。Hypercall 的具体功能识别号由 eax 表明，而其它参数则在 ebx, ecx, edx, esi 和 edi 中。为了减少虚拟域和 hypervisor 之间的特权级别(ring)切换次数，Xen 提供对 hypercall 的批处理，即将几个 hypercall 功能请求放在一个列表中由专门的 do_multicall_call 请求完成。

　　只有特权级别为1的代码(泛虚拟化域的 kernel)才能向 Xen 发送 Hypercall 请求，以防止应用程序(特权级3)的错误调用导致对系统可能的破坏。因此只有运行在特权级1的虚拟域操作系统内核才能申请hypercall。但是一些 Xen 专用的特别程序如 xend 或 xm 也需要有 hypervisor 的服务来完成特殊的操作如生成一个新的虚拟域等，这在 XenLinux 中是通过一个称为 privcmd 的内核驱动程序实现。应用程序通过 ioctl 向该驱动程序提出服务请求，运行在虚拟域内核(特权级1)的 privcmd 驱动程序再将服务请求以 hypercall 形式转向 hypervisor 并由后者完成。

　　Xen 硬件虚拟机体系结构

　　泛虚拟化技术通过对客户机操作系统的修改，绕开了传统 X86 体系结构的虚拟化漏洞，并以良好的性能赢得了在开源软件操作系统(如 Linux)上的广泛关注，但是无法支持象 Windows 这样的私有操作系统。硬件虚拟化技术在芯片硬件层面上弥补了 X86 体系结构的虚拟化漏洞，使 hypervisor 对未经修改的操作系统的支持成为可能，如 Intel®VT 和 AMD SVM 技术。

　　Intel® VT 技术引入了一种新的处理器操作，称为 VMX(Virtual Machine Extensions)。VMX 操作可以在根状态(root)或非根状态(non-root)下执行，通常虚拟机监控程序(VMM)在根状态下执行而客户机软件则运行在非根状态。VMM 可以通过虚拟机进入(VM entry)使处理器进入 VMX 非根状态，相反通过虚拟机退出(VM exit)可以使控制权回到 VMX 根状态。

　　处理器处于 VMX 根状态时的功能和权限就像没有 VMX 的系统一样，只是引进了一些新的支持 VMX 的指令，而处于非根状态的处理器的行为则受到了限制。某些特定的指令，事件或状态会导致虚拟机退出到 VMM 进行特权资源虚拟化，但客户机软件本身并不知道自己是否运行在虚拟机上。

　　VMX 操作新定义了虚拟机控制结构(Virtual Machine Control Structure)，简称VMCS。Xen 对硬件虚拟处理器的管理通过 VMCS 实现，如图3所示。当虚拟机进入时(处理器控制从 VMX 根状态进入 VMX 非根状态)，处理器状态被保存在 VMCS 中(Host状态)，同时客户机状态从 VMCS 中装入。相反当虚拟机退出时(从 VMX 非根状态进入 VMX 根状态)，处理器状态被保存在VMCS 的中(客户机状态)，而 Host 状态则从 VMCS 中装入。VMM 可以对不同虚拟处理器的 VMCS 分别设置不同虚拟机退出条件，从而实现对不同客户机的不同虚拟化策略。

　　支持硬件虚拟机的 Xen 架构如图4所示，在 64 位 VMM 上的 VMX 虚拟机可以同时支持 32 位客户机和 64 位客户机并存，并且运行在完全的(客户机)特权级别上。运行在硬件虚拟机上的客户机操作系统不需要任何修改，可以支持从开源的 Linux(2.4 版本和 2.6 版本) 到私有的 Windows (WindowsXP, Windows2000) 以及对这些操作系统的安装。有报道指出 FreeBSD 也可以成功在 Xen 硬件虚拟机上运行。

　　内存虚拟化

　　每一个 X86 客户机的内存地址总是从 0 开始的，而位于该地址的物理内存只有一块。因此监控程序必须把客户机从 0 开始的内存地址映像到其他物理内存页，也因此监控程序必须把客户机虚拟地址(guest virtualaddress)到客户机物理地址(guest physicaladdress)的映像(客户机页表)进行重新映像，即建立客户机虚拟地址到机器物理地址(machine physical address 或 physicaladdress)的映像。Xen 泛虚拟化实现采用修改客户机页表的方式实现这一重新映像，硬件虚拟机采用影像页表(shadow page table)方式实现。

　　Xen 泛虚拟化的 hypervisor 和客户机共享同一个地址空间。32 位 X86(非 PAE 模式)架构下的 hypervisor 占有 4G 空间的高 64M地址空间即从 0XFC000000 到 0XFFFFFFFF，这通过重定向泛虚拟化客户机的 GDT 表实现。hypervisor 为每一个虚拟域准备一个内部 GDT 表以容纳客户机 GDT，但同时为 Xen 保留一部分描述符空间用于 1) hypervisor 将自身的代码和数据分别映像到 ring0, 1 和 3；2) 映像每一个 CPU 的 TSS；3) 映像每一个 CPU 的 LDT。因此泛虚拟化的 Xen 客户机只能使用 0 到 4G-64M 的地址空间，这并不会影响 Linux 应用程序的正常执行(应用程序只使用 0-3G 地址空间)。

　　Xen 虚拟域的初始内存大小在该虚拟域启动时确定，各虚拟域以分区(partition)形式共享整个系统的物理内存。XenLinux 实现了气球(ballon)驱动程序(如图 5 所示)来调节各虚拟域之间的物理内存共享。当一个虚拟域 A 需要更多的内存时，它可以通过气球驱动程序向 Hypervisor 提交内存请求，Hypervisor 可以在未分配的内存中或向其它虚拟域 B 通过气球驱动程序回收内存而提供该 A。虚拟域 A 的气球驱动程序在得到 Hypervisor 新提供的内存后向操作系统释放。

　　设备虚拟化

　　除了处理器和内存，计算机的运行离不开外围设备，如硬盘、显示器、键盘鼠标等，同样虚拟机的运行也离不开虚拟平台上的各种各样的设备。这些设备通常可以归纳成 3类：1) 泛虚拟化设备；2) 仿真设备；3) 直接分配设备(Direct Assignment)。泛虚拟化设备是一种存在于特定环境下(Xen)的一种完全虚拟的设备，它需要在客户机操作系统上安装全新的驱动程序以实现对虚拟设备的访问；仿真设备则利用软件方法仿真一个操作系统能够识别的物理设备，通常也是现实世界中已经存在的设备，如 IDE 硬盘。对于仿真设备，客户机操作系统及 BIOS 本身具有对该种设备的驱动程序，因此不需重新开发客户机驱动程序；直接分配设备是指将一个系统上物理存在的设备，排他性地赋予一个虚拟机。如在一个有两块以太网卡的机器上，将其中的一块排他性地赋予一个硬件虚拟机如 VMX 虚拟域。拥有直接分配设备的虚拟域即为隔离设备驱动域，如图 2 中的虚拟域 1。

　　Xen 虚拟设备

　　如图 2 所示，除了虚拟域 0 和隔离驱动域外，Xen 虚拟域 2 本身并不拥有真正的物理设备，而是虚拟设备，如虚拟的控制台(输入输出)，虚拟的块设备甚至虚拟的网络设备。Xenbus 为所有泛虚拟化的设备驱动程序在虚拟域之间的通信提供了一个抽象的总线，Xen 虚拟设备都必须在初始化时向 Xenbus 注册，而将大部分的内部初始化和设置推迟到 Xenbus 探测(probe)时。Xen 常规的块设备驱动程序分成前端驱动程序(Front-end driver)和后端驱动程序(Back-end driver)，如图 2 上的前端设备驱动程序在接到来自操作系统的读写请求时，通过事件通道和共享内存向位于隔离驱动域的后端设备提出服务请求。后端设备在收到服务请求后则通过该虚拟机上的原生设备完成读写请求。典型的 Xenbus 上虚拟设备包括虚拟块设备(VBD)和虚拟网络接口(VNIF)。

　　仿真设备

　　如图 4 所示，在硬件虚拟机中，为实现物理设备的共享，客户机的 I/O 访问(含内存映像 I/O-Memory Mapped IO)必须被 Xen 捕获，由设备模型(Device Model)进行仿真。硬件虚拟化技术提供了对客户机 I/O 操作的捕获支持，而对于内存映像 I/O，则通过页缺失(Page fault)被 Xen 捕获。但是 Xen 监控程序本身并没有驱动程序去直接访问这些设备，因此这些 I/O 访问的仿真最终由 Xen交由虚拟域 0 完成。从客户机操作系统的角度看，仿真设备同真实的物理设备并没有区别。

　　位于 Dom0 的设备模型(Device Model)向硬件虚拟机提供了一个虚拟的 PC 平台(虚拟设备)。每一个硬件虚拟机都可以看到一个完整的虚拟 PC 平台，包括键盘、鼠标、实时时钟、可编程定时器(8254)、可编程中断控制器(8259)、CMOS、软盘、IDE 硬盘、CDROM和 VGA 图形卡等。

　　直接分配设备

　　客户机操作系统对直接分配设备的访问就如同在原生系统上一样。直接分配设备在本质上是一个不参与虚拟化的真实物理设备，客户机对直接分配设备的 I/O 访问直接传送给物理设备，而物理设备产生的中断也直接传递到该虚拟机，同时直接分配设备的 DMA 操作结果也必须可以直接被该虚拟机接受。

　　运行在客户机上的未经修改的操作系统本身并不知道监控程序已经将它的客户机物理地址作了重新映像；另外，DMA 操作只支持小于 4G 的物理内存地址，这在 32 位虚拟机上没有任何问题，但是在 36 位地址的PAE(Physical Address Extensions)模式和 64位机上则是一个大问题；因此未经修改的操作系统并不能够支持直接分配设备。Xen 泛虚拟化域采用修改设备驱动程序的方法，将 DMA 操作的客户机地址转换成物理地址的方法实现物理设备的直接内存存取即 DMA。这在物理内存小于 4G 的系统上总能实现，但是对于物理内存大于 4G 的系统则未必可行，因为驱动程序得到的物理内存地址可能大于4G。Intel® 的设备虚拟化技术提供了基于硬件的解决方案，如图 6 所示，通过引入硬件 DMA 地址重新映像的方法，将客户机物理地址转化成机器物理地址(设备 A 和 B 所用的 DMA 地址是客户机物理地址), 从而实现对设备 DMA 的支持。Xen 硬件虚拟机采用的硬件设备虚拟化技术，通过 VMM 向硬件提供客户机 DMA 物理内存到机器物理地址的映像页表，实现未经修改的操作系统对直接分配设备的访问支持。

　　Xen 跨平台支持

　　Xen 作为一个开源的泛虚拟化解决方案，它的总体框架具有对其他处理器(X86以外)架构的支持。Xen 3.0 已经实现对 Intel® 安腾架构(Itanium)的支持(Xen/IA64)，同时对 IBM Power PC 架构的支持也正在开发中(Xen/PPC)。同 X86 一样，泛虚拟化的 Xen/IA-64 客户机运行在 ring 1-3，通过 Event Channel 和 Hypercalls 同监控程序协同工作。同时 Xen/IA-64 支持虚拟块设备(VBD)和虚拟网络(VNIF)。

　　在完全虚拟化支持方面，安腾架构也如同 X86 架构一样存在虚拟化支持的漏洞。Intel® VT 技术引入了一个新的处理器模式——虚拟机模式，通过 PSR 寄存器中的 VM(Virtual Machine)位实现。当 VM 位为 0 时，处理器工作在 Host 模式，就如同没有硬件虚拟化技术支持一样。当 VM 位为 1 时，处理器工作在虚拟机模式，具有全部的 4 个ring。处于虚拟机模式时，不管处理器是否处于 ring 0 它对特权资源的访问都会产生打断(interruptions)，进而使处理器进入 Host模式。如图 7 所示，VMM 运行在 Host 模式，具有完全的特权级别，处理器被打断后直接进入 VMM，从而实现对特权资源的虚拟化。不同于 X86，安腾架构有一层称之为 PAL(Processor Abstraction Layer) 的处理器抽象层，将不同处理器实现之间的不同特点经过抽象提供一个统一的固件接口(firmwareinterface)。Intel® VT 技术同时实现了 PAL 的虚拟化支持。

　　Xen 最新进展

　　2005 年 12 月 5 日，XenSource 向外发布了 3.0 版本。Xen 3.0 支持 Intel® VT 技术、客户机 SMP 及客户机 CPU 热插拔、动态移植、32 位/64 位和 PAE 客户机支持、安腾架构支持、安全平台、虚拟机的保存和恢复等等。动态移植技术可以使得一个虚拟机在不同的物理机器间移植而不需要关闭机器，同时不中断虚拟机对外的服务。动态移植理论上可以使虚拟机器的服务永不间断，在物理机器寿命到来之前移植到一个新机器上而继续运行。虚拟机的保存和恢复可以为用户提供机器级别的备份，而不需要关心用户程序本身是否有备份功能，实现灾难时候的恢复。

　　预计 2006 年 9 月，XenSourcee 将向外发布他的第一个正式产品 XenEnterprise。XenEnterprise 基于 Xen 3.0.3，在这之前，Redhat 在他的 Fedora Core 4.0 和 Fedora Core 5.0 中已经集成了 Xen，Novell 在他的 SUSE Linux 10.1 和 SLES 10 中也已经集成了 Xen。同时 Redhat 计划在他的下一个企业 Linux 即 RHEL 5.0 中集成 Xen。Xen 今天已经是一个事实上的开源虚拟化解决方案标准。

　　Xen 虚拟机技术的开源特性、它的接近于原生系统的性能、永不停机的动态移植功能、以及同时对泛虚拟化客户机操作系统和未经修改的操作系统的支持，吸引了包括华尔街分析师在内的广泛关注。利用 Xen 进行服务器加固(Server Consolidation)，搭建有虚拟机组成的网络试验和教学系统，利用虚拟机的保存/恢复(Save/Restore)实现服务器灾难恢复(Disaster Recovery)等等，必将进一步提升国内企事业单位的计算机使用和管理水平，节约宝贵的设备购置经费和极大地提高系统的整体环境安全。

　　[Reference]

　　[1] Pratt, Ian; Fraser, Keir; Hand, Steve;Limpach, Christian; Warfield, Andrew;Magenheimer, Dan; Nakajima, Jun; Mallick,Asit; “Xen 3.0 and the Art ofVirtualization,” in Proceedings ofLinux Symposium, Volume Two, 2005.

　　[2] Jeremy Sugerman, GaneshVenkitachalam and Beng-Hong Lim,“Virtualizing I/O Devices on VMwareWorkstations Hosted Virtual MachineMonitor,” Proceedings of the 2001USENIX Annual Technical Conference,Boston, Massachusetts, June 2001.

　　[3] Carl A. Waldspurger, “MemoryResource Management in VMware ESXServer,” Proceedings of the 5th symposiumon Operating systems design andimplementation (OSDI '02), December 2002.

　　[4] A. Whitaker, M. Shaw, and S. Gribble,“Denali: Lightweight virtual machines fordistributed and networked applications,”Proceedings of the USENIX TechnicalConference, Monterey, CA, June 2002.

　　[5] Uhlig, R.; Neiger, G.; Rodgers, D.; Santoni,A.L.; Martins, F.C.M.; Anderson, A.V.; Bennett,S.M.; Kagi, A.; Leung, F.H.; Smith, L.;”IntelVirtualization Technology,” IEEE ComputerVolume 38, Issue 5, pp. 48–56, May 2005.

　　[6] Nakajima, Jun; Mallick, Asit; Pratt, Ian;Frser, Keir, ”X86-64 XenLinux: Architecture, Implementation, and Optimizations,” OttawaLinux Symposium, 2006.

　　[7] 董耀祖，周正伟,，“基于X86体系架构的系统虚拟机技术发展现状与应用”，计算机工程2006年第13期71页。

　　[8] http://www.linuxjournal.com/article/8909