|
|
楼主 |
发表于 2006-7-30 22:08:45
|
显示全部楼层
自己先google了一把，找到一篇
http://mechgouki.blogdriver.com/mechgouki/876153.html
Xen介绍 part1- -
[作者]：滕昱,2005/8/06,0.1版本
[版权声明]：此文档遵循GNU自由文档许可证(GNU Free Documentation License).任何人可以自由复制,分发,修改,不过如果方便,请注明出处和作者
(1)导言
Xen是什么?从完整定义上说，是个半虚拟化(Para-virtualization)的虚拟机(VMM,virtual machine monitor).那么下面就分别解释一下这个定义的前后2部分。
虚拟机：其实就是一个中间层，对上对下公开不同接口，达到隔开的效果。其实在广义上说，所有正确的软件技术或多或少都可以算虚拟机。说popular的，JVM和.NET框架也可以算作虚拟机的一种。不过，在本文中，我们取的是其狭义的定义：在一个os(host)运行多个os(guest)的软件.
半虚拟化:既然有半虚拟化，那么一定有全虚拟化(Full virtualization).这类软件的代表大家都很熟悉:VMware,VirtualPC,WINE.当然还少不了那些运行在X86上的游戏机模拟器。特点就是在host机器中运行的guest OS都不需要进行改动,由虚拟机软件动态的把guest OS的请求翻译成为一般进程的请求由host机器执行。这类软件已经很成熟了，但是由于x86硬件架构的限制，如何解决guest os的运行效率基本上是不可能有什么大进展的了。作为例子，如果你使用过x86下面的VMware，就会发现除了内存操作还可以忍受外，一旦涉及到DMA IO时候，系统性能的急剧下降。(注意，这是在x86架构上，而其他一些架构比如sparc,powerpc由于硬件设计时候考虑，全虚拟化在那些架构上性能相当高效)
对于Xen来说，它的半虚拟化主要是虚拟出了一个叫做Arch_x86的抽象硬件层，运行在x86 chip的Ring0上，在Xen术语中，被称为Domain0---其实就代码角度来说，这是个修改过的“部分linux内核”。然后所有的guest OS，都运行在Ring1和Ring2上面---注意,这意味这guest os必须修改其内核，因为所有的标准内核在x86上都会假设自己可以运行在Ring0。这大约也是半虚拟化的最大弱点。不过所有的guest os上面的应用程序并不需要修改，仍然运行在Ring3上。但是，这样获得的好处就是接近原生os的高效率。
所以，对于windows系统来说，除非MS自己改，否则是无法用半虚拟化支持windows的。当然，在Xen1.0的时候，MS作为这个项目的主要发起者，还是搞出了支持win系统的xen(虽然按照paper的说法，win内核作的改动多的惊人)。但是由于商业上的警觉，MS退出了这个项目。所以现在的Xen2.0并不支持windows。不过，按照Roadmap的说法。Xen3.0会用全虚拟化方式重新支持windows.
当前的稳定版本xen-2.0.7完全支持的os是linux2.4/2.6以及NetBSD.FreeBSD的port已经进入测试阶段，并很快会release.对于Plan9的支持也在进行中。
(2)安装
首先，如果你想偷懒的话，我建议你选择一个有成熟Xen内核版本的linux distribution。现阶段Fedora,Suse,Debian都有2进制包可以方便的完成安装。http://www-128.ibm.com/developer ... yum一样有用。
对于其他os，那么从源代码包编译就是唯一手段。具体方法请参考Xen man page。不过需要你注意的是，Xen编译需要相当多的其他工具，并且对于GRUB应该需要有一定的了解。所以用一个单独硬盘玩是一个"ugly"但是安全的做法。需要特别注意的是如果你使用Xenlinux2.6内核，现阶段必须禁止TLS(Thread Local Storage)。按照文档的说法，这样是避免当前的TLS实现损害Xen。这个问题可能在Xen3.0里面得到解决。
(3)结构
Xen是个多层系统，最底层并且拥有完全硬件访问特权的就是Xen自己---大约可以分为这么几个部分：
(a)Control interface：
只能被一个特殊的guest OS访问，这个guset os被称为Domain0，也是Xen系统启动以后必须运行的guest os，相当于整个Xen系统控制中心。那么这个guest os上面的应用程序就是Xend，Xm，Xensv这类配置管理工具了。通过它们你可以启动或是关闭新的guest os，划分每个guest os的资源(e.g.内存大小)。
(b)Safe Hardware Interface:
Xen的核心部件之一，完成除虚拟cpu,MMU以外所有的硬件虚拟工作，包括DMA/IO，驱动程序，虚拟的PCI地址空间配置，虚拟硬件中断等等。其主要功能是通过Device channel和isolated driver domain(IDD)的模块来完成。你可以把IDD想像成一个server，它管理了所有的真正的硬件io操作。同时，IDD对各个guest os一无所知，它所做的只是相应SHI和Device channel模块给它提交的异步IO请求。而SHI会管理每个guest os通过Device channels请求的IO操作，让它们觉得自己是在和真正的硬件打交道一样。下面看个例子，关于guest OS在Grant Table中请求一个page的步骤：
<1>guest OS通过Device channel标记这个page在IDD中应该被移出---为了防止同一page被多次错误的引用
<2>IDD移出这个page
<3>给Xen的管理模块SHI发送pin的请求消息。
<4>Xen的管理模块SHI查询这个page是否在它所管理的活动的Grant Table中。
<5>如果需要，SHI会通知guest os操作成功
<6>这时候可以给IDD发送一个pin的异步应答消息，告诉它Xen以及更新了这个IO在SHI的状态
<7>IDD向真正的硬件发送DMA请求。
当然，这样的架构设计的损失了性能，特别是在那些需要高速DMA操作的方面，例如，网络数据包的传送。为了避免不必要的数据拷贝。IDD会要求buffer一些guest OS的page，当收到网络数据包的时候，会首先检查其目的地，然后直接使用buffer的page进行数据传送，那么数据包马上就可以在guest os中接受到。
Xen支持2种不同的驱动程序架构
<1>Native Device Driver:对于Domain0，它就一定包括这个驱动。如果guest os具有了这个NDD，就可以使用向Xen的SHI接口。
<2>Front-end Device Driver:这样的驱动架构是看不到SHI层的，它唯一可以作的就是和系统中其他的guest os中拥有Back-end的os通讯，把请求通过这些os的NDD转发出去，特别的，Domain0也一定有这个Back-end模块。
(c)Virtual CPU和Virtual MMU模块：
Xen以Ring0级别运行在线性地址最上面的六十四MB的内存中，在Xen系统中，这部分地址是保留的。在Xen中虚拟出了GDT和LDT。这里可以回到上面所说的TLS问题，由于2.6内核的NPTL线程库设计其TLS可以访问所有的4GB内存，那么势必会影响到这个MB的保留地址，所以在现版本中必须关闭。
(x86_六十四似乎有改动，但是没有看懂，脸红中，残念....)
对于系统调用，因为所有的guest os都修改了内核运行在Ring1/2级别，它们都可以使用一种"fast trap"方法来响应应用程序的系统调用---即直接方式，userspace可以直接进入guest OS被修改过的"内核"空间，然后通过guest os向Xen发起真正的system call,注意这时候就只有一次context-switch,而那些全虚拟化的软件则无法作到这点，因为它们只是host os中的正常进程，并且无法修改guest OS的代码，那么必须模拟出2次context-switch。带来了极大的效率损失
最后对于Virtual CPU来说，现在xen2.0还只能模拟出单cpu，而3.0的目标就是完全支持虚拟的smp架构。
Virtual MMU也是采取2层结构，每个guest OS管理自己的PageTables，然后通过2种不同的更新方式更新真正的硬件PTs
<1>影子模式：这时候guest os打交道的是Xen中的一个虚拟的MMU，它管理了所有的MMU请求。再把它们翻译成真正的硬件请求送交硬件MMU运行。安全但是低效
<2>直接模式：没有虚拟的MMU，guest os的MMU直接通过Xen发起一次系统调用来发送请求到真正的硬件MMU，高效。
...................................
(4)使用
google之，地球人都知道...................
(5)代码分析
以后有空写吧，去看韩剧去了..................
- 作者： mechgouki 2005年08月7日, 星期日 14:58 |
|
IP卡
狗仔卡
发表于 2006-7-30 22:05:22
提升卡
置顶卡
沉默卡
喧嚣卡
变色卡
显身卡