Paul Barham, Boris Dragovic, Keir Fraser, Steven Hand, Tim Harris, Alex Ho, Rolf Neugebauer, Ian Pratt, Andrew Warfield

剑桥大学计算机实验室
15 JJ Thomson Avenue, Cambridge, UK, CB3 0FD
{firstname.lastname}@cl.cam.ac.uk

底层命题：在缺乏硬件虚拟化支持（如 Intel VT-x 尚未普及）的时代，如何以接近原生的性能同时运行多个隔离的操作系统？

学习价值（妥协的艺术与接口设计）：引入了“半虚拟化（Paravirtualization）”的概念。它没有死磕“完全透明的虚拟化”，而是选择修改 Guest OS 内核来主动适配底层 Hypervisor。你可以学到在面临严苛的性能约束时，如何通过重新定义系统边界（API/ABI）来达成最优解。

摘要

已有大量系统被设计用于通过虚拟化技术来细分现代计算机的充裕资源。其中一些系统需要专用硬件，或无法支持通用操作系统；一些系统以牺牲性能为代价追求 100% 的二进制兼容性；另一些则为了速度而牺牲安全性或功能完整性。少有系统能够提供资源隔离或性能保障；大多数仅提供尽力而为（best-effort）的资源分配方式，存在拒绝服务的风险。

本文提出了 Xen，一种 x86 虚拟机监控器（virtual machine monitor），它允许多个通用操作系统以安全且资源可管理的方式共享传统硬件，同时不牺牲性能或功能完整性。这一目标通过提供一种理想化的虚拟机抽象来实现，Linux、BSD 和 Windows XP 等操作系统只需极少的移植工作即可在其上运行。

我们的设计目标是在一台现代服务器上同时托管多达 100 个虚拟机实例。Xen 所采用的虚拟化方法极为高效：我们能够同时托管 Linux 和 Windows XP 等操作系统，且仅带来可忽略不计的性能开销——与非虚拟化环境相比至多只有百分之几的差距。在一系列微基准测试和系统级测试中，我们的性能显著优于现有的商业及开源解决方案。

分类与主题描述： D.4.1 [操作系统]：进程管理；D.4.2 [操作系统]：存储管理；D.4.8 [操作系统]：性能

一般术语： 设计、度量、性能

关键词： 虚拟机监控器（Virtual Machine Monitors）、Hypervisor、准虚拟化（Paravirtualization）

1. 引言

现代计算机已具备足够强大的性能，能够通过虚拟化技术呈现出多台较小的虚拟机（Virtual Machines, VMs）的假象，每台虚拟机运行一个独立的操作系统实例。这一趋势使人们对虚拟机技术重新产生了浓厚兴趣。本文介绍了 Xen，一种高性能、资源可管理的虚拟机监控器（Virtual Machine Monitor, VMM），它能够支持诸多应用场景，包括服务器整合（server consolidation）[42, 8]、共址托管设施（co-located hosting facilities）[14]、分布式 Web 服务 [43]、安全计算平台 [12, 16] 以及应用迁移（application mobility）[26, 37]。

成功地对一台机器进行分区以支持多个操作系统的并发执行面临着若干挑战。首先，虚拟机之间必须相互隔离：不允许一个虚拟机的执行对另一个虚拟机的性能产生不利影响。当虚拟机分属互不信任的用户时，这一点尤为重要。其次，需要支持多种不同的操作系统，以适应主流应用的异构性需求。第三，虚拟化引入的性能开销应当尽可能小。

Xen 托管通用操作系统，尽管需要对其源代码进行一定程度的修改。本文所描述和评估的原型系统能够支持多个并发运行的 XenoLinux 客户操作系统实例；每个实例导出的应用二进制接口（Application Binary Interface, ABI）与非虚拟化的 Linux 2.4 完全一致。我们将 Windows XP 移植到 Xen 的工作尚未完成，但已能够运行简单的用户空间进程。NetBSD 的移植工作也在进行中。

Xen 使用户能够动态实例化一个操作系统来执行其所需的任意任务。在 XenoServer 项目 [15, 35] 中，我们正在 ISP 内部或互联网交换点等经济战略位置的标准服务器硬件上部署 Xen。我们在启动新虚拟机时执行准入控制（admission control），并期望每个虚拟机以某种方式为其所需的资源付费。我们在其他文献中讨论了这方面的思路与方法 [21]；本文的重点在于 VMM 本身。

在一台共享机器上托管多个应用和服务器有多种构建方式。最简单的方式可能是部署一台或多台运行标准操作系统（如 Linux 或 Windows）的主机，然后允许用户安装文件并启动进程——应用之间的保护由传统的操作系统技术提供。经验表明，由于看似无关的应用之间存在复杂的配置交互，系统管理很快就会成为一项耗时的任务。

更重要的是，这类系统不能充分支持性能隔离；一个进程的调度优先级、内存需求、网络流量和磁盘访问会影响其他进程的性能。在资源充足且用户群体封闭的情况下（如计算网格或实验性的 PlanetLab 平台 [33]），这可能是可以接受的，但在资源被过度分配或用户不合作的情况下则不可接受。

解决这一问题的一种方法是为操作系统追加性能隔离支持。资源容器（resource containers）[3]、Linux/RK [32]、QLinux [40] 和 SILK [4] 在不同程度上展示了这一点。此类方法的一个难点在于确保所有资源使用都被正确地计入相应进程——例如，考虑缓冲区缓存（buffer cache）或页面置换算法导致的应用间复杂交互。这实际上就是操作系统内部的 "QoS 串扰 "（QoS crosstalk）问题 [41]。在较低层次执行多路复用可以缓解这一问题，Exokernel [23] 和 Nemesis [27] 操作系统已证明了这一点。任务间的非预期或不希望出现的交互被最小化。

我们采用同样的基本方法来构建 Xen，它以整个操作系统的粒度对物理资源进行多路复用，并能够在操作系统之间提供性能隔离。与进程级多路复用相比，这还允许各种客户操作系统优雅地共存，而不必强制规定特定的应用二进制接口。这种灵活性是有代价的——运行完整的操作系统比运行一个进程更加重量级，无论是在初始化方面（例如启动或恢复 vs. fork 和 exec），还是在资源消耗方面。

对于我们最多托管 100 个操作系统实例的目标，我们认为这一代价是值得的；它允许单个用户以资源受控的方式运行未修改的二进制程序或二进制程序集合（例如一个 Apache 服务器配合 PostgreSQL 后端）。此外，它提供了极高的灵活性，因为用户可以动态创建其软件所需的精确执行环境。各种服务和应用之间令人困扰的配置交互被避免了（例如，每个 Windows 实例维护自己的注册表）。

本文其余部分的结构如下：第 2 节解释我们的虚拟化方法并概述 Xen 的工作原理。第 3 节描述我们设计和实现的关键方面。第 4 节使用行业标准基准测试来评估运行在 Xen 之上的 XenoLinux 的性能，将其与原生 Linux、VMware Workstation 和 User-mode Linux（UML）进行比较。第 5 节回顾相关工作，最后第 6 节讨论未来工作并作出总结。

2. Xen：方法与概述

在传统的 VMM 中，暴露给虚拟机的虚拟硬件在功能上与底层物理机器完全相同 [38]。尽管完全虚拟化（full virtualization）有允许未修改操作系统直接运行的明显优势，但它也存在诸多缺陷。对于当前流行的 IA-32（即 x86）架构而言，这一点尤为突出。

完全虚拟化从来就不是 x86 架构设计的一部分。某些特权指令必须由 VMM 处理才能实现正确的虚拟化，但以不充分的特权级别执行这些指令时会静默失败而非产生便于捕获的陷阱（trap）[36]。高效地虚拟化 x86 MMU 也很困难。这些问题可以解决，但代价是增加复杂性和降低性能。VMware 的 ESX Server [10] 动态重写托管机器代码的部分内容，在可能需要 VMM 干预的地方插入陷阱。这种翻译应用于整个客户操作系统内核（伴随相应的翻译、执行和缓存开销），因为所有不会产生陷阱的特权指令都必须被捕获和处理。ESX Server 实现了系统结构（如页表）的影子版本（shadow versions），并通过捕获每次更新尝试来维护与虚拟表的一致性——这种方法对于更新密集型操作（如创建新的应用进程）有很高的开销。

抛开 x86 的复杂性不谈，还有其他反对完全虚拟化的理由。特别是，在某些情况下，希望被托管的操作系统既能看到真实资源也能看到虚拟资源：同时提供真实时间和虚拟时间使客户操作系统能够更好地支持时间敏感型任务，正确处理 TCP 超时和 RTT 估算；而暴露真实机器地址则允许客户操作系统通过使用超级页（superpages）[30] 或页着色（page coloring）[24] 来提升性能。

我们通过呈现一种与底层硬件相似但不完全相同的虚拟机抽象来避免完全虚拟化的缺陷——这种方法被称为准虚拟化（paravirtualization）[43]。准虚拟化有望改善性能，尽管它确实需要修改客户操作系统。需要注意的是，我们并不要求修改应用二进制接口（ABI），因此不需要修改客户应用程序。

我们将迄今为止的讨论提炼为一组设计原则：

  1. 支持未修改的应用二进制程序是至关重要的，否则用户将不会迁移到 Xen。因此，我们必须虚拟化现有标准 ABI 所要求的所有架构特性。

  2. 支持完整的多应用操作系统非常重要，因为这允许在单个客户操作系统实例中虚拟化复杂的服务器配置。

  3. 在 x86 等不合作的（uncooperative）机器架构上，准虚拟化对于获得高性能和强资源隔离是必要的。

  4. 即使在合作的机器架构上，完全隐藏资源虚拟化的影响也会在正确性和性能两方面带来风险。

请注意，我们的准虚拟化 x86 抽象与最近的 Denali 项目 [44] 所提出的有很大不同。Denali 被设计用于支持数千个运行网络服务的虚拟机，其中绝大多数是小规模和不常用的。相比之下，Xen 的目标是扩展到大约 100 个运行行业标准应用和服务的虚拟机。鉴于这些非常不同的目标，对比 Denali 的设计选择与我们的原则是有启发性的。

首先，Denali 不以现有 ABI 为目标，因此可以从其虚拟机接口中省略某些架构特性。例如，Denali 不完全支持 x86 分段机制，尽管该机制在 NetBSD、Linux 和 Windows XP 的 ABI 中被导出（且被广泛使用 1）。

