3G Eden
RSS地址空间压缩是指 VMM 必须在Guest OS 的地址空间中保留一部分供其使用。例如，中断描述表寄存器（IDT Register）中存放的是中断描述表的线性地址，如果 Guest OS 运行过程中来了外部中断或触发处理器异常，必须保证运行权马上转移到 VMM 中，因此 VMM 需要将 Guest OS 的一部分线性地址空间映射成自己的中断描述表的主机物理地址。VMM 可以完全运行在 Guest OS 的地址空间中，也可以拥有独立的地址空间，后者的话，VMM 只占用 Guest OS 很少的地址空间，用于存放中断描述表和全局描述符表（GDT）等重要的特权状态。无论如何哪种情况，VMM 应该防止 Guest OS 直接读取和修改这部分地址空间。
内存是一种非常重要的系统资源，VMM 必须全权管理，Guest OS 理解的物理地址只是客户机物理地址（Guest Physical Address），并不是最终的主机物理地址（Host Physical Address）。当 Guest OS 发生缺页异常时，VMM 需要知道缺页异常的原因，是 Guest 进程试图访问没有权限的地址，或是客户机线性地址（Guest Linear Address）尚未翻译成 Guest Physical Address，还是客户机物理地址尚未翻译成主机物理地址。一种可行的解决方法是 VMM 为 Guest OS 的每个进程的页表构造一个影子页表，维护 Guest Linear Address 到 Host Physical Address 的映射，主机 CR3 寄存器存放这个影子页表的物理内存地址。VMM 同时维护一个 Guest OS 全局的 Guest Physical Address 到 Host Physical Address 的映射表。发生缺页异常的地址总是Guest Linear Address，VMM 先去 Guest OS 中的页表检查原因，如果页表项已经建立，即对应的Guest Physical Address 存在，说明尚未建立到 Host Physical Address的映射，那么 VMM 分配一页物理内存，将影子页表和映射表更新；否则，VMM 返回到 Guest OS，由 Guest OS 自己处理该异常。
系统调用是操作系统提供给用户的服务例程，使用非常频繁。最新的操作系统一般使用 SYSENTER/SYSEXIT 指令对来实现快速系统调用。SYSENTER 指令通过IA32_SYSENTER_CS，IA32_SYSENTER_EIP 和 IA32_SYSENTER_ESP 这 3 个 MSR（Model Specific Register）寄存器直接转到 Ring 0级；而 SYSEXIT 指令不在 Ring 0 级执行的话将触发异常。因此，如果 VMM 只能采取 Trap-And-Emulate 的方式处理这 2 条指令的话，整体性能将会受到极大损害。
所有的外部中断和主机处理器的异常直接由 VMM 接管，VMM 构造必需的虚拟中断和异常，然后转发给 Guest OS。VMM 需要模拟硬件和操作系统对中断和异常的完整处理流程，例如 VMM 先要在 Guest OS 当前的内核栈上压入一些信息，然后找到 Guest OS 相应处理例程的地址，并跳转过去。VMM 必须对不同的 Guest OS 的内部工作流程比较清楚，这增加了 VMM 的实现难度。同时，Guest OS 可能频繁地屏蔽中断和启用中断，这两个操作访问特权寄存器 EFLAGS，必须由 VMM 模拟完成，性能因此会受到损害。 Guest OS 重新启用中断时，VMM 需要及时地获知这一情况，并将积累的虚拟中断转发。
Guest OS对特权资源的每次访问都会触发处理器异常，然后由 VMM 模拟执行，如果访问过于频繁，则系统整体性能将会受到极大损害。比如对中断的屏蔽和启用，cli（Clear Interrupts）指令在 Pentium 4 处理器上需要花费 60 个时钟周期（cycle）。又如，处理器本地高级可编程中断处理器（Local APIC）上有一个操作系统可修改的任务优先级寄存器（Task-Priority Register），IO-APIC 将外部中断转发到 TPR 值最低的处理器上（期望该处理器正在执行低优先级的线程），从而优化中断的处理。TPR 是一个特权寄存器，某些操作系统会频繁设置（Linux Kernel只在初始化阶段为每个处理器的 TPR 设置相同的值）。
软件 VMM 所遇到的以上挑战从本质上来说是因为 Guest OS 无法运行在它所期望的最高特权级，传统的 Trap-And-Emulate 处理方式虽然以透明的方式基本解决上述挑战，但是带来极大的设计复杂性和性能下降。当前比较先进的虚拟化软件结合使用二进制翻译和超虚拟化的技术，核心思想是动态或静态地改变 Guest OS 对特权状态访问的操作，尽量减少产生不必要的硬件异常，同时简化 VMM 的设计。
  |
