Xen 的整体架构和整体设计

1、一、 Xen 的整体架构和整体设计      1.Xen的整体架构如图：         （Domain 0)               Domain 1              

2、60;                                          图1   Xen 架构     

3、;  从图中可以看到，VMM介于硬件和虚拟机之间，截获虚拟机的特权指令并代替它们执行。VMM同时提供Domain间的共享内存和事件通道。 有一个特殊的虚拟机VM0（又称Domain0）运行着Linux，其主要作用是完成VM的创建、管理、配置等工作，并完成设备驱动。其他VM访问设备时，Xen获得该请求，然后将其转交给Domain0；当Domain0 完成请求的操作后，Xen再将结果返回给VM。这种做法的好处是Xen可以利用Linux中已有的驱动，不用在重新开发驱动了。2. Xen的泛虚拟化设计：     Xen采用的泛虚拟化技术需要对Guest

4、OS进行相应修改。 IA-32平台上Xen的泛虚拟化技术如下：   1）Guest OS使用特权指令的地方要修改为调用Xen提供的API:hypercalls。    2）硬件中断被轻量级的事件机制取代；对于异常，Guest OS要调用hypercalls来注册自己的异常处理函数。        陷阱的处理程序是注册到VMM上的，而不是直接注册到虚拟CPU上的，这样就节省了一步操作，否则要先引起虚拟硬件的陷阱，再由VMM处理。    &

5、#160;  系统调用注册到处理器。大多数操作系统中，系统调用是通过一个查找表和一个特殊的陷阱队列来处理的。虚拟化后，陷阱队列引起VMM的处理。而Xen跨过这个效率不高的一步，允许虚拟机上的操作系统直接将它们系统调用的处理绑定到处理器上，避免了VMM处理陷阱队列而进行上下文切换的开销。       3）修改内存管理机制：在每个Guest OS的虚拟内存空间保留64M给Xen，物理内存的申请和释放都要经过Xen。每个虚拟机可以对硬件页表进行只读访问，而更新页表的工作则由VMM完成。    

6、;   4）修改I/O使用方法：Xen只提供给VM一些通用快速的设备，VM只能根据Xen定义的API来访问设备。     Xen的I/O模型如下图所示：图2 Xen的I/O模型      Xen采用的是泛虚拟化技术，VM（也称为DomainU）的I/O操作不能直接通过自身的驱动程序访问硬件，而是要借助Domain0的驱动来访问。DomainU的I/O操作由两个主要的驱动模块来完成，即Fronten Driver和Backend Driver。Frontend Driver 位于Domain U中，负责接收Domainu的I/O请求，并把请求交给位于Domain 0的Backend Driver，随后由Backend Driver 调用Domain0中的相关驱动来处理，并把处理结果返回给Frontend，从而完成DomainU的一次I/O操作。    由于Frontend和Backend位于不同的OS中，它们之间的通信要依赖共享内存环和事件通道(Event Channel)来进行。通过共享内