2.1 虚拟机接口
一个准虚拟化的x86接口主要包括了系统中的三个大的方面：存储管理，CPU和设备I/O。在下面，我们将依次介绍各个机器子系统的情况，并讨论在我们的准虚拟化架构中是如何体现的。虽然在我们的实现中，有相当一部分，如存储管理，是专门针对x86的，但是实际上还有很多方面（比如我们虚拟的CPU和I/O设备）都是可以很容易地应用于其它机器架构上的。更进一步地说，在与RISC架构在实现上有差异的很多地方，x86往往表现出的是该方面最坏情况时的情形。例如，对硬件页表进行有效的虚拟化就比虚拟化一个软件管理的TLB困难很多。
存储
管理分段不能够使用具有完全特权级的段描述符，不能够与线性地址空间的最顶部交迭（//因为最顶部是Xen）。
分页guest
OS直接对硬件页表做读访问，但是更新（//就是写）是分批进行的而且要经过hypervisor确认。一个domain可以被分配在不连续的页面上。
CPU保护guest OS必须运行在低于Xen的特权级上。
异常guest OS必须将异常句柄的描述符表在Xen中记录。除了页面错误外，其它句柄和真实的x86架构相同。
系统调用guest OS为系统调用提供一个“快速”的句柄。允许应用直接调用它所在的guest OS，而不必间接地通过Xen完成每次调用。
中断硬件中断被一个轻量级的事件系统替换。
时间每个guest OS具有一个定时器接口，可以得到“真实的”和“虚拟的”时间。
设备I/O网络，磁盘，……虚拟设备访问起来很简单。数据传递使用的是异步I/O环。由一个事件机制替换硬件中断来发布通告。
虚拟化存储毫无疑问是准虚拟化一个体系结构中最困难的部分，它包括hypervisor所需的机制和移植各个guest
OS所需的改动。如果在架构中提供了由软件管理的TLB的话，那么这个任务会变得轻松些，它们可以以比较简单的方式被有效地虚拟化[13]。带标记的TLB是另外一个在大部分RISC架构（这些RISC架构主要用于构建服务器，比如Alpha，MIPS和SPARC）中支持的有用特征。其中，每个TLB项都有和地址空间标识符相关的标记，这使得hypervisor和各个guest OS能够有效地在被隔离开的地址空间内共存。这时在执行转移（//transferring execution：在进程执行间切换的时候，执行的指令序列从一个进程转移到另一个进程，称为执行转移）的时候，是不需要刷新（flush）整个TLB（//只对具有和自己的地址空间标识符相吻合的TLB项进行操作）。
不幸的是，x86架构并没有由软件管理的TLB；取而代之的是在发生TLB失效的时候，处理器会自动通过遍历硬件页表结构来处理。因此为了获得最好的可能达到的性能，当前地址空间内所有的有效页传输）都要在硬件可访问的页表中给出（//最好情况理应如此，但实际如何做得到呢？）。此外，因为TLB是没有标记的，所以地址空间的切换需要整个TLB的刷新。在这些限制下，我们作出了两个决定：（i）由guest OS负责分配和管理硬件页表，这么做最小化了Xen对页表操作的影响，确保了安全性和隔离性；（ii）Xen处于每个地址空间的最顶部的64MB空间内，因此避免了在进入和离开hypervisor时进行TLB刷新操作（//这个要看源代码才能最后搞清楚）。
每当guest OS需要一个新的页表，例如创建了一个新进程，它就在自己保留的内存空间内分配和初始化一个页面，并且将其在Xen中记录。此时操作系统必须放弃对页表存储空间直接写的权限：所有后续的更新操作都必须由Xen进行确认。这就在很多方面限制了更新操作，包括只允许操作系统它自己所属的页进行映射操作，不允许对页表进行可写的映射操作。guest OS可以成批地进行更新操作以减少每次更新都要进入hypervisor带来的代价（//因为每次更新都要hypervisor确认）。每个地址空间顶部的64MB区域是保留给Xen的，是不能够被guest OS访问或者重新进行映射的。因为任何通常的x86架构中的ABI都不会使用到这个区域中的地址，所以这个约束不会破坏到应用程序的兼容性。
分段机制也是以类似的方式，通过对硬件段描述符表的更新确认来进行虚拟化（//这样做就达到虚拟化的目的了么？哦，应该是Xen在确认后接着由Xen执行，嗯）。对于x86架构上段描述符的限制只有：（i）它们的特权级别必须比Xen要低；（ii）它们不能够对地址空间中Xen的保留部分进行访问。
虚拟化CPU对guest OS提出了几个要求。因为hypervisor插在操作系统的下层违背了惯常的关于操作系统在整个系统中特权最高的假设。为了保护hypervisor不会受到操作系统不正确行为的影响（即domain不受另一个domain的影响），guest OS就必须被改造为能够运行在较低的特权级上。
很多处理器体系结构只是提供了两个特权级。在这些情况下，guest OS和应用程序共享较低的特权级。同时，guest OS运行在单独的地址空间中以保护自己不会受到应用程序执行的影响。guest OS通过hypervisor设定虚拟的特权级和改变当前的地址空间来间接地和应用之间进行控制传递。另外，如果处理器的TLB支持地址空间标记，那么也就可以避免TLB刷新带来的高昂代价。
在x86架构上有效地实现特权级的虚拟化是可能的，因为x86架构在硬件上支持四个不同的特权级。x86架构的特权级往往用圈（ring）来表示，从ring 0（最高特权）到ring 3（最低特权）。操作系统的代码运行在ring 0这个特权级上，因为再没有其它的ring能够执行那些特权指令。ring 3通常用于执行应用代码。就我们所知，自OS/2起到现在的各个知名的x86 架构上的操作系统都还没有利用ring 1和ring 2这两个特权级的。那么，任何遵循这个通常的安排的操作系统（//没有利用ring 1和ring 2）就都可以移植到Xen上来。
这个移植过程只需要做一些改动使操作系统改为运行在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会像上文谈及的一样被终止。
；QQ联络：1360095750。