Xen和虚拟化技术学习指南 （3）

这个移植过程只需要做一些改动使操作系统改为运行在ring 1特权级上。这就防止了guest OS会直接执行特权指令，也保证了操作系统与运行在ring 3上的应用程序之间相隔离的安全性。

特权指令需要被Xen确认和执行以达到准虚拟化的目的，这主要应用于诸如安置新的页表，或者在处理器idle时放弃之（而不是去hlt它）等操作。因为只有Xen有足够高的特权级来执行这些指令，所以任何guest OS试图直接运行特权指令都会失败，后果要么是“沉默”要么是产生错误。

异常，包括内存错误和软件陷阱，都可以在x86架构的基础上直接进行虚拟化。有一个表，内容为对每类异常进行描述的句柄。表中所列的异常都是在Xen中有记录的，以用作确认。表中给出的句柄都是与真正的x86硬件中相同的；之所以这一点是可能做到的，主要是因为在我们的准虚拟化架构中，异常堆栈框架是没有被修改的。唯一的一个改动是在页面错误句柄上。因为该句柄的操作需要从特权处理器寄存器（CR2）中读出出错的地址；但是这是不可能的（//因为特权级别不够了），我们就将它（//页面错误句柄？CR2的值？）写入扩展的堆栈框架中（后来发现，在移植XP的时候，将这个值写入一个预先商定的共享存储位置上要比修改堆栈框架简单一些）。当系统在ring 0以外执行时有异常发生，Xen的句柄就会在guest OS堆栈中创建一个异常堆栈框架的拷贝，并且会将控制交给相应的已经记录过的异常句柄。

典型的，只有两类异常会经常发生而影响到系统的性能：系统调用（一般都是通过软件异常实现）和页面错误。我们让每个guest OS都记录一个“快速的”异常操作句柄来改进系统调用的性能。这个异常操作句柄可以直接由处理器使用，而不必非要间接地经过ring 0；这个句柄在放置进硬件异常列表中之前就是经过确认的（//所以不必经过Xen）。不幸的是，我们不可能使用同样的技术来处理页面错误句柄，因为只有那些运行在ring 0的代码才能够从寄存器CR2中读出错误的地址；因此，页面错误必须要经过Xen才能提交，Xen保存该寄存器的值供来自ring 1的访问使用。

当Xen发现异常产生时，它会对异常句柄进行确认以确保安全性。这只需要检查句柄的代码段中是否含有指明要在ring 0中执行的操作。既然没有guest OS能够创建这样一个段，那么只需要将专门的段选择符和少量的保留在Xen中的静态值作比较即可。除了这点以外，任何其它的句柄问题都会在异常传播（exception propagation）（//一个异常导致了另一个异常的产生）的过程中被修正。例如，如果句柄缺少相应代码段或者句柄没有分配到内存页，那么在Xen为将控制返回给句柄而执行iret指令的时候就会有一个相应的错误产生。Xen通过检查出错的程序计数器值来检测这些“双错误（//double faults：之前已经出错了，现在到了iret已经是第二个错误了；第二个错误是由第一个错误传播而来）”：如果地址是处于异常虚拟化的代码中（//说明异常处理没有完成，iret没成功），那么guest OS就要被终止。

对于直接的系统调用句柄来说，这种“懒惰（//第一个错误发生的时候，没有被检查到；直到Xen执行了iret之后才报错）”的检查也是安全的：当CPU试图直接跳至guest OS句柄的时候，会发生访问错误（//之前的过程都一样，只是直接的系统调用是不经过Xen的）。在这种情况下，产生错误的地址将处于Xen之外（因为Xen不会去执行guest OS系统调用），因此错误就以上文讲过的一般方式进行虚拟化即可。如果由于错误的传播导致了进一步的“双错误”，那么guest OS会像上文谈及的一样被终止。

2.1.3设备I/O

在完全虚拟化环境下需要仿真现有的硬件设备，而Xen不同于此。Xen给出了一套清楚、简单的设备抽象。这就使得我们能够设计一个接口以有效地满足我们对保护性和隔离性的需求。为了做到这一点，I/O和各个domain之间的数据传递都是要经过Xen的，可以使用的方法有共享内存，异步缓冲区描述符环等。这些方法能够在Xen有效地执行确认检查（例如，检查缓冲区是否包括在了domain的存储空间内）的同时，为在系统中的竖直方向上传递缓冲区信息提供了一个高性能的通信机制。和硬件中断类似，Xen支持一个轻量级的事件递交机制用于为一个domain传送异步通告（notification）。这些通告是在对未决事件类型的位图进行更新的时候产生的，也可以通过调用一个guest OS专有的事件句柄产生。这些调用的返回可以由guest OS来决定是否进行“拖延”处理。例如，这么做（//拖延处理）可以避免在频繁唤醒通告时带来的额外开销。