其次，Denali 的实现未解决在单个客户操作系统内支持应用多路复用和多地址空间的问题。相反，应用程序被显式地链接到 Ilwaco 客户操作系统的一个实例上，其方式颇类似于 Exokernel [23] 中的 libOS。因此，每个虚拟机实质上托管一个单用户、单应用、无保护的 " 操作系统 "。相比之下，在 Xen 中，单个虚拟机托管一个真正的操作系统，该操作系统本身可以安全地多路复用成千上万个未修改的用户级进程。尽管已开发了一个原型虚拟 MMU 可能会帮助 Denali 在这方面有所改进 [44]，但我们尚未看到任何已发表的技术细节或评估。

第三，在 Denali 架构中，VMM 执行所有到磁盘的页面交换（paging）。这可能与虚拟化层缺乏内存管理支持有关。在 VMM 中进行页面交换有悖于我们的性能隔离目标：恶意虚拟机可以引发抖动（thrashing）行为，不公平地剥夺其他虚拟机的 CPU 时间和磁盘带宽。在 Xen 中，我们期望每个客户操作系统使用其自身保证的内存预留和磁盘分配来执行自己的页面交换（这一思路之前在自分页 [20] 中已被采用）。

最后，Denali 虚拟化了所有机器资源的 " 命名空间 "（namespaces），认为如果一个虚拟机不能命名另一个虚拟机的资源分配，就无法访问它们（例如，虚拟机不了解硬件地址，只知道 Denali 为它们创建的虚拟地址）。相比之下，我们认为 hypervisor 内部安全的访问控制足以确保保护；此外，如前所述，让客户操作系统直接看到物理资源在正确性和性能方面都有充分的理由。

在下一节中，我们描述 Xen 导出的虚拟机抽象，并讨论客户操作系统如何被修改以符合该抽象。请注意，在本文中，我们使用术语 " 客户操作系统 "（guest operating system）来指代 Xen 可以托管的某个操作系统，使用术语 " 域 "（domain）来指代一个运行中的虚拟机，客户操作系统在其中执行；这种区分类似于传统系统中程序与进程的区别。我们将 Xen 本身称为 hypervisor（虚拟机监控器），因为它运行在比其托管的客户操作系统的 supervisor 代码更高的特权级别上。

2.1 虚拟机接口

表 1 概述了准虚拟化的 x86 接口，分为系统的三个主要方面：内存管理、CPU 和设备 I/O。下面我们依次讨论每个机器子系统，并讨论它在我们的准虚拟化架构中是如何呈现的。请注意，尽管我们实现的某些部分（如内存管理）是 x86 特有的，但许多方面（如我们的虚拟 CPU 和 I/O 设备）可以很容易地应用于其他机器架构。此外，x86 代表了与 RISC 风格处理器有显著差异的领域中的最坏情况——例如，高效地虚拟化硬件页表比虚拟化软件管理的 TLB 更加困难。

表 1：准虚拟化的 x86 接口

类别 子项 描述
内存管理 分段（Segmentation） 不能安装具有完全特权的段描述符，且不能与线性地址空间的顶端重叠。
分页（Paging） 客户操作系统对硬件页表有直接的只读访问权，但更新须经批量处理并由 hypervisor 验证。一个域可以被分配不连续的机器页面。
CPU 保护（Protection） 客户操作系统必须在比 Xen 更低的特权级别上运行。
异常（Exceptions） 客户操作系统必须向 Xen 注册一个异常处理程序描述符表。除页面错误外，处理程序保持不变。
系统调用（System Calls） 客户操作系统可以为系统调用安装一个 " 快速 " 处理程序，允许应用程序直接调用其客户操作系统，避免在每次调用时都经过 Xen 间接传递。
中断（Interrupts） 硬件中断被一个轻量级事件系统所替代。
时间（Time） 每个客户操作系统都有一个定时器接口，并同时感知 " 真实 " 时间和 " 虚拟 " 时间。
设备 I/O 网络、磁盘等 虚拟设备既优雅又简单易用。数据使用异步 I/O 环传输。事件机制替代硬件中断用于通知。

2.1.1 内存管理

虚拟化内存无疑是准虚拟化一种架构中最困难的部分，无论是对 hypervisor 中所需的机制而言，还是对移植每个客户操作系统所需的修改而言。如果架构提供软件管理的 TLB，则任务会更容易，因为这种 TLB 可以用简单的方式高效虚拟化 [13]。带标签的 TLB（tagged TLB）是另一个有用的特性，大多数服务器级 RISC 架构都支持它，包括 Alpha、MIPS 和 SPARC。将地址空间标识符标签与每个 TLB 条目关联，允许 hypervisor 和每个客户操作系统高效地共存于各自独立的地址空间中，因为在转移执行时无需刷新整个 TLB。

不幸的是，x86 没有软件管理的 TLB；TLB 缺失由处理器在硬件中自动通过遍历页表结构来处理。因此，为了获得最佳性能，当前地址空间的所有有效页面翻译都应存在于硬件可访问的页表中。此外，由于 TLB 没有标签，地址空间切换通常需要完全刷新 TLB。鉴于这些限制，我们做了两个决定：(i) 客户操作系统负责分配和管理硬件页表，Xen 仅以最少的介入来确保安全性和隔离性；(ii) Xen 存在于每个地址空间顶部的 64MB 区域中，从而避免了进出 hypervisor 时的 TLB 刷新。

每次客户操作系统需要一个新的页表时（可能是因为正在创建一个新进程），它从自己的内存预留中分配并初始化一个页面，然后向 Xen 注册该页面。此时，操作系统必须放弃对页表内存的直接写权限：所有后续更新都必须由 Xen 验证。这以多种方式限制了更新，包括只允许操作系统映射它拥有的页面，以及不允许对页表进行可写映射。客户操作系统可以批量处理更新请求，以分摊进入 hypervisor 的开销。每个地址空间顶部为 Xen 保留的 64MB 区域不可由客户操作系统访问或重新映射。然而，这一地址区域不被任何常见的 x86 ABI 使用，因此这一限制不会破坏应用兼容性。

分段以类似的方式虚拟化，通过验证对硬件段描述符表的更新。对 x86 段描述符的唯一限制是：(i) 它们的特权级别必须低于 Xen，(ii) 它们不得允许访问地址空间中为 Xen 保留的部分。

2.1.2 CPU

虚拟化 CPU 对客户操作系统有若干影响。主要的一点是，在操作系统之下插入一个 hypervisor 违反了操作系统是系统中最高特权实体的通常假设。为了保护 hypervisor 免受操作系统错误行为的影响（以及保护域之间的相互隔离），客户操作系统必须被修改为在较低的特权级别上运行。

许多处理器架构仅提供两个特权级别。在这些情况下，客户操作系统将与应用程序共享较低的特权级别。客户操作系统将通过在与其应用程序不同的地址空间中运行来保护自身，并通过 hypervisor 间接地在应用程序之间传递控制，以设置虚拟特权级别并切换当前地址空间。同样，如果处理器的 TLB 支持地址空间标签，则可以避免昂贵的 TLB 刷新。

在 x86 上可以高效地虚拟化特权级别，因为它在硬件中支持四个不同的特权级别。x86 的特权级别通常被描述为环（rings），编号从零（最高特权）到三（最低特权）。操作系统代码通常在 ring 0 中执行，因为没有其他环可以执行特权指令，而 ring 3 一般用于应用程序代码。据我们所知，自 OS/2 以来，没有任何知名的 x86 操作系统使用过 ring 1 和 ring 2。任何遵循这种常见安排的操作系统都可以通过修改使其在 ring 1 中执行来移植到 Xen。这阻止了客户操作系统直接执行特权指令，同时使其与运行在 ring 3 中的应用程序保持安全隔离。

特权指令通过要求在 Xen 内部验证和执行来实现准虚拟化——这适用于安装新页表或在空闲时让出处理器等操作（而不是尝试执行 hlt 指令）。任何客户操作系统直接执行特权指令的尝试都会被处理器拒绝，要么静默失败，要么产生一个错误（fault），因为只有 Xen 在足够高的特权级别上执行。

异常（包括内存错误和软件陷阱）在 x86 上的虚拟化非常直接。描述每种异常类型处理程序的表被注册到 Xen 进行验证。该表中指定的处理程序通常与真实 x86 硬件的处理程序相同；这是可能的，因为异常栈帧在我们的准虚拟化架构中未被修改。唯一的修改是针对页面错误处理程序的，它通常需要从一个特权处理器寄存器（CR2）中读取导致错误的地址；由于这在 ring 1 中是不可能的，我们将其写入一个扩展的栈帧中 2。当异常发生在 ring 0 之外执行时，Xen 的处理程序在客户操作系统的栈上创建异常栈帧的副本，并将控制返回到相应的已注册处理程序。

通常只有两类异常频繁到足以影响系统性能：系统调用（通常通过软件异常实现）和页面错误。我们通过允许每个客户操作系统注册一个 " 快速 " 异常处理程序来改善系统调用性能，该处理程序可由处理器直接访问而无需经过 ring 0 的间接传递；此处理程序在安装到硬件异常表之前由 Xen 验证。不幸的是，无法对页面错误处理程序应用相同的技术，因为只有在 ring 0 中执行的代码才能从寄存器 CR2 中读取导致错误的地址；因此页面错误必须始终通过 Xen 传递，以便可以将该寄存器值保存以供 ring 1 访问。

安全性通过在异常处理程序注册到 Xen 时进行验证来保证。唯一需要的检查是处理程序的代码段不指定在 ring 0 中执行。由于没有客户操作系统能创建这样的段，只需将指定的段选择器与少数由 Xen 保留的静态值进行比较即可。除此之外，其他处理程序问题在异常传播过程中被修复——例如，如果处理程序的代码段不存在，或者处理程序未被换入内存，则当 Xen 执行返回到处理程序的 iret 指令时将产生相应的错误。Xen 通过检查导致错误的程序计数器值来检测这些 " 双重错误 "（double faults）：如果该地址位于异常虚拟化代码内部，则违规的客户操作系统将被终止。

