NEVE: Nested Virtualization Extensions for ARM
今天和大家分享的论文题目为NEVE: Nested Virtualization Extensions for ARM，发表于SOSP’17作者是来自Columbia University的Jason Nieh老师组里的Jin Tack Lim。
Introduction
嵌套虚拟化指在虚拟机中运行虚拟机的能力，其在以IaaS为基础的云服务场景中需求十分普遍。尽管当下x86架构的服务器占据了市场大头，但ARM架构的服务器也正在进军云服务市场，并在ARMv8.3中提供了嵌套虚拟化支持。然而，ARMv8.3的硬件还未实现，因此针对ARM嵌套虚拟化设计的硬件辅助VMM也难以实现。为了解决这个问题，本文使用半虚拟化的方法让VMM利用现有指令模拟新架构特性的行为和性能，构建了第一个支持嵌套虚拟化的ARM VMM。本文修改了ARM KVM以支持ARMv8.3的嵌套虚拟化，但由于频繁的trap-emulate操作，其性能很差。为了进一步解决这个问题，本文提出ARM嵌套虚拟化扩展NEVE,可以以最小的硬件和软件复杂度提高嵌套虚拟化性能。
NEVE的设计基于这一观察：ARM上嵌套虚拟化的主要开销来源是VM和VMM之前以及不同VM之间的上下文切换成本，这涉及许多需要VMM干预的指令，尤其为嵌套虚拟化运行VM时涉及多个级别的VMM时这一成本会加剧。但是这些指令并不会立即影响VM和VMM的运行，而是为稍后的运行准备硬件，NEVE会记录这些指令的结果并将trap到VMM的过程合并加推迟，直到实际运行依赖这些上下文，从而显著降低了嵌套虚拟化的开销。NEVE将被加入ARMv8.4架构规范中。
Implementation
ARM虚拟化架构
介绍具体实现之前先简单概括一下ARM架构虚拟化支持的发展：
ARMv8中定义了新的EL0-EL3四种异常特权级，其中EL2是为VMM设计的，ARMV8.0中的CPU虚拟化采用半虚拟化方法，VMM实际是修改过的OS内核，在EL1和EL2之间拆分OS和管理器功能，将VM中敏感操作trap到EL2中处理；ARMv8.1中引入Virtualization Host Extension(VHE)扩展，为EL1和EL2设置了两套独立的寄存器，使得在EL2上可以直接运行未经修改的，为EL1设计的操作系统内核，OS对系统寄存器的访问被VHE透明地重定向到EL2寄存器中。那么如何在ARM上运行嵌套虚拟化？在现有的虚拟化架构下，如果在EL1中运行guest VMM，直接执行EL2的特权指令并不会被trap到EL2中，这会导致VMM崩溃。因此ARMv8.3中引入嵌套虚拟化支持，它会将EL1中执行的hypervisor指令trap到EL2, 并在guest VMM读取CurrentEL寄存器时伪装成EL2运行，并且支持在EL1中使用EL2页表格式。
ARMv8.3嵌套虚拟化模拟
但由于ARMv8.3的硬件尚未实现，因此本文采用半虚拟化的方法实现嵌套虚拟化，半虚拟化的核心是对敏感非特权指令的处理。本文采用的方法是将guest VMM的hypervisor指令替换成HVC指令来trap到EL2中的host VMM中，一条HVC指令接受一个16bit操作数并向EL2生成一个异常，Host VMM根据这一操作数确定原始指令并模拟该指令行为。本文总结了四类需要被捕获并模仿的hypervisor指令：
•只能在EL2中运行的指令，如直接访问EL2的系统寄存器；•Hypervisor访问EL1,但被VHE自动重定向到EL2寄存器的指令；•eret指令，guest VMM不能在不经过host VMM干预的情况下直接返回嵌套虚拟机，因为它们实际共用同一套系统寄存器，其硬件上下文需要由Host VMM保存并恢复；•受开发环境限制，本文在开发阶段使用的是ARMv8.0的硬件，对于VHE引入的一些指令也需要半虚拟化并仿真执行。
内存虚拟化通过影子页表完成，以处理嵌套虚拟化引入的额外内存地址翻译，由于ARM硬件支持的Stage 1&2的页表包含两个阶段的地址转换，而嵌套虚拟化则至少需要三层：L2 VM VA -> L2 VM PA, L2 VM PA -> L1 VMM PA, L1 VMM PA -> L0 VMM PA。本文通过折叠guest VMM->host VMM的 stage-2地址翻译来创建从L2 VM PA->L0 VMM PA的影子页表翻译，即stage-1负责将嵌套虚拟机的虚拟地址翻译为虚拟机物理地址，stage-2负责将嵌套虚拟机物理地址翻译为主机物理地址。中断虚拟化则通过下陷-模拟的方式向guest VMM提供控制接口，基于多路复用GIC虚拟化支持实现。
本文将这种半虚拟化方式实现的嵌套虚拟化与x86进行了对比，具体实验环境配置请移步原文，从上表可以看出，除了在EOI这个指标之外，无论是单级虚拟化还是嵌套虚拟化，ARM性能开销都远超过x86。为了分析ARM嵌套虚拟化性能差的原因，本文进一步测量了运行Hypercall benchmark时Host VMM触发的陷阱次数，发现当嵌套虚拟机调用一次HVC时，不引入和引入VHE扩展会分别触发126和82次下陷，说明嵌套虚拟机的每次exit都会导致从guest VMM到host VMM的大量下陷，而这类下陷是由于ARMv8.0架构上需要显式地将一些hypervisor指令替换为HVC call（主要是对EL2寄存器的访问），以模拟ARMv8.3的行为，这是主要的性能开销来源。因此，对ARMv8.3建模准确与否取决于hvc指令执行时间是否近似于trap-and-emulate。经过进一步实验分析，不同指令的hvc和trap开销总体上差异在10%以内，因此可以认为当前实现的嵌套虚拟化架构可用作ARMv8.3的模拟器。
NEVE设计
上述实验表明：ARMv8.3中嵌套虚拟化的开销主要来自guest VMM执行EL2特权指令时频繁触发的下陷操作，而这些特权指令主要是对EL2寄存器的访问。如果可以减少对这些寄存器的访问次数，就可以提升ARM嵌套虚拟化的性能。经过观察，这些系统寄存器可以进一步分为仅影响VM的和影响VMM的，而仅涉及VM的寄存器并不会立刻影响VM的运行，而是用于VM entry时准备虚拟硬件。
基于上述观察，本文进一步提出NEVE，它避免了因访问系统寄存器的各种hyp指令触发的从guest VMM到host VMM的下陷，并无需对guest VMM和VM进行修改。NEVE包含三个关键机制：
•将虚拟机寄存器存在内存中而非触发下陷，直到虚拟机实际需要它们位置。这一步通过硬件辅助将系统寄存器访问指令透明地重写为内存访问指令实现；•NEVE会识别可以不经下陷直接访问的等效寄存器来减少两层VMM之间的下陷，如Guest VMM需要在VBAR_EL2中写入异常向量基地址，这将触发到EL2的下陷，而Host VMM又需要将地址写入VBAR_EL1以便Guest VMM正确处理异常；•NEVE在内存中保存cache副本，并将寄存器读取指令重定向到内存访问的方法来减少Host VMM在读取某些控制寄存器时的下陷。
为此，NEVE引入了一个新的寄存器Virtual Nested Control Register(VNCR_EL2)，字段如下：
Host VMM将寄存器初始值写入内存，并在运行guest VMM之前启用NEVE，在guest VMM运行期间对VM系统寄存器的所有访问都被重定向到延迟访问页。下表列出了本文总结的27个VM系统寄存器，它们不会影响VMM的运行。
进一步地，本文区分了两种类型的VMM控制寄存器，分别是普通系统寄存器和用于中断虚拟化的相关的GIC寄存器。普通系统寄存器中一部分可以直接从EL2映射到EL1中执行，因为其本质是在EL1的guest VMM中运行；针对EL1和EL2运行不一致的寄存器，本文采用Trap on write方法，即Host VMM先将EL2寄存器值预先写入延迟访问的内存中以供guest VMM读取，而对这些寄存器的写入则会下陷至Host VMM处理；此外还有两个寄存器TCR_EL2和TTBR0_EL2，对其的访问是否需要重定向取决于VHE的配置。
下表总结了与GIC配置相关的接口寄存器，它们会影响VMM在EL2中的运行，NEVE对这些寄存器统一使用Trap on write策略。此外还有一些特殊寄存器的处理，本文并未一一赘述。
由于无法对硬件直接修改，本文采用半虚拟化方法修改了ARM/KVM来支持NEVE，为了实现延迟访问页，本文在主机和guest VMM之间建立了一个共享内存区域，对guest层KVM的修改为将访问EL2控制寄存器的指令替换为访问EL1寄存器的指令，并且KVM有两种运行模式，分别是有VHE和没有VHE。
Evaluation
再次使用microbenchmark测试NEVE性能结果如下：
可以看到，与之前基于ARMv8.3的模拟相比，NEVE的嵌套虚拟化取得了明显的性能提升，尽管与x86之间仍然存在差距，但由于x86单层虚拟化性能本身就比ARM更好，其引入的相对开销其实是近似的。此外，NEVE将ARMv8.3中的下陷次数减少了六倍以上。
Conclusion
本文深入研究了ARM的嵌套虚拟化，提出一种新的半虚拟化技术以在低版本硬件上评估新架构特性，并针对评估结果进一步设计了一个架构扩展，以提高嵌套虚拟化的性能，将在ARM下一个版本中正式引入。
原文始发于微信公众号（COMPASS Lab）：NEVE: ARM硬件辅助嵌套虚拟化扩展