2.2移植OS到Xen的代价

当前我们的NetBSD移植还处于非常初级的阶段，因此我们就没有将其结果在这里报告。虽然XP的移植要更进一步，但也还处于移植过程中；当前移植的XP能够执行RAM上的用户空间的应用，但是缺乏虚拟的I/O驱动。基于这个原因，表中就没有给出和XP的虚拟设备驱动相关的数据。无论怎样，和Linux一样，我们可以想见这些驱动应该是小的和简单的，因为这要得益于Xen提供的理想的硬件抽象。

衡量代价的标准是与原先的x86代码相比修改或增加的那些必要的注释以及遵从一定格式的代码的行数（不包括设备驱动）。对Windows XP中体系结构无关（architecture independent）的代码所作的改动达到了一个惊人的数字，这是因为Windows XP使用了多种多样的结构和联合来访问页表项（PTE）。每次对页表的访问都不得不被单独地进行修改（//因为每次访问都可能用到不同的结构），当然这个过程是可以采用一些脚本来自动完成的。与此相反的，Linux需要的改动就少了很多，这是因为Linux的存储系统是使用预处理程序中的宏来访问PTE的— 这些宏定义为增加准虚拟化所需的转换和hypervisor调用提供了便利的位置（//就在这些位置上加即可）。

在这两个操作系统中，体系结构特有（architecture specific）的部分用于将x86代码向我们的准虚拟架构的移植。这包括重写那些使用了特权指令的程序，删除大量的低层的系统初始化代码。另外，Window XP需要有更多的改变，这主要是因为之前遗留下来的16位仿真代码的存在以及需要一个略有不同引导加载（boot-loading）机制。注意，XP中的x86特有的代码要比Linux多很多，因此可以预见到在做移植的时候也就需要做更多的工作。

2.3控制和管理

贯穿于整个Xen的设计与实现过程中，有一个目标就是尽可能地将策略从机制当中剥离出来。虽然hypervisor必须要被包含在数据通路（data-path aspects）上。例如，在domain之间调度CPU，在发送之前过滤网络数据包，或者在读数据块的时候进行执行访问控制（//必然的，因为Xen位于guest OS和底层硬件之间，guest OS又是彼此隔离的，所以数据传递是一定都要经由Xen的）。但是在更高层次的问题上，例如CPU如何被共享或者各个domain能够发送哪种数据包，这时就不需要将Xen包括在内了，甚至都不用考虑它（//hypervisor是实现机制，而如何共享CPU和如何进行任务分工都是策略问题）。

最终得到的架构是hypervisor只是提供那些最基本的控制操作。这些操作经由一个可访问的接口从经过授权的domain传来；而那些复杂的策略决策，比如许可控制（//不知道这个许可控制是否和第1部分里提到的是一回事儿），都最好由运行在guest OS上的管理软件执行，而并非在有特权的hypervisor代码中（//Xen只是提供机制，不负责策略）。

整个系统架构中有一个domain是在引导（boot）时创建的。这个domain被允许使用控制接口。这个初始的domain，术语称为Domain 0，它负责操控应用级的管理软件。控制接口具有创建和终止其它domain的能力，还能控制它们相关的调度参数、物理存储分配以及它们对给定的物理磁盘和网络设备的访问。

除了处理器和存储资源，控制接口还支持虚拟网络接口（VIF）和块设备（VBD：虚拟块设备）的创建和删除。这些虚拟I/O设备具有一些和访问控制相关的信息。这些信息决定了哪个domain能够访问它们，以及访问时有哪些约束（例如，一个只读的VBD可以被创建，一个VIF可以过滤IP包以防止源地址欺骗）。

这个控制接口，结合对系统当前状态进行的剖析统计，其结果能够被输出到一套运行在Domain 0上的应用级管理软件上。该管理软件作为管理工具的补充，能够对整个服务器进行方便地管理：例如，能够创建和破坏domain，设定网络过滤器和路由规则，在数据包和数据流两个粒度上监视每个domain的网络活动，创建和删除虚拟网络接口和虚拟块设备。我们期待开发出高级的工具来进一步将管理策略的应用程序自动化（//这里的管理策略和前面讲的“机制与策略分开”中的策略不是一回事儿吧？）。

ccid_page/>

3. DETAILED DESIGN — 细节设计