请注意，这种 " 惰性 "（lazy）检查即使对于直接系统调用处理程序也是安全的：当 CPU 尝试直接跳转到客户操作系统处理程序时将发生访问错误。在这种情况下，导致错误的地址将在 Xen 之外（因为 Xen 永远不会执行客户操作系统的系统调用），因此该错误将以正常方式被虚拟化。如果传播该错误导致进一步的 " 双重错误 "，则如上所述终止该客户操作系统。

2.1.3 设备 I/O

与完全虚拟化环境中通常所做的模拟现有硬件设备不同，Xen 暴露了一组简洁而优雅的设备抽象。这使我们能够设计一种既高效又满足保护和隔离要求的接口。为此，I/O 数据通过 Xen 在每个域之间传输，使用共享内存、异步缓冲区描述符环（buffer-descriptor rings）。这些环提供了一种高性能的通信机制，用于在系统中垂直传递缓冲区信息，同时允许 Xen 高效地执行验证检查（例如，检查缓冲区是否包含在域的内存预留之内）。

类似于硬件中断，Xen 支持一种轻量级的事件传递机制（event-delivery mechanism），用于向域发送异步通知。这些通知通过更新待处理事件类型的位图来实现，并可选地调用由客户操作系统指定的事件处理程序。这些回调可以由客户操作系统自行决定 " 延迟 "——例如，为了避免频繁的唤醒通知带来的额外开销。

2.2 将操作系统移植到 Xen 的代价

表 2 展示了将通用操作系统移植到 Xen 的准虚拟化 x86 环境的代价（以代码行数计）。请注意，我们的 NetBSD 移植处于非常早期的阶段，因此此处未报告其数据。XP 移植更为先进，但仍在进行中；它可以从 RAM 磁盘上执行若干用户空间应用程序，但目前缺乏任何虚拟 I/O 驱动程序。因此，未列出 XP 虚拟设备驱动程序的数据。然而，与 Linux 一样，由于 Xen 所呈现的理想化硬件抽象，我们预计这些驱动程序将是小型且简单的。

表 2：将通用操作系统移植到 Xen 的简易性。代价度量为与原始 x86 代码库（不含设备驱动程序）相比，修改或新增的、格式合理且有适当注释的代码行数。

操作系统子部分 Linux（行数） XP（行数）
架构无关部分 78 1299
虚拟网络驱动程序 484 –
虚拟块设备驱动程序 1070 –
Xen 专用部分（非驱动程序） 1363 3321
总计 2995 4620
（占 x86 代码库总量的百分比） 1.36% 0.04%

Windows XP 需要对其架构无关操作系统代码进行出人意料数量的修改，因为它使用了多种结构体和联合体来访问页表项（PTEs）。每处页表访问都必须单独修改，尽管其中一些过程通过脚本实现了自动化。相比之下，Linux 需要的通用内存系统修改要少得多，因为它使用预处理器宏来访问 PTE——宏定义提供了一个便捷的位置来添加准虚拟化所需的翻译和 hypervisor 调用。

在两个操作系统中，架构特定部分实际上是 x86 代码到我们的准虚拟化架构的移植。这涉及重写使用特权指令的例程，以及删除大量底层系统初始化代码。同样，Windows XP 需要更多的修改，主要是因为存在遗留的 16 位模拟代码以及需要一种稍微不同的引导加载机制。请注意，XP 中 x86 特定代码库比 Linux 中的要大得多，因此应预期更大的移植工作量。

2.3 控制与管理

在 Xen 的设计和实现过程中，一个始终贯穿的目标是尽可能地将策略与机制分离。尽管 hypervisor 必须参与数据路径方面（例如在域之间调度 CPU、在传输前过滤网络数据包、或在读取数据块时执行访问控制），但它无需参与甚至无需了解更高层次的问题，如 CPU 应如何共享，或每个域可以传输何种类型的数据包。

由此产生的架构是：hypervisor 本身仅提供基本的控制操作。这些操作通过一个可被授权域访问的接口导出；诸如准入控制之类的潜在复杂策略决策，最好由运行在客户操作系统之上的管理软件来执行，而非在特权 hypervisor 代码中完成。

系统的整体结构如图 1 所示。请注意，在启动时会创建一个被允许使用控制接口的域。这个初始域称为 Domain 0，负责托管应用级管理软件。控制接口提供了创建和终止其他域的能力，以及控制其相关的调度参数、物理内存分配以及对机器物理磁盘和网络设备的访问权限。

除了处理器和内存资源外，控制接口还支持创建和删除虚拟网络接口（VIFs）和块设备（VBDs）。这些虚拟 I/O 设备具有相关的访问控制信息，用于确定哪些域可以访问它们以及有何限制（例如，可以创建一个只读的 VBD，或者一个 VIF 可以过滤 IP 数据包以防止源地址欺骗）。

这个控制接口，连同当前系统状态的性能分析统计信息，被导出到在 Domain 0 中运行的一套应用级管理软件。这组管理工具允许方便地管理整个服务器：当前的工具可以创建和销毁域、设置网络过滤器和路由规则、以数据包和流的粒度监控每个域的网络活动，以及创建和删除虚拟网络接口和虚拟块设备。我们预期将开发更高级的工具来进一步自动化管理策略的应用。

3. 详细设计

在本节中，我们介绍组成基于 Xen 的服务器的各主要子系统的设计。在每种情况下，我们同时介绍 Xen 和客户操作系统的功能以便清晰阐述。当前对客户操作系统的讨论以 XenoLinux 为重点，因为这是最成熟的移植；尽管如此，我们正在进行的 Windows XP 和 NetBSD 移植工作使我们确信 Xen 是客户操作系统无关的。

3.1 控制转移：Hypercall 与事件

Xen 与上层域之间的控制交互存在两种机制：域到 Xen 的同步调用可以通过 hypercall 完成，而 Xen 到域的通知则通过异步事件机制传递。

Hypercall 接口允许域执行一个同步的软件陷阱（software trap）进入 hypervisor 以执行特权操作，这类似于传统操作系统中系统调用的使用方式。hypercall 的一个使用示例是请求一组页表更新，其中 Xen 验证并应用一个更新列表，在完成后将控制返回给调用域。

Xen 到域的通信通过异步事件机制提供，它替代了设备中断的通常传递机制，并允许对重要事件（如域终止请求）进行轻量级通知。类似于传统的 Unix 信号，事件的数量很少，每个事件用于标记特定类型的发生。例如，事件用于指示新数据已通过网络接收，或虚拟磁盘请求已完成。

待处理事件存储在一个每域的位掩码（bitmask）中，该位掩码在 Xen 调用客户操作系统指定的事件回调处理程序之前由 Xen 更新。回调处理程序负责重置待处理事件集合，并以适当的方式响应通知。域可以通过设置一个 Xen 可读的软件标志来显式地延迟事件处理：这类似于在真实处理器上禁用中断。

3.2 数据传输：I/O 环

Hypervisor 的存在意味着在客户操作系统和 I/O 设备之间存在一个额外的保护域，因此提供一种允许数据以尽可能小的开销在系统中垂直移动的数据传输机制至关重要。

两个主要因素影响了我们 I/O 传输机制的设计：资源管理和事件通知。为了资源可计费性，我们试图最小化当从设备接收到中断时将数据解复用（demultiplex）到特定域所需的工作——管理缓冲区的开销在稍后执行，届时计算可以被计入相应的域。类似地，用于设备 I/O 的内存尽可能由相关域提供，以防止共享缓冲池固有的串扰（crosstalk）；在数据传输期间，I/O 缓冲区通过在 Xen 内固定（pinning）底层页帧来保护。

图 2 展示了我们 I/O 描述符环的结构。环是由域分配但可从 Xen 内部访问的循环描述符队列。描述符不直接包含 I/O 数据；I/O 数据缓冲区由客户操作系统在带外（out-of-band）分配，并由 I/O 描述符间接引用。对每个环的访问基于两对生产者 - 消费者指针：域将请求放置在环上并推进请求生产者指针，Xen 取走这些请求进行处理并推进相关的请求消费者指针。响应以类似方式放回环上，只是 Xen 作为生产者，客户操作系统作为消费者。不要求按顺序处理请求：客户操作系统为每个请求关联一个唯一标识符，该标识符在相应的响应中被复制。这允许 Xen 基于调度或优先级考虑明确地重新排序 I/O 操作。

这种结构足够通用，可以支持多种不同的设备范式。例如，一组 " 请求 " 可以提供用于网络数据包接收的缓冲区；随后的 " 响应 " 则表示数据包已到达这些缓冲区。重新排序在处理磁盘请求时很有用，因为它允许在 Xen 内对请求进行高效调度，而使用带外缓冲区的描述符使实现零拷贝（zero-copy）传输变得容易。

我们将请求或响应的生产与另一方的通知解耦：在请求的情况下，域可以入队多个条目后再调用 hypercall 通知 Xen；在响应的情况下，域可以通过指定一个响应数量阈值来延迟通知事件的传递。这允许每个域在延迟和吞吐量需求之间进行权衡，类似于 ArseNIC 千兆以太网接口 [34] 中的流感知中断调度（flow-aware interrupt dispatch）。

3.3 子系统虚拟化

上述控制和数据传输机制被用于我们对各种子系统的虚拟化。下面，我们讨论 CPU、定时器、内存、网络和磁盘的虚拟化是如何实现的。

3.3.1 CPU 调度

Xen 当前按照借用虚拟时间（Borrowed Virtual Time, BVT）调度算法 [11] 来调度域。我们选择这个特定的算法是因为它既是工作保持的（work-conserving），又具有一种特殊的低延迟唤醒（或调度）机制，当域收到事件时可以快速调度。快速调度对于最小化虚拟化对设计为及时运行的操作系统子系统的影响尤为重要；例如，TCP 依赖于确认的及时传递来正确估算网络往返时间。BVT 通过使用虚拟时间弯曲（virtual-time warping）机制提供低延迟调度，该机制临时违反 " 理想 " 公平共享以偏向最近被唤醒的域。然而，其他调度算法可以在我们的通用调度器抽象之上轻松实现。每域的调度参数可以由 Domain 0 中运行的管理软件调整。

3.3.2 时间与定时器

Xen 为客户操作系统提供了真实时间（real time）、虚拟时间（virtual time）和挂钟时间（wall-clock time）的概念。真实时间以自机器启动以来经过的纳秒数表示，其精度维持在处理器周期计数器的水平，并可与外部时间源（例如通过 NTP）进行频率锁定。域的虚拟时间仅在域执行时推进：这通常被客户操作系统调度器用来确保其时间片在应用进程之间的正确共享。最后，挂钟时间被指定为一个要加到当前真实时间上的偏移量。这允许调整挂钟时间而不影响真实时间的前进。

