分段机制也是以类似的方式，通过对硬件段描述符表的更新确认来进行虚拟化（//这样做就达到虚拟化的目的了么？哦，应该是Xen在确认后接着由Xen执行，嗯）。对于x86架构上段描述符的限制只有：（i）它们的特权级别必须比Xen要低；（ii）它们不能够对地址空间中Xen的保留部分进行访问。
2.1.2CPU
虚拟化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会像上文谈及的一样被终止。
2.1.3设备I/O
在完全虚拟化环境下需要仿真现有的硬件设备，而Xen不同于此。Xen给出了一套清楚、简单的设备抽象。这就使得我们能够设计一个接口以有效地满足我们对保护性和隔离性的需求。为了做到这一点，I/O和各个domain之间的数据传递都是要经过Xen的，可以使用的方法有共享内存，异步缓冲区描述符环等。这些方法能够在Xen有效地执行确认检查（例如，检查缓冲区是否包括在了domain的存储空间内）的同时，为在系统中的竖直方向上传递缓冲区畔⑻峁┝艘桓龈咝阅艿耐ㄐ呕啤：陀布卸侠嗨疲琗en支持一个轻量级的事件递交机制用于为一个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和如何进行任务分工都是策略问题）。
上一页 [1] [2] [3] [4] [5] [6] [7] 下一页
共11页: 上一页 [1] [2] [3] [4] [5] [6] 7 [8] [9] [10] [11] 下一页 