在这一部分，我们介绍构成基于Xen的服务器的各个主要子部分的设计细节。在各个设计中，我们对Xen和guest OS的功能作了清楚的说明。当前的关于guest OS的讨论主要集中于XenoLinux，这主要是因为这个guest OS是目前发展最成熟的；但是我们对于当前正在进行中的对Windows XP和NetBSD的移植工作也是很有信心的。我们相信Xen可以支持多种多样的guest OS。

3.1 控制传递：hypercalls和事件

有两种机制用于Xen和其上的domain之间进行控制的交互：使用hypercall产生从domain到Xen的同步调用；使用异步事件机制完成从Xen到domain的通告递交。

hypercall接口允许domain通过执行一个同步软陷阱陷入到hypervisor执行一个特权操作，这类似于在传统的操作系统中对系统调用的使用。举一个使用hypercall的例子：一组页表更新的请求，要经过Xen确认并且完成相应的更新操作（//更新是要由Xen确认并完成的，需要特权操作，所以这时要利用hypercall陷入到hypervisor中），在更新完成后再由Xen将控制返回给产生本次调用的domain。

从Xen到domain的通信是由一个异步事件机制提供的。这个机制取代了常用的利用设备中断的递交机制，它允许那些重要事件（如domain-termination request）采用轻量级的通告形式。和传统的Unix信号类似，这些重要事件的个数比较少，但每一个都用作针对某一特定类型事件的标记。例如，用于在网络上指出新的数据已经被接收到的事件，或者表示一个虚拟磁盘请求已经完成的事件。

那些未决的事件存放在每个domain的bitmask（//一个专门的数据结构）中。bitmask的更新要由Xen在调用一个和guest OS相应的事件调用返回句柄之前完成（//Xen针对某类事件要向上发通告，如果Xen调用了guest OS相应的事件调用返回句柄，就说明该事件完成了，下面要把控制交回给domain，所以必然要在调用事件调用返回句柄之前由Xen将bitmask更新）。调用返回句柄负责重新设置未决事件集合（//调用返回句柄仍旧是由Xen操作，更新bitmask），同时以相应的行为和通告相呼应。一个domain可以通过设置一个Xen可读的软件标记来显式地推迟对事件操作：这一点是与在真实的处理器中禁止中断的过程类似的。

3.2 数据传递：I/O环

hypervisor的存在意味着在guest OS和I/O设备之间有一个额外的保护域，所以数据的传递机制就变得至关重要。数据传递机制使得数据能够在系统中沿着竖直方向移动，同时具有尽量小的开销。

有两个主要方面构成了我们对I/O传递机制的设计：资源管理和事件通告。为了做到resource accountability，我们在接收到一个来自设备的中断后，要尽量减少在将多路数据分解（//demultiplex data：分解多路数据，数据自硬件设备传来，需要传递给各个指定的domain中的guest OS中执行，这里就存在一个多路选择的问题来确定究竟把数据传给哪个domain；一旦确定了数据是传给哪个domain的，也就说明了此时是哪个domain在使用相关设备，做到了resource accountability）到一个特定的domain中所做的工作 —

管理缓冲区带来的开销是在计算任务分配给相应的domain后产生的（//任务分给domain后，domain才开始对任务数据所处的那部分缓冲区进行管理，而并非用其它的机制对整个缓冲区统一管理，那样会增加复杂性，而且缺乏保障）。类似的，设备I/O的访存操作也是由相应的domain提供的，这么做可以防止由于共享缓冲池导致的相互间的干扰（//如果I/O能够直接访存而不经过domain管理的话，就会产生混乱，比如不清楚I/O操作存取到的数据是属于哪个domain的）；I/O缓冲在数据传递过程中通过Xen内部绑定（pin）到底层页框上面的方法来获得保护。

I/O描述符环是一个循环队列，它由domain分派的描述符组成，可以从Xen内部访问到。描述符中并不直接包含有I/O数据；取而代之的是，I/O数据缓冲被guest OS在带宽外分配再间接地由I/O描述符引用（//I/O描述符环的容量是有限的，所以I/O数据要先进行分配，再做向I/O描述符环上的映射；所谓out-of-band：带宽外，就是在分配数据时可以超出I/O描述符环的限制）。每次环访问都要基于两对生产者-消费者指针：domain通过推进请求生产者指针将一个请求放置在环上；Xen处理这些请求，推进一个相关的请求消费者指针。响应被放回在环上也是类似的，只是由Xen作为生产者，guest OS作为消费者。这里是不要求请求是被按顺序被处理的：guest OS给每个请求都建立了一个唯一的相关标识符，这个标识符会在相关的响应上被复制（//描述符环只是限定了能够处理请求的规模，并不规定处理顺序，谁先被处理谁后被处理是在将数据映射到描述符环上的时候决定的）。这就允许Xen出于调度和优先级的考虑，重新排定I/O操作的顺序。