每个客户操作系统可以编程一对闹钟定时器，一个用于真实时间，另一个用于虚拟时间。客户操作系统应维护内部定时器队列，并使用 Xen 提供的闹钟定时器来触发最早的超时。超时通过 Xen 的事件机制传递。

3.3.3 虚拟地址翻译

与其他子系统一样，Xen 试图以尽可能小的开销来虚拟化内存访问。如第 2.1.1 节所述，x86 架构使用硬件页表这一事实使这一目标变得更加困难。VMware 采取的方法是为每个客户操作系统提供一个对内存管理单元（MMU）不可见的虚拟页表 [10]。然后，hypervisor 负责捕获对虚拟页表的访问，验证更新，并在虚拟页表和 MMU 可见的 " 影子 "（shadow）页表之间来回传播更改。这大大增加了某些客户操作系统操作的开销，例如创建新的虚拟地址空间，并且需要显式传播硬件对 " 已访问 "（accessed）位和 " 脏 "（dirty）位的更新。

尽管完全虚拟化迫使使用影子页表来给出连续物理内存的假象，但 Xen 没有这种约束。事实上，Xen 只需参与页表更新，以防止客户操作系统进行不可接受的更改。因此，我们避免了与使用影子页表相关的开销和额外复杂性——Xen 的方法是将客户操作系统页表直接注册到 MMU，并限制客户操作系统只能以只读方式访问。页表更新通过 hypercall 传递给 Xen；为确保安全，请求在被应用之前会被验证。

为辅助验证，我们为每个机器页帧关联一个类型和引用计数。一个页帧在任何时间点可以具有以下互斥类型之一：页目录（PD）、页表（PT）、本地描述符表（LDT）、全局描述符表（GDT）或可写（RW）。请注意，客户操作系统始终可以创建到其自身页帧的只读映射，无论其当前类型如何。只有当页帧的引用计数为零时，才能安全地重新分配其用途。这一机制用于维护安全所需的不变量；例如，域不能拥有对页表任何部分的可写映射，因为这将要求相关页帧同时具有 PT 和 RW 两种类型。

类型系统还用于跟踪哪些页帧已经被验证可用于页表中。为此，客户操作系统在将页帧分配为页表用途时进行指示——这需要 Xen 对页帧中的每个条目进行一次性验证，之后其类型被固定为 PD 或 PT（视情况而定），直到客户操作系统发出后续的取消固定请求。这在更改页表基址指针时特别有用，因为它免去了在每次上下文切换时验证新页表的需要。请注意，在页帧既被取消固定又其引用计数降至零之前，它不能被重新分配用途——这防止了客户操作系统利用取消固定请求来绕过引用计数机制。

为了最小化所需的 hypercall 数量，客户操作系统可以在本地排队更新，然后用单个 hypercall 应用整个批次——这在创建新地址空间时特别有益。然而，我们必须确保更新被足够早地提交以保证正确性。幸运的是，客户操作系统通常会在首次使用新映射之前执行 TLB 刷新：这确保了任何缓存的翻译被无效化。因此，在 TLB 刷新之前立即提交待处理更新通常足以保证正确性。然而，某些客户操作系统在确定 TLB 中不存在过期条目时会省略刷新。在这种情况下，首次尝试使用新映射可能会导致页面不存在（page-not-present）错误。因此，客户操作系统的错误处理程序必须检查是否有待处理的更新；如果有，则刷新这些更新并重试导致错误的指令。

3.3.4 物理内存

每个域的初始内存分配（即预留）在其创建时指定；内存因此在域之间静态分区，提供强隔离。也可以指定一个最大允许预留量：如果域内的内存压力增大，它可以尝试从 Xen 申请额外的内存页，直至该预留上限。反之，如果域希望节省资源（可能是为了避免产生不必要的费用），它可以通过将内存页释放回 Xen 来减少其内存预留。

XenoLinux 实现了一个气球驱动程序（balloon driver）[42]，通过在 Xen 和 XenoLinux 的页面分配器之间来回传递内存页来调整域的内存使用。尽管我们可以直接修改 Linux 的内存管理例程，但气球驱动程序通过使用现有的操作系统功能进行调整，从而简化了 Linux 的移植工作。然而，准虚拟化可以用来扩展气球驱动程序的能力；例如，客户操作系统中的内存不足处理机制可以被修改为通过从 Xen 请求更多内存来自动缓解内存压力。

大多数操作系统假设内存由最多几个大的连续区段组成。由于 Xen 不保证分配连续的内存区域，客户操作系统通常会为自己创建连续物理内存的假象，即使其底层的硬件内存分配是稀疏的。从物理地址到硬件地址的映射完全是客户操作系统的责任，它可以简单地维护一个以物理页帧号为索引的数组。Xen 通过提供一个所有域可直接读取的共享翻译数组来支持高效的硬件到物理地址映射——Xen 对该数组的更新进行验证，以确保相关操作系统拥有相应的硬件页帧。

请注意，即使客户操作系统在大多数情况下选择忽略硬件地址，在访问其页表（其中必然使用硬件地址）时也必须使用翻译表。硬件地址也可以被暴露给操作系统内存管理系统的有限部分以优化内存访问。例如，客户操作系统可以分配特定的硬件页面以优化物理索引缓存 [24] 中的放置，或者使用超级页（superpages）[30] 映射自然对齐的连续硬件内存部分。

3.3.5 网络

Xen 提供了虚拟防火墙路由器（Virtual Firewall-Router, VFR）的抽象，其中每个域有一个或多个网络接口（VIFs）逻辑地连接到 VFR。VIF 看起来有点像现代网络接口卡：有两个缓冲区描述符的 I/O 环，一个用于发送，一个用于接收。每个方向还有一个关联的规则列表，形式为 <pattern>, <action>——如果模式匹配，则应用相关的动作。

Domain 0 负责插入和删除规则。在典型情况下，将安装规则以防止 IP 源地址欺骗，并确保基于目标 IP 地址和端口的正确解复用。规则也可以与 VFR 上的硬件接口关联。特别是，我们可以安装规则来执行传统的防火墙功能，如阻止对不安全端口的传入连接尝试。

要传输一个数据包，客户操作系统只需将一个缓冲区描述符入队到发送环上。Xen 复制描述符，然后为了安全起见复制数据包头部并执行任何匹配的过滤规则。数据包有效载荷不被复制，因为我们使用分散 - 聚集 DMA（scatter-gather DMA）；但请注意，相关的页帧必须被固定直到传输完成。为确保公平性，Xen 实现了一个简单的轮询（round-robin）数据包调度器。

为了高效实现数据包接收，我们要求客户操作系统为收到的每个数据包交换一个未使用的页帧；这避免了在 Xen 和客户操作系统之间复制数据包的需要，尽管它要求在网络接口上排队页面对齐的接收缓冲区。当数据包到达时，Xen 立即检查接收规则集以确定目标 VIF，并将数据包缓冲区与相关接收环上的一个页帧交换。如果没有可用的页帧，则丢弃该数据包。

3.3.6 磁盘

只有 Domain 0 对物理（IDE 和 SCSI）磁盘拥有直接的未检查访问权限。所有其他域通过虚拟块设备（Virtual Block Devices, VBDs）的抽象来访问持久存储，VBDs 由 Domain 0 内运行的管理软件创建和配置。让 Domain 0 管理 VBDs 使 Xen 内部的机制保持非常简单，避免了诸如 Exokernel [23] 使用的 UDF 等更复杂的解决方案。

一个 VBD 包含一个带有相关所有权和访问控制信息的区段（extents）列表，并通过 I/O 环机制访问。典型的客户操作系统磁盘调度算法会在将请求入队到环上之前对其重新排序，以尝试减少响应时间并应用差异化服务（例如，它可能选择以牺牲推测性预读请求为代价来积极调度同步元数据请求）。然而，由于 Xen 对实际磁盘布局有更完整的了解，我们也支持在 Xen 内部进行重新排序，因此响应可能以不同的顺序返回。因此，VBD 对客户操作系统来说有点像 SCSI 磁盘。

Hypervisor 内部为每个 VBD 维护一个翻译表；该表中的条目由 Domain 0 通过特权控制接口安装和管理。在收到磁盘请求时，Xen 检查 VBD 标识符和偏移量，并产生相应的扇区地址和物理设备。权限检查也在此时执行。使用 DMA 在磁盘和请求域的固定内存页之间进行零拷贝数据传输。

Xen 以简单的轮询方式服务来自竞争域的批量请求；然后将这些请求传递给标准的电梯调度器（elevator scheduler），最后到达磁盘硬件。域可以显式地传递重排序屏障（reorder barriers），以在维护更高级语义（例如使用预写日志时）所必需时防止重排序。低层调度给我们带来了良好的吞吐量，而请求批处理提供了合理公平的访问。未来的工作将研究提供更可预测的隔离和差异化服务，可能利用现有的技术和调度器 [39]。

3.4 构建新域

为新域构建初始客户操作系统结构的任务大部分委托给 Domain 0，它使用其特权控制接口（第 2.3 节）来访问新域的内存并将初始寄存器状态通知 Xen。与完全在 Xen 内部构建域相比，这种方法有许多优势，包括降低 hypervisor 复杂性和提高鲁棒性（通过特权接口的访问经过完整性检查，这使我们在初始开发期间能够捕获许多 bug）。然而，最重要的是构建过程可以轻松扩展和特化以适应新的客户操作系统。例如，Linux 内核假设的启动时地址空间比 Windows XP 预期的要简单得多。可以为所有客户操作系统指定一个固定的初始内存布局，但这将需要在每个客户操作系统中添加额外的引导代码来按操作系统其余部分的要求布置内存。不幸的是，这类代码难以正确实现；为了简便和鲁棒，最好在 Domain 0 中实现，因为它可以提供比引导环境丰富得多的诊断和调试支持。

4. 性能评估

