Xen的内存管理

Xen的内存管理机制，系统软件的内存管理机制通常与处理器的体系结构息息相关，X86体系结构中，页表(Page Table)的填充由操作系统完成，而内存管理单元(MMU)在TLB(transaltion lookside buffer)缺失的情况下会自动遍历页表。而某些体系结构中缺失TLB的情况下不会自动遍历页表。本文主要针对半虚拟化的guest OS 系统进行讨论。
X86系列处理器从80286开始引入“保护模式”，它利用分段模式实现内存的隔离和保护，在此基础上稍后的处理器有增加了分页模式，这种分段和分页共存的模式，逐渐被分页模式所替代，AMD已经将分段模式从X86体系结构中去除。
段保护模式(segment protection)
每个段都有自身的访问控制权限的标识，用来标识该段的读、写或者执行所需的权限。代码段通常被标记为可读和可执行，而数据段通常标记为可读和可写。内存段属于处理段内存管理，而要实现细密度的内存管理就必须是页表来实现。
伪物理地址模型(Pseudo-Physical Memory Model)
操作系统很早就引入了虚拟内存这一概念，大多数情况下：virtual memory指的是那些磁盘中分配的页面，与之相反的protected memory 才是通常意义的虚拟内存。
具有protected memory的操作系统中，每个进程都有自己的虚拟地址空间，因此，从应用程序角度来看，他可以访问整个内存空间。在Xen中Hypervisor必须完成操作系统的工作，及一个用户进程必须经过两次映射才能真正转化成实际的物理地址。

其实这种3层地址空间并不是必须，也可以让个内核之接访问物理地址空间，并由Hypervisor来防止越界行为的发生，但是Xen并没有这么做的原因有二：其一、大多数现代操作系统在设计之初，就假设其运行在一个连续的、平坦的物理地址空间。其二、一个VM在器生命周期中，可能被迫迁移到别的物理平台，VM必须被暂停，到了新的物理机，物理地址发生改变，所以必须重新映射地址。
32位X86系统中的分段模式
X86系统采用了分段的内存模型。但与Xen来说，这是一种可用的内存保护隔离机制，每个段是由一个64位段描述定义的，其中32位用来记录段基址，20位用来记录段大小，剩余12位，有一位记录段大小的单位，其余用来标识访问控制权限。所有的段描述都记录在两张表，GDT和LDT.在Xen运行的guest OS可以像普通操作系统直接访问LDT,GDT但是必须通过Hypercall的调用才可以访问。
另一种方法是内存地址空间划分。在32位X86系统中，Xen使用线性地址空间的最高的64MB，并且该段描述为保护标识，这也意味着只用过Ring 0才可以访问该区域内存。顶端1GB 剩余部分被分给guest OS kernel,并且被标记为保护，这部分内存只用Ring0 和Ring1可以访问，放置而已程序的访问，而剩余的3GB分配给guest OS Application.这种方法简单高效，但大部分的现代处理器已经不支持分段模式了，因此在Xen的一致的过程中会出现问题，实际上X86_64平台已经移除了这种机制，因此当Xen运行在64位模式下，这种方法失效了。解决方案就是页式保护机制。
Xen Memory Assist
对于采用该完全虚拟化的guest OS，每次跟新页表都操作系统都会陷入，并由Hypervisor代其完成实际的更新工作，目的是为了保证每个Domain之间的内存隔离和保护。而采用半虚拟化技术的guest OS，内核会使用Hypercall的方式向Hypervisor提出MMU相关操作请求你。使用Hypercall发方式需要对guest OS进行大量的修改，但是其性能比直接陷入强很多。
对于HVM的domain，Xen提供了影子页表（shadow page tables），此时guest OS拥有一份页表的备份，但这些页面被Hypervisor标记为只读，每当guest OS 更新自己的页表的时候，就会发生陷入，控制权随即被转移给Hypervisor，由其负责完成页表的更新工作。HVM需要完全虚拟化他的页表，所以Xen提供了影子页表，但是性能消耗很大，新的CPU技术使用了硬件加速这个过程，性能提高很多。影子页表另一个用处，就是Domain迁移到其他物理机的时候，Hypervisor必须知道追踪哪些页表被修改了。
Xen还提供了一种“完全虚拟化的”半虚拟化的页表和影子页表之间的一种管理方式即wirtiable page,这种模式下，guest OS被提供一种假象，看到页表可写，实际却无法进行写操作，具体实现方法如下：
1.Hypervisor将页表目录入口设置无效，将该页表从系统页表剔除；
2.将页表描述标记为可写；
3.页表控制权交还给guest OS；
4当guest OS做写入页表操作时发生错误；
5.Hypervisor捕获该错误，检查该页表，并将该页表重新链接回 guest OS。
Ballon Driver控制内存使用
在上一篇博客中介绍过ballon driver，Xen本身不支持swap，因此其分配刚给guest OS内存后，Hypervisor不会在用作他用。那么ballon driver提供相关的管理功能。ballon driver就像气球一样，当guest OS内存不够用的时候可以向Hypervisor申请更多的内存，当有不用内存空间就会释放给Hypervisor，类似气球一样高可伸缩。
Domain U 挂起(suspend)、恢复和迁移
大部分客户都希望domain支持暂停和恢复，这样就可以将运行状态和数据保存到磁盘文件中，可以迁移到其他主机上。domain的恢复必须遵循几条规则
1、处理器体系结构必须一致；
2、新的主机必须有足够的RAM来支持domain的运行
3、必须有可用的块设备。
挂起一个domain前，guest OS会从Xenstore获取暂停的指令，并对其自身状态进行调整，进而为工作做好准备，随后调用一个Hypercall进行相关工作。
CPU暂停——在挂起domain的过程中，Xen只负责暂停第一个VCPU的运行，如果该domain运行在多处理器环境下，guest OS必须负责其他VCPU的暂停工作，同样domain恢复过程中，guest OS也必须负责恢复其他VCPU的运行。
domain的回复和保存正好是一个相反的，共享内存页面会通过授权表进行重新映射，在domain恢复过程中pseudo到Physical Memory的映射必须重新映射到新的物理页表。