Intel-VT 硬件辅助虚拟化技术详解
2005 年冬天，英特尔带来了业内首个面向台式机的硬件辅助虚拟化技术 Intel-VT 及相关的处理器产品，从而拉开了 IA 架构虚拟化技术应用的新时代大幕。支持虚拟化技术的处理器带有特别优化过的指令集来自动控制虚拟化过程，从而极大简化 VMM 的设计，VMM 的性能也能得到很大提高。其中 IA-32 处理器的虚拟化技术称为 VT-x，安腾处理器的虚拟化技术称为 VT-i。AMD 公司也推出了自己的虚拟化解决方案，称为 AMD-V。尽管 Intel-VT 和 AMD-V 并不完全相同，但是基本思想和数据结构却是相似的，本文只讨论 Intel-VT-x 技术。
新增的两种操作模式
VT-x 为 IA 32 处理器增加了两种操作模式：VMX root operation 和 VMX non-root operation。VMM 自己运行在 VMX root operation 模式，VMX non-root operation 模式则由 Guest OS 使用。两种操作模式都支持 Ring 0 ~ Ring 3 这 4 个特权级，因此 VMM 和 Guest OS 都可以自由选择它们所期望的运行级别。
这两种操作模式可以互相转换。运行在 VMX root operation 模式下的 VMM 通过显式调用 VMLAUNCH 或 VMRESUME 指令切换到 VMX non-root operation 模式，硬件自动加载 Guest OS的上下文，于是 Guest OS 获得运行，这种转换称为 VM entry。Guest OS 运行过程中遇到需要 VMM 处理的事件，例如外部中断或缺页异常，或者主动调用 VMCALL 指令调用 VMM 的服务的时候（与系统调用类似），硬件自动挂起 Guest OS，切换到 VMX root operation 模式，恢复 VMM 的运行，这种转换称为 VM exit。VMX root operation 模式下软件的行为与在没有 VT-x 技术的处理器上的行为基本一致；而VMX non-root operation 模式则有很大不同，最主要的区别是此时运行某些指令或遇到某些事件时，发生 VM exit。
虚拟机控制块
VMM 和 Guest OS 共享底层的处理器资源，因此硬件需要一个物理内存区域来自动保存或恢复彼此执行的上下文。这个区域称为虚拟机控制块（VMCS），包括客户机状态区（Guest State Area），主机状态区（Host State Area）和执行控制区。VM entry 时，硬件自动从客户机状态区加载 Guest OS 的上下文。并不需要保存 VMM 的上下文，原因与中断处理程序类似，因为 VMM 如果开始运行，就不会受到 Guest OS的干扰，只有 VMM 将工作彻底处理完毕才可能自行切换到 Guest OS。而 VMM 的下次运行必然是处理一个新的事件，因此每次 VMM entry 时， VMM 都从一个通用事件处理函数开始执行；VM exit 时，硬件自动将 Guest OS 的上下文保存在客户机状态区，从主机状态区中加载 VMM 的通用事件处理函数的地址，VMM 开始执行。而执行控制区存放的则是可以操控 VM entry 和 exit 的标志位，例如标记哪些事件可以导致 VM exit，VM entry 时准备自动给 Guest OS “塞”入哪种中断等等。
客户机状态区和主机状态区都应该包含部分物理寄存器的信息，例如控制寄存器 CR0，CR3，CR4；ESP 和 EIP（如果处理器支持 64 位扩展，则为 RSP，RIP）；CS，SS，DS，ES，FS，GS 等段寄存器及其描述项；TR，GDTR，IDTR 寄存器；IA32_SYSENTER_CS，IA32_SYSENTER_ESP，IA32_SYSENTER_EIP 和 IA32_PERF_GLOBAL_CTRL 等 MSR 寄存器。客户机状态区并不包括通用寄存器的内容，VMM 自行决定是否在 VM exit 的时候保存它们，从而提高了系统性能。客户机状态区还包括非物理寄存器的内容，比如一个 32 位的 Active State 值表明 Guest OS 执行时处理器所处的活跃状态，如果正常执行指令就是处于 Active 状态，如果触发了三重故障（Triple Fault）或其它严重错误就处于 Shutdown 状态，等等。
前文已经提过，执行控制区用于存放可以操控 VM entry 和 VM exit 的标志位，包括：
- External-interrupt exiting：用于设置是否外部中断可以触发 VM exit，而不论 Guest OS 是否屏蔽了中断。
- Interrupt-window exiting：如果设置，当 Guest OS 解除中断屏蔽时，触发 VM exit。
- Use TPR shadow：通过 CR8 访问 Task Priority Register（TPR）的时候，使用 VMCS 中的影子 TPR，可以避免触发 VM exit。同时执行控制区还有一个 TPR 阈值的设置，只有当 Guest OS 设置的 TR 值小于该阈值时，才触发 VM exit。
- CR masks and shadows：每个控制寄存器的每一位都有对应的掩码，控制 Guest OS 是否可以直接写相应的位，或是触发 VM exit。同时 VMCS 中包括影子控制寄存器，Guest OS 读取控制寄存器时，硬件将影子控制寄存器的值返回给 Guest OS。
VMCS 还包括一组位图以提供更好的适应性：
- Exception bitmap：选择哪些异常可以触发 VM exit，
- I/O bitmap：对哪些 16 位的 I/O 端口的访问触发 VM exit。
- MSR bitmaps：与控制寄存器掩码相似，每个 MSR 寄存器都有一组“读”的位图掩码和一组“写”的位图掩码。
每次发生 VM exit时，硬件自动在 VMCS 中存入丰富的信息，方便 VMM 甄别事件的种类和原因。VM entry 时，VMM 可以方便地为 Guest OS 注入事件（中断和异常），因为 VMCS 中存有 Guest OS 的中断描述表（IDT）的地址，因此硬件能够自动地调用 Guest OS 的处理程序。
更详细的信息请参阅 Intel 开发手册 [5]。
解决纯软件虚拟化技术面临的挑战
首先，由于新的操作模式的引入，VMM 和 Guest OS 的执行由硬件自动隔离开来，任何关键的事件都可以将系统控制权自动转移到 VMM，因此 VMM 能够完全控制系统的全部资源。
其次，Guest OS 可以运行在它所期望的最高特权级别，因此特权级压缩和特权级别名的问题迎刃而解，而且 Guest OS 中的系统调用也不会触发 VM exit。
硬件使用物理地址访问虚拟机控制块（VMCS），而 VMCS 保存了 VMM 和 Guest OS 各自的 IDTR 和 CR3 寄存器，因此 VMM 可以拥有独立的地址空间，Guest OS 能够完全控制自己的地址空间，地址空间压缩的问题也不存在了。
中断和异常虚拟化的问题也得到了很好的解决。VMM 只用简单地设置需要转发的虚拟中断或异常，在 VM entry 时，硬件自动调用 Guest OS 的中断和异常处理程序，大大简化 VMM 的设计。同时，Guest OS 对中断的屏蔽及解除可以不触发 VM exit，从而提高了性能。而且 VMM 还可以设置当 Guest OS 解除中断屏蔽时触发 VM exit，因此能够及时地转发积累的虚拟中断和异常。
|
未来虚拟化技术的发展
我们可以看到，硬件辅助虚拟化技术必然是未来的方向。Intel-VT目前还处在处理器级虚拟化技术的初级阶段，尚需在如下方面进行发展：
- 提高操作模式间的转换速度。
两种操作模式间的转换发生之如此频繁，如果不能有效减少其转换速度，即使充分利用硬件特性，虚拟机的整体性能也会大打折扣。早期的支持硬件辅助虚拟化技术的 Pentium 4 处理器需要花费 2409 个时钟周期处理 VM entry，花费 508 个时钟周期处理由缺页异常触发的 VM exit，代价相当高。随着 Intel 技术的不断完善，在新的 Core 架构上，相应时间已经减少到 937 和 446 个时钟周期。未来硬件厂商还需要进一步提高模式的转换速度，并提供更多的硬件特性来减少不必要的转换。
时间:2009-08-18 16:41 来源:developerWorks 中国 作者:林 昊翔 原文链接