在本节中，我们对 Xen 进行了全面的性能评估。我们首先将 Xen 与若干替代虚拟化技术进行基准比较，然后比较在单个原生操作系统上并发运行多个应用的总系统吞吐量与在各自虚拟机中运行每个应用的情况。接着我们评估 Xen 在客户操作系统之间提供的性能隔离，并评估在同一硬件上运行大量操作系统的总体开销。对于这些测量，我们使用了我们的 XenoLinux 移植版本（基于 Linux 2.4.21），因为这是我们最成熟的客户操作系统。我们预计 Windows XP 和 NetBSD 移植版本的相对开销与之相似，但尚未进行全面评估。

在同一台机器上运行多个 Linux 副本有若干预先存在的解决方案。VMware 提供了若干商业产品来提供虚拟 x86 机器，可在其上启动未修改的 Linux 副本。最常用的版本是 VMware Workstation，它由一组对 " 宿主 " 操作系统的特权内核扩展组成。Windows 和 Linux 宿主均受支持。VMware 还提供了一款名为 ESX Server 的增强产品，它用专用内核替代宿主操作系统。这样做使其相对于工作站产品获得了一些性能优势。ESX Server 还支持一个准虚拟化的网络接口，可以通过在客户操作系统中安装特殊的设备驱动程序（vmxnet）来访问（如果部署环境允许）。

我们已经对 ESX Server 进行了下述基准测试，但遗憾的是由于该产品终端用户许可协议的条款限制，无法报告定量结果。取而代之的是，我们报告 VMware Workstation 3.2 的结果（运行在 Linux 宿主操作系统之上），因为这是最近的没有基准测试发布限制的 VMware 产品。ESX Server 利用其原生架构的优势，在性能上等于或优于 VMware Workstation 及其托管架构。虽然 Xen 当然要求客户操作系统被移植，但它利用准虚拟化的优势明显优于 ESX Server。

我们还报告了 User-mode Linux（UML）的结果，这是一个越来越流行的虚拟托管平台。UML 是 Linux 的一个移植版本，作为 Linux 宿主上的用户空间进程运行。与 XenoLinux 类似，所需的修改仅限于架构相关的代码库。然而，UML 代码与原生 x86 移植版本差异很大，因为执行环境的性质截然不同。虽然 UML 可以运行在未修改的 Linux 宿主上，但我们报告的是 " 单内核地址空间 "（Single Kernel Address Space, skas3）变体的结果，该变体利用宿主操作系统的补丁来改善性能。

我们还调查了其他三种在同一 x86 机器上运行移植版 Linux 的虚拟化技术。Connectix 的 Virtual PC 和即将推出的 Virtual Server 产品（现已被微软收购）在设计上类似于 VMware，提供完全的 x86 虚拟化。由于所有版本的 Virtual PC 在其许可协议中都有基准测试限制，我们没有对其进行深入分析。UMLinux 在概念上类似于 UML，但代码库不同，且尚未达到同等水平的性能，因此我们省略了其结果。改善 UMLinux 性能的宿主操作系统修改工作正在进行中 [25]。虽然 Plex86 最初是一个通用的 x86 VMM，但它现在已被重新定位为仅支持 Linux 客户操作系统。客户操作系统必须经过特殊编译才能在 Plex86 上运行，但与原生 x86 相比源代码更改是微不足道的。Plex86 的性能目前远低于其他技术。

所有实验均在配备双处理器 2.4 GHz Xeon 的 Dell 2650 服务器上执行，该服务器配有 2 GB RAM、一块 Broadcom Tigon 3 千兆以太网网卡和一块 Hitachi DK32EJ 146 GB 10k RPM SCSI 磁盘。全程使用 Linux 2.4.21 版本，在原生和 VMware 客户操作系统实验中编译为 i686 架构，在 Xen 上运行时编译为 xeno-i686 架构，在 UML 上运行时编译为 um 架构。机器中的 Xeon 处理器支持 SMT（" 超线程 "），但由于没有任何内核当前具有 SMT 感知调度器而将其禁用。我们确保所有客户操作系统及其 VMM 可用的内存总量等于原生 Linux 可用的总内存量。全程使用 Red Hat 7.2 发行版，安装在 ext3 文件系统上。虚拟机被配置为以 " 持久原始模式 "（persistent raw mode）使用相同的磁盘分区，这提供了最佳性能。使用相同的文件系统映像也消除了磁盘寻道时间和传输速率的潜在差异。

4.1 相对性能

我们执行了大量实验以评估各种虚拟化技术相对于在 " 裸机 " 上运行的开销。采用了涵盖整个系统的复杂应用级基准测试来表征各种服务器型工作负载下的性能。由于 Xen 和 VMware 产品当前都不支持多处理器客户操作系统（尽管它们本身都支持 SMP），因此这些实验中测试机器配置为单 CPU；我们稍后会考察并发客户操作系统的性能。所报告的结果为七次试验的中位数。

图 3 中的第一组柱状图代表了一个对 VMM 相对容易的场景。SPEC CPU 套件包含一系列长时间运行的计算密集型应用程序，旨在衡量系统的处理器、内存系统和编译器质量的性能。该套件很少执行 I/O，与操作系统的交互也很少。由于几乎所有的 CPU 时间都花费在用户空间代码的执行上，三种 VMM 都表现出低开销。

下一组柱状图显示了在本地 ext3 文件系统上使用 gcc 2.96 构建默认配置的 Linux 2.4.21 内核所花费的总耗时。原生 Linux 将约 7% 的 CPU 时间花费在操作系统中，主要执行文件 I/O、调度和内存管理。在各种 VMM 中，这些 " 系统时间 " 或多或少地被放大：Xen 仅产生 3% 的开销，而其他 VMM 则经历了更为显著的减速。

使用 PostgreSQL 7.1.3 数据库在其默认配置下进行了两个实验，由开源数据库基准测试套件（OSDB）驱动。我们分别报告了多用户信息检索（IR）和联机事务处理（OLTP）工作负载的结果，均以每秒元组数（tuples per second）为度量。为获得正确结果，需要对该套件的测试框架进行小幅修改，原因是 UML 在高负载下丢失虚拟定时器中断的 bug。基准测试通过 PostgreSQL 的原生 API（可调用 SQL）经 Unix 域套接字驱动数据库。PostgreSQL 对操作系统施加了相当大的负载，这反映在 VMware 和 UML 所经历的巨大虚拟化开销中。特别是，OLTP 基准测试需要许多同步磁盘操作，导致大量的保护域转换。

dbench 程序是一个派生自行业标准 "NetBench" 的文件系统基准测试。它模拟 Windows 95 客户端对文件服务器施加的负载。在这里，我们检查单个客户端执行约 90,000 次文件系统操作时所经历的吞吐量。

SPEC WEB99 是一个复杂的应用级基准测试，用于评估 Web 服务器及其托管系统。工作负载是一个复杂的页面请求混合：30% 需要动态内容生成，16% 是 HTTP POST 操作，0.5% 执行 CGI 脚本。在服务器运行过程中会生成访问日志和 POST 日志，因此磁盘工作负载并非仅为只读。因此，测量结果反映了一般的操作系统性能，包括文件系统和网络，以及 Web 服务器本身。

若干客户端机器用于为被测服务器生成负载，每台机器模拟一组同时访问网站的用户。基准测试以不同数量的模拟用户重复运行，以确定能够支持的最大用户数。SPEC WEB99 定义了模拟用户必须接受的最低服务质量（QoS），以确保其为 " 合规 "（conformant）用户并因此计入得分：用户必须在一系列请求中获得超过 320 Kb/s 的聚合带宽。在测量期之前允许一个预热阶段，在此期间同时连接的客户端数量缓慢增加，让服务器预加载其缓冲区缓存。

在我们的实验设置中，我们使用了 Apache HTTP 服务器 1.3.27 版，安装了 mod_specweb99 插件来执行大部分（但非全部）动态内容生成——SPEC 规则要求 0.5% 的请求使用完全的 CGI，fork 一个单独的进程。通过使用 "TUX"（Linux 内核内静态内容 Web 服务器）可以获得更好的绝对性能数字，但我们选择不使用它，因为我们认为它不太可能代表我们的真实世界目标应用。此外，虽然使用 TUX 时 Xen 的性能有所改善，但 VMware 由于在模拟 ring 0 执行客户操作系统内核时花费了更大比例的时间而表现很差。

SPEC WEB99 对整个系统进行了全面测试。在测量期间，存在高达 180 Mb/s 的 TCP 网络流量和对 2 GB 数据集的大量磁盘读写活动。该基准测试是 CPU 密集型的，且大部分时间花费在客户操作系统内核中，执行网络协议栈处理、文件系统操作和 Apache 处理所提供负载所需的众多 httpd 进程之间的调度。XenoLinux 表现良好，达到了原生 Linux 性能的 99% 以内。VMware 和 UML 都表现不佳，支持的客户端数量不到原生 Linux 系统的三分之一。

4.2 操作系统基准测试

为了更精确地测量 Xen 和其他 VMM 中的开销区域，我们使用 McVoy 的 lmbench 程序 [29] 执行了若干小规模实验，针对特定子系统。我们使用了 3.0-a3 版本，因为该版本解决了 Seltzer 的 hbench [6] 提出的关于该工具保真度的许多问题。lmbench 套件的操作系统性能子集由 37 个微基准测试组成。在原生 Linux 情况下，我们分别报告了单处理器（L-UP）和 SMP（L-SMP）内核的数据，因为我们对 SMP 系统中许多情况下额外锁带来的性能开销感到有些惊讶。

在 37 个微基准测试中的 24 个中，XenoLinux 的性能与原生 Linux 相似，紧密跟踪单处理器 Linux 内核的性能并优于 SMP 内核。在表 3 到表 5 中，我们展示了各测试系统之间存在有趣性能差异的结果；Xen 特别大的惩罚以粗体显示。

表 3：lmbench：进程测试——时间单位为微秒（μs）

配置 null call null I/O stat open/close TCP inst hndl sig proc fork proc exec proc sh proc
L-SMP 0.53 0.81 2.10 3.51 23.2 0.83 2.94 143 601
L-UP 0.45 0.50 1.28 1.92 5.70 0.68 2.49 110 530
Xen 0.46 0.50 1.22 1.88 5.69 0.69 1.75 198 768
VMW 0.73 0.83 1.88 2.99 11.1 1.02 4.63 874 2k3
UML 24.7 25.1 36.1 62.8 39.9 26.0 46.0 21k 33k

表 4：lmbench：上下文切换时间——单位为微秒（μs）

配置 2p/0K 2p/16K 2p/64K 8p/16K 8p/64K 16p/16K 16p/64K
L-SMP 1.69 1.88 2.03 2.36 26.8 4.79 38.4
L-UP 0.77 0.91 1.06 1.03 24.3 3.61 37.6
Xen 1.97 2.22 2.67 3.07 28.7 7.08 39.4
VMW 18.1 17.6 21.3 22.4 51.6 41.7 72.2
UML 15.5 14.6 14.4 16.3 36.8 23.6 52.0

表 5：lmbench：文件和虚拟内存系统延迟——单位为微秒（μs）

配置 0K File create 0K File delete 10K File create 10K File delete Mmap lat Prot fault Page fault
L-SMP 44.9 24.2 123 45.2 99.0 1.33 1.88
L-UP 32.1 6.08 66.0 12.5 68.0 1.06 1.42
Xen 32.5 5.86 68.2 13.6 139 1.40 2.73
VMW 35.3 9.3 85.6 21.4 620 7.53 12.4
UML 130 65.7 250 113 1k4 21.8 26.3

在进程微基准测试中（表 3），Xen 显示出比原生 Linux 更慢的 fork、exec 和 sh 性能。这是可以预期的，因为这些操作需要大量的页表更新，而所有更新都必须由 Xen 验证。然而，准虚拟化方法允许 XenoLinux 批量处理更新请求。创建新页表是一个理想的情况：因为没有理由更早提交待处理的更新，XenoLinux 可以将每次 hypercall 分摊到 2048 次更新上（其批处理缓冲区的最大大小）。因此，每次更新 hypercall 构建了 8 MB 的地址空间。

表 4 显示了不同进程数量和不同工作集大小下的上下文切换时间。Xen 产生了 1μs 到 3μs 的额外开销，因为它执行一次 hypercall 来更改页表基址。然而，对于更大的工作集大小（可能更能代表真实应用），上下文切换的结果表明该开销与缓存效应相比是很小的。不寻常的是，VMware Workstation 在这些微基准测试中比 UML 表现更差；然而，这是 ESX Server 的增强能够减少开销的一个领域。

表 5 中的 mmap 延迟和页面错误延迟结果很有趣，因为它们需要每页两次进入 Xen 的转换：一次用于接受硬件错误并将细节传递给客户操作系统，另一次用于代表客户操作系统安装更新的页表项。尽管如此，开销相对适中。

表 3 中的一个小异常是 XenoLinux 的信号处理延迟比原生 Linux 更低。这个基准测试根本不需要任何对 Xen 的调用，0.75μs（30%）的加速可能是由于 XenoLinux 中一个偶然的缓存对齐，因此再次提醒不要过于认真地对待微基准测试。

4.2.1 网络性能

为了评估虚拟化网络的开销，我们在千兆以太网局域网上检查 TCP 性能。在所有实验中，我们使用一台配置相似的运行原生 Linux 的 SMP 机器作为端点之一。这使我们能够独立测量接收和发送性能。使用 ttcp 基准测试来执行这些测量。发送方和接收方应用程序均配置了 128 kB 的套接字缓冲区大小，因为我们发现这为所有测试系统提供了最佳性能。所报告结果为传输 400 MB 数据的 9 次实验的中位数。

表 6：ttcp：带宽（Mb/s）

配置 MTU 1500 TX MTU 1500 RX MTU 500 TX MTU 500 RX
Linux 897 897 602 544
Xen 897 (-0%) 897 (-0%) 516 (-14%) 467 (-14%)
VMW 291 (-68%) 615 (-31%) 101 (-83%) 137 (-75%)
UML 165 (-82%) 203 (-77%) 61.1 (-90%) 91.4 (-83%)

表 6 展示了两组结果，一组使用默认以太网 MTU 1500 字节，另一组使用 500 字节 MTU（该值常被拨号 PPP 客户端使用）。结果表明，XenoLinux 虚拟网络驱动程序采用的页面翻转（page-flipping）技术避免了数据复制的开销，因此实现了非常低的每字节开销。使用 500 字节 MTU 时，每数据包开销占主导地位。发送端防火墙过滤和接收端解复用的额外复杂性对吞吐量产生了不利影响，但仅有 14%。

VMware 为与客户操作系统通信模拟了一个 "pcnet32" 网卡，该网卡提供了相对简洁的基于 DMA 的接口。ESX Server 还支持面向兼容客户操作系统的特殊 "vmxnet" 驱动程序，该驱动程序提供了显著的网络性能改善。

4.3 并发虚拟机

在本节中，我们比较了在各自客户操作系统中运行多个应用与在同一原生操作系统上运行它们的性能。我们的关注重点是 Xen 的结果，但也会在适用时评论其他 VMM 的性能。

图 4 显示了在双 CPU 机器上并行运行 1、2、4、8 和 16 个 SPEC WEB99 基准测试副本的结果。原生 Linux 配置为 SMP 模式；在其上我们以并发进程方式运行多个 Apache 副本。在 Xen 的情况下，每个 SPEC WEB99 实例在其自己的单处理器 Linux 客户操作系统中运行（连同一个 sshd 和其他管理进程）。每个 Web 服务器使用不同的 TCP 端口号，以使各副本能够并行运行。请注意，c 个同时连接所需的 SPEC 数据集大小为 (25 + (c × 0.66)) × 4.88 MB 字节，即约 1000 个连接需要 3.3 GB。这足以彻底测试磁盘和缓冲区缓存子系统。

获得良好的 SPEC WEB99 得分需要高吞吐量和有界延迟：例如，如果客户端请求因延迟的磁盘读取而被滞留，则该连接将被归类为不合规并且不会计入得分。因此，VMM 以及时的方式调度域非常重要。默认情况下，Xen 使用 5 毫秒的时间片。

在单个 Apache 实例的情况下，第二个 CPU 的加入使原生 Linux 将第 4.1 节中报告的得分提升了 28%，达到 662 个合规客户端。然而，最佳聚合吞吐量是在运行两个 Apache 实例时获得的，这表明 Apache 1.3.27 可能存在一些 SMP 可伸缩性问题。

运行单个域时，Xen 因不支持 SMP 客户操作系统而受到制约。然而，Xen 的中断负载均衡器识别出空闲 CPU 并将所有中断处理转移到该 CPU 上，使单 CPU 得分提升了 9%。随着域数量的增加，Xen 的性能提升到与原生情况相差几个百分点以内。

接下来，我们进行了一系列实验，运行多个 PostgreSQL 实例，由 OSDB 套件驱动。在单个 Linux 操作系统上运行多个 PostgreSQL 实例证明是困难的，因为通常只运行一个支持多个数据库的 PostgreSQL 实例。然而，这会阻止不同用户拥有独立的数据库配置。我们不得不使用 chroot 和软件补丁的组合来避免不同 PostgreSQL 实例之间的 SysV IPC 命名空间冲突。相比之下，Xen 允许每个实例在自己的域中启动，从而方便配置。

图 5 显示了运行 1、2、4 和 8 个 OSDB-IR 和 OSDB-OLTP 实例时 Xen 实现的聚合吞吐量。当添加第二个域时，第二个 CPU 的充分利用几乎使总吞吐量翻倍。进一步增加域的数量导致聚合吞吐量有所下降，这可归因于上下文切换和磁盘磁头移动的增加。在单个 Linux 操作系统上运行多个 PostgreSQL 实例的聚合得分比使用 Xen 的等效得分低 25-35%。原因尚未完全明了，但似乎 PostgreSQL 存在 SMP 可伸缩性问题，加上对 Linux 块缓存的利用不佳。

图 5 还展示了 8 个域之间的性能差异化。Xen 的调度器被配置为给每个域分配一个 1 到 8 之间的整数权重。各域的吞吐量得分反映在柱状图的不同条带中。在 IR 基准测试中，权重对吞吐量有精确的影响，每个段的大小与其期望值之差在 4% 以内。然而，在 OLTP 情况下，被赋予更大资源份额的域并没有获得成比例的更高得分：高水平的同步磁盘活动暴露了我们当前磁盘调度算法的一个弱点，导致它们表现不佳。

4.4 性能隔离

为了展示 Xen 提供的性能隔离，我们原本希望在 Xen 和其他基于操作系统的性能隔离技术实现（如资源容器）之间进行一次 " 比拼 "。然而，目前似乎没有基于 Linux 2.4 的可用实现可供下载。QLinux 2.4 尚未发布，其目标是为多媒体应用提供 QoS，而非在服务器环境中提供全面的防御性隔离。Ensim 基于 Linux 的 Private Virtual Server 产品似乎是最完整的实现，据报道涵盖了 CPU、磁盘、网络和物理内存资源的控制 [14]。我们正在与 Ensim 讨论，希望能在日后报告比较评估的结果。

在缺乏并排比较的情况下，我们展示了即使在存在恶意工作负载的情况下，Xen 的性能隔离也按预期工作的结果。我们运行了 4 个配置了相等资源分配的域，其中两个域运行先前已测量的工作负载（PostgreSQL/OSDB-IR 和 SPEC WEB99），另外两个域各运行一对极端反社会的进程。第三个域同时运行一个磁盘带宽消耗者（持续的 dd）和一个文件系统密集型工作负载，目标是在大目录中创建大量小文件。第四个域运行一个 "fork 炸弹 "（forkbomb），同时运行一个虚拟内存密集型应用，该应用尝试分配和访问 3 GB 虚拟内存，在失败时释放所有页面然后重新开始。

我们发现 OSDB-IR 和 SPEC WEB99 的结果仅受到两个运行破坏性进程的域的轻微影响——分别比先前报告的结果低 4% 和 2%。我们将此归因于额外上下文切换和缓存效应的开销。鉴于我们当前相对简单的磁盘调度算法，我们认为这一结果有些幸运，但在此场景下它似乎为基准测试的良好运行提供了充分的隔离，使其免受其他域的页面交换和磁盘密集型活动的影响。VMware Workstation 实现了类似水平的隔离，但绝对性能较低。

我们在原生 Linux 下重复了相同的实验。毫不奇怪，破坏性进程使机器对两个基准测试进程完全不可用，导致几乎所有 CPU 时间都花费在操作系统中。

4.5 可扩展性

在本节中，我们考察 Xen 扩展到其目标 100 个域的能力。我们讨论运行多个客户操作系统实例和关联应用程序的内存需求，并测量它们执行的 CPU 性能开销。

我们评估了以 XenoLinux 启动并运行默认的 RH 7.2 守护进程集以及一个 sshd 和 Apache Web 服务器的域的最小物理内存需求。该域在启动时被给予 64 MB 的预留，限制了其可增长的最大大小。客户操作系统被指示通过将所有可能的页面返回给 Xen 来最小化其内存占用。在未配置交换空间的情况下，域能够将其内存占用减少到 6.2 MB；允许使用交换设备后进一步减少到 4.2 MB。一个静默的域能够保持在此缩减状态，直到传入的 HTTP 请求或周期性服务导致需要更多内存。在这种情况下，客户操作系统将从 Xen 请求页面返回，根据需要增长其占用直至其配置的上限。

这表明，在现代服务器级机器上运行 100 个域时，内存使用开销不太可能成为问题——通常会有远多于操作系统或应用程序文本页的内存被用于应用数据和缓冲区缓存。Xen 本身每个域仅维护固定的 20 kB 状态，不像其他 VMM 需要维护影子页表等。

最后，我们考察了在大量域之间而非仅在进程之间进行上下文切换的开销。图 6 显示了在双 CPU 服务器上，在 1 到 128 个域或进程之间并发运行 SPEC CINT2000 套件的一个小子集时获得的归一化聚合吞吐量。代表原生 Linux 的线几乎是平的，表明对于此基准测试，在如此多进程之间调度时聚合性能没有损失；Linux 将它们全部识别为计算密集型，并以 50 毫秒或更长的时间片进行调度。相比之下，较低的线表示 Xen 在配置为默认 5 毫秒最大调度 " 时间片 " 时的吞吐量。尽管在单个服务器上同时运行 128 个计算密集型进程不太可能在我们的目标应用领域中常见，但 Xen 应对得相当好：运行 128 个域时，相对于 Linux 我们仅损失 7.5% 的总吞吐量。

在此极端负载下，我们测量了对运行 SPEC CINT2000 子集的某个域的用户到用户 UDP 延迟。我们测得平均响应时间为 147 毫秒（标准差 97 毫秒）。对一个在其他方面处于空闲状态的第 129 个域重复该实验，我们记录到平均响应时间为 5.4 毫秒（标准差 16 毫秒）。这些数字非常令人鼓舞——尽管存在大量后台负载，交互式域仍然保持响应。

为了确定 7.5% 性能下降的原因，我们将 Xen 的调度 " 时间片 " 设置为 50 毫秒（ESX Server 使用的默认值）。结果是吞吐量曲线紧密跟踪原生 Linux，几乎消除了性能差距。然而，正如可以预期的，高负载下的交互式性能被这些设置不利地影响。

5. 相关工作

虚拟化技术应用于操作系统已有近三十年的历史，涵盖商业和研究领域。IBM VM/370 [19, 38] 首先利用虚拟化技术为遗留代码提供二进制支持。VMware [10] 和 Connectix [8] 都虚拟化了通用 PC 硬件，允许多个操作系统在单一宿主上运行。所有这些例子都实现了底层硬件（至少一个子集）的完全虚拟化，而非准虚拟化并向客户操作系统呈现修改后的接口。如我们的评估所示，完全虚拟化的决策虽然能更容易地支持现成操作系统，但对性能有不利后果。

虚拟机监控器方法也被 Disco 用于允许通用操作系统在 ccNUMA 机器上高效运行 [7, 18]。为了在 MIPS 架构上实现虚拟化执行，需要对托管操作系统进行少量修改。此外，还为了性能原因进行了某些其他修改。

目前，我们知道另外两个采用准虚拟化方法的系统：IBM 当前为其 zSeries 大型机支持准虚拟化版本的 Linux，允许大量 Linux 实例同时运行。Denali [44]（前文已讨论）是一个当代的隔离内核，试图提供能够托管大量虚拟化操作系统实例的系统。

除了 Denali 之外，我们还知道另外两个使用底层虚拟化来构建分布式系统基础设施的努力。vMatrix [1] 项目基于 VMware，旨在构建一个在不同机器之间迁移代码的平台。由于 vMatrix 是在 VMware 之上开发的，他们更关注分布方面的更高层次问题，而非虚拟化本身的问题。此外，IBM 提供了 " 托管主机 "（Managed Hosting）服务，其中可以在 IBM 大型机上租用虚拟 Linux 实例。

PlanetLab [33] 项目构建了一个分布式基础设施，旨在作为地理分布式网络服务的研究和开发测试平台。该平台面向研究人员，试图将单个物理主机划分为切片（slivers），为用户提供同时的底层访问。当前部署使用 VServers [17] 和 SILK [4] 来管理操作系统内的共享。

我们与操作系统可扩展性和主动网络（active networks）社区有一些共同的动机。然而，在 Xen 上运行时，无需检查 " 安全 " 代码或保证终止——在任一情况下唯一受害的人是有问题的客户本身。因此，Xen 提供了一种更通用的解决方案：托管代码无需由受信任的编译器进行数字签名（如 SPIN [5] 中的做法），无需附带安全证明（如 PCC [31] 中的做法），无需用特定语言编写（如 SafetyNet [22] 或任何基于 Java 的系统），也无需依赖特定的中间件（如移动代理系统）。这些其他技术当然可以继续在运行于 Xen 之上的客户操作系统中使用。对于具有更瞬态任务的工作负载，这可能特别有用，因为这些任务无法分摊启动新域的成本。

类似的论点也适用于语言级虚拟机方法：虽然资源管理的 JVM [9] 当然应该能够托管不可信的应用程序，但这些应用程序必须编译为 Java 字节码并遵循该特定系统的安全模型。同时，Xen 可以轻松地将语言级虚拟机作为运行在客户操作系统之上的应用程序来支持。

6. 讨论与结论

我们已经介绍了 Xen hypervisor，它在运行客户操作系统的域之间分配计算机的资源。我们的准虚拟化设计特别强调性能和资源管理。我们还描述和评估了 XenoLinux，一个运行在 Xen 之上的功能完整的 Linux 2.4 内核移植版。

6.1 未来工作

我们相信 Xen 和 XenoLinux 已经足够完善，可以为更广泛的受众所使用，因此打算在不久的将来公开发布我们的软件。一个测试版已经在被选定的参与方评估中；一旦这个阶段完成，将在我们的项目页面 3 上宣布通用的 1.0 版本发布。

在初始发布之后，我们计划对 Xen 进行若干扩展和改进。为了提高虚拟块设备的效率，我们打算实现一个按块内容索引的共享通用缓冲区缓存。这将在不牺牲隔离的情况下为我们的设计添加受控的数据共享。为虚拟块设备添加写时复制（copy-on-write）语义将允许它们在域之间安全共享，同时仍允许文件系统的分叉发展。

为了提供更好的物理内存性能，我们计划实现一个末次机会页面缓存（last-chance page cache, LPC）——实际上是一个系统范围的空闲页面列表，仅当机器内存被不充分分配时其长度才非零。当客户操作系统虚拟内存系统选择驱逐一个干净页面时使用 LPC；与其完全丢弃该页面，不如将其添加到空闲列表的尾部。如果在该页面被 Xen 重新分配之前发生了对该页面的错误，则可以在不进行磁盘访问的情况下满足该错误。

Xen 的一个重要角色是作为 XenoServer 项目的基础，该项目着眼于单个机器之外，正在构建支持互联网规模计算基础设施所需的控制系统。我们设计的关键思想是资源使用被精确计量，并由该任务的赞助者支付费用——如果以真实货币支付，我们可以使用拥塞定价（congestion pricing）策略 [28] 来处理超额需求，并使用超额收入来购买额外的机器。这需要具有更大弹性的精确且及时的 I/O 调度来应对恶意工作负载。我们还计划通过为虚拟块设备创建租约（leases）来将计费纳入我们的块存储架构。

为了更好地支持 XenoServer 的管理和运维，我们正在融入更全面的审计和取证日志记录支持。我们还在开发额外的 VFR 规则，希望能让我们检测和防止各种反社会的网络行为。最后，我们正在继续 XenoXP 的开发工作，首先集中在编写网络和块设备驱动程序上，目标是完全支持企业服务器（如 IIS）。

6.2 结论

Xen 为部署各种以网络为中心的服务提供了出色的平台，如本地镜像动态 Web 内容、媒体流转码与分发、多人游戏和虚拟现实服务器，以及为瞬态连接设备提供更持久网络存在的 " 智能代理 "[2]。

Xen 直接解决了此类服务部署的最大单一障碍：当前无法以短时间和低实例化成本托管瞬态服务器。通过允许 100 个操作系统在单个服务器上运行，我们将相关成本降低了两个数量级。此外，通过将每个操作系统的设置和配置转化为软件层面的事务，我们促成了更小粒度时间尺度的托管。

如我们在第 4 节的实验结果所示，XenoLinux 在 Xen 上的性能实际上等同于基准 Linux 系统的性能。这一事实来源于两个组件之间接口的精心设计，意味着拥有资源管理设施并不会带来可感知的成本。我们正在进行的将 BSD 和 Windows XP 内核移植到 Xen 之上的工作正在确认 Xen 所暴露接口的通用性。

致谢

本工作得到 EPSRC 资助（Grant GR/S01894/01）和 Microsoft 的支持。我们感谢 Evangelos Kotsovinos、Anil Madhavapeddy、Russ Ross 和 James Scott 的贡献。

参考文献

[1] A. Awadalla and M. Rosenblum. The vMatrix: A network of virtual machine monitors for dynamic content distribution. In Proceedings of the 7th International Workshop on Web Content Caching and Distribution (WCW 2002), Aug. 2002.

[2] A. Bakre and B. R. Badrinath. I-TCP: indirect TCP for mobile hosts. In Proceedings of the 15th International Conference on Distributed Computing Systems (ICDCS 1995), pages 136–143, June 1995.

[3] G. Banga, P. Druschel, and J. C. Mogul. Resource containers: A new facility for resource management in server systems. In Proceedings of the 3rd Symposium on Operating Systems Design and Implementation (OSDI 1999), pages 45–58, Feb. 1999.

[4] A. Bavier, T. Voigt, M. Wawrzoniak, L. Peterson, and P. Gunningberg. SILK: Scout paths in the Linux kernel. Technical Report 2002-009, Uppsala University, Department of Information Technology, Feb. 2002.

[5] B. N. Bershad, S. Savage, P. Pardyak, E. G. Sirer, M. Fiuczynski, D. Becker, S. Eggers, and C. Chambers. Extensibility, safety and performance in the SPIN operating system. In Proceedings of the 15th ACM SIGOPS Symposium on Operating Systems Principles, volume 29(5) of ACM Operating Systems Review, pages 267–284, Dec. 1995.

[6] A. Brown and M. Seltzer. Operating System Benchmarking in the Wake of Lmbench: A Case Study of the Performance of NetBSD on the Intel x86 Architecture. In Proceedings of the 1997 ACM SIGMETRICS Conference on Measurement and Modeling of Computer Systems, June 1997.

[7] E. Bugnion, S. Devine, K. Govil, and M. Rosenblum. Disco: Running commodity operating systems on scalable multiprocessors. In Proceedings of the 16th ACM SIGOPS Symposium on Operating Systems Principles, volume 31(5) of ACM Operating Systems Review, pages 143–156, Oct. 1997.

[8] Connectix. Product Overview: Connectix Virtual Server, 2003. http://www.connectix.com/products/vs.html.

[9] G. Czajkowski and L. Daynes. Multitasking without compromise: a virtual machine evolution. ACM SIGPLAN Notices, 36(11):125–138, Nov. 2001. Proceedings of the 2001 ACM SIGPLAN Conference on Object Oriented Programming, Systems, Languages and Applications (OOPSLA 2001).

[10] S. Devine, E. Bugnion, and M. Rosenblum. Virtualization system including a virtual machine monitor for a computer with a segmented architecture. US Patent, 6397242, Oct. 1998.

[11] K. J. Duda and D. R. Cheriton. Borrowed-Virtual-Time (BVT) scheduling: supporting latency-sensitive threads in a general-purpose scheduler. In Proceedings of the 17th ACM SIGOPS Symposium on Operating Systems Principles, volume 33(5) of ACM Operating Systems Review, pages 261–276, Kiawah Island Resort, SC, USA, Dec. 1999.

[12] G. W. Dunlap, S. T. King, S. Cinar, M. Basrai, and P. M. Chen. ReVirt: Enabling Intrusion Analysis through Virtual-Machine Logging and Replay. In Proceedings of the 5th Symposium on Operating Systems Design and Implementation (OSDI 2002), ACM Operating Systems Review, Winter 2002 Special Issue, pages 211–224, Boston, MA, USA, Dec. 2002.

[13] D. Engler, S. K. Gupta, and F. Kaashoek. AVM: Application-level virtual memory. In Proceedings of the 5th Workshop on Hot Topics in Operating Systems, pages 72–77, May 1995.

[14] Ensim. Ensim Virtual Private Servers, 2003. http://www.ensim.com/products/materials/datasheet_vps_051003.pdf.

[15] K. A. Fraser, S. M. Hand, T. L. Harris, I. M. Leslie, and I. A. Pratt. The Xenoserver computing infrastructure. Technical Report UCAM-CL-TR-552, University of Cambridge, Computer Laboratory, Jan. 2003.

[16] T. Garfinkel, M. Rosenblum, and D. Boneh. Flexible OS Support and Applications for Trusted Computing. In Proceedings of the 9th Workshop on Hot Topics in Operating Systems, Kauai, Hawaii, May 2003.

[17] J. Gelinas. Virtual Private Servers and Security Contexts, 2003. http://www.solucorp.qc.ca/miscprj/s_context.hc.

[18] K. Govil, D. Teodosiu, Y. Huang, and M. Rosenblum. Cellular Disco: Resource management using virtual clusters on shared-memory multiprocessors. In Proceedings of the 17th ACM SIGOPS Symposium on Operating Systems Principles, volume 33(5) of ACM Operating Systems Review, pages 154–169, Dec. 1999.

[19] P. H. Gum. System/370 extended architecture: facilities for virtual machines. IBM Journal of Research and Development, 27(6):530–544, Nov. 1983.

[20] S. Hand. Self-paging in the Nemesis operating system. In Proceedings of the 3rd Symposium on Operating Systems Design and Implementation (OSDI 1999), pages 73–86, Oct. 1999.

[21] S. Hand, T. L. Harris, E. Kotsovinos, and I. Pratt. Controlling the XenoServer Open Platform, April 2003.

[22] A. Jeffrey and I. Wakeman. A Survey of Semantic Techniques for Active Networks, Nov. 1997. http://www.cogs.susx.ac.uk/projects/safetynet/.

[23] M. F. Kaashoek, D. R. Engler, G. R. Granger, H. M. Briceño, R. Hunt, D. Mazières, T. Pinckney, R. Grimm, J. Jannotti, and K. Mackenzie. Application performance and flexibility on Exokernel systems. In Proceedings of the 16th ACM SIGOPS Symposium on Operating Systems Principles, volume 31(5) of ACM Operating Systems Review, pages 52–65, Oct. 1997.

[24] R. Kessler and M. Hill. Page placement algorithms for large real-indexed caches. ACM Transactions on Computer Systems, 10(4):338–359, Nov. 1992.

[25] S. T. King, G. W. Dunlap, and P. M. Chen. Operating System Support for Virtual Machines. In Proceedings of the 2003 Annual USENIX Technical Conference, Jun 2003.

[26] M. Kozuch and M. Satyanarayanan. Internet Suspend/Resume. In Proceedings of the 4th IEEE Workshop on Mobile Computing Systems and Applications, Calicoon, NY, Jun 2002.

[27] I. M. Leslie, D. McAuley, R. Black, T. Roscoe, P. Barham, D. Evers, R. Fairbairns, and E. Hyden. The design and implementation of an operating system to support distributed multimedia applications. IEEE Journal on Selected Areas in Communications, 14(7):1280–1297, Sept. 1996.

[28] J. MacKie-Mason and H. Varian. Pricing congestible network resources. IEEE Journal on Selected Areas in Communications, 13(7):1141–1149, Sept. 1995.

[29] L. McVoy and C. Staelin. lmbench: Portable tools for performance analysis. In Proceedings of the USENIX Annual Technical Conference, pages 279–294, Berkeley, Jan. 1996. Usenix Association.

[30] J. Navarro, S. Iyer, P. Druschel, and A. Cox. Practical, transparent operating system support for superpages. In Proceedings of the 5th Symposium on Operating Systems Design and Implementation (OSDI 2002), ACM Operating Systems Review, Winter 2002 Special Issue, pages 89–104, Boston, MA, USA, Dec. 2002.

[31] G. C. Necula. Proof-carrying code. In Conference Record of POPL 1997: The 24th ACM SIGPLAN-SIGACT Symposium on Principles of Programming Languages, pages 106–119, Jan. 1997.

[32] S. Oikawa and R. Rajkumar. Portable RK: A portable resource kernel for guaranteed and enforced timing behavior. In Proceedings of the IEEE Real Time Technology and Applications Symposium, pages 111–120, June 1999.

[33] L. Peterson, D. Culler, T. Anderson, and T. Roscoe. A blueprint for introducing disruptive technology into the internet. In Proceedings of the 1st Workshop on Hot Topics in Networks (HotNets-I), Princeton, NJ, USA, Oct. 2002.

[34] I. Pratt and K. Fraser. Arsenic: A user-accessible gigabit ethernet interface. In Proceedings of the Twentieth Annual Joint Conference of the IEEE Computer and Communications Societies (INFOCOM-01), pages 67–76, Los Alamitos, CA, USA, Apr. 22–26 2001. IEEE Computer Society.

[35] D. Reed, I. Pratt, P. Menage, S. Early, and N. Stratford. Xenoservers: accounted execution of untrusted code. In Proceedings of the 7th Workshop on Hot Topics in Operating Systems, 1999.

[36] J. S. Robin and C. E. Irvine. Analysis of the Intel Pentium's ability to support a secure virtual machine monitor. In Proceedings of the 9th USENIX Security Symposium, Denver, CO, USA, pages 129–144, Aug. 2000.

[37] C. P. Sapuntzakis, R. Chandra, B. Pfaff, J. Chow, M. S. Lam, and M. Rosenblum. Optimizing the Migration of Virtual Computers. In Proceedings of the 5th Symposium on Operating Systems Design and Implementation (OSDI 2002), ACM Operating Systems Review, Winter 2002 Special Issue, pages 377–390, Boston, MA, USA, Dec. 2002.

[38] L. Seawright and R. MacKinnon. VM/370 – a study of multiplicity and usefulness. IBM Systems Journal, pages 4–17, 1979.

[39] P. Shenoy and H. Vin. Cello: A Disk Scheduling Framework for Next-generation Operating Systems. In Proceedings of ACM SIGMETRICS'98, the International Conference on Measurement and Modeling of Computer Systems, pages 44–55, June 1998.

[40] V. Sundaram, A. Chandra, P. Goyal, P. Shenoy, J. Sahni, and H. M. Vin. Application Performance in the QLinux Multimedia Operating System. In Proceedings of the 8th ACM Conference on Multimedia, Nov. 2000.

[41] D. Tennenhouse. Layered Multiplexing Considered Harmful. In Rudin and Williamson, editors, Protocols for High-Speed Networks, pages 143–148. North Holland, 1989.

[42] C. A. Waldspurger. Memory resource management in VMware ESX server. In Proceedings of the 5th Symposium on Operating Systems Design and Implementation (OSDI 2002), ACM Operating Systems Review, Winter 2002 Special Issue, pages 181–194, Boston, MA, USA, Dec. 2002.

[43] A. Whitaker, M. Shaw, and S. D. Gribble. Denali: Lightweight Virtual Machines for Distributed and Networked Applications. Technical Report 02-02-01, University of Washington, 2002.

[44] A. Whitaker, M. Shaw, and S. D. Gribble. Scale and performance in the Denali isolation kernel. In Proceedings of the 5th Symposium on Operating Systems Design and Implementation (OSDI 2002), ACM Operating Systems Review, Winter 2002 Special Issue, pages 195–210, Boston, MA, USA, Dec. 2002.

Footnotes

  1. 例如，线程库经常使用段来寻址线程本地数据。 ↩

  2. 事后来看，将值写入一个预先约定的共享内存位置而非修改栈帧会简化 XP 的移植工作。 ↩

  3. http://www.cl.cam.ac.uk/netos/xen ↩