5.2 功耗和性能测量

表3展示了在ARM平台上使用KVM/ARM和在x86平台上使用KVM x86 进行虚拟化的各种微体系结构成本。测量结果以循环而不是时间的形式显示，以便在具有不同CPU频率的平台之间提供有用的比较。在可能的情况下，我们将为ARM平台显示两个数字，其中包含和不包含VGIC和虚拟计时器的支持。

Hypercall是两个世界交换机的开销，从虚拟机到主机，然后立即返回，不需要在主机中做任何工作。由于两个主要因素，与KVM x86相比，KVM/ARM在此操作中需要3到4倍的时钟周期。首先，在ARM上保存和恢复VGIC状态以使用虚拟中断的开销是很大的，可用的x86硬件还没有提供这种机制。在没有VGIC和虚拟时钟的ARM平台上，测量时不包括保存和恢复VGIC状态的开销，结果表明，该操作在ARM的两个world切换时VGIC状态的恢复和保存占用了一半的开销。其次，x86提供了硬件支持，可以在world切换时自动保存和恢复状态，这要快得多。ARM需要软件显式地保存和恢复状态，这提供了更大的灵活性，但成本更高。但是，如果没有VGIC状态，hypercall的开销只比x86服务器平台上硬件加速hypercall的开销多大约600个周期。ARM world切换的成本还没有优化，还可以进一步降低。例如，一个小补丁消除了不必要的原子操作，从而降低了大约300个时钟周期的hypercall开销，但是直到v3.10发布之后才将其纳入主线内核。另一个例子是，如果部分VGIC状态执行惰性上下文切换而不是在每个world切换上保存和恢复，这也可以降低world切换的开销。

Trap是将硬件模式从虚拟机模式切换到运行hypervisor的CPU模式、ARM上的HYP模式和x86上的root模式的成本。结果表明ARM的trap操作要比x86的trap要快得多,因为ARM只需要操作两个寄存器来完成这个trap,而trap在x86的开销也只是粗略的执行world切换，因为在这两种情况下，硬件保存的状态相同。ARM上的trap开销只占world开销中的很小一部分，这表明在ARM上由分裂模式虚拟化引起的双trap不会增加太多开销。

I/O kernel是从虚拟机到设备的I/O操作的开销，其是在内核中被模拟的。

I/O User显示向用户空间中模拟的设备发出I/O操作的开销，向I/O内核中添加从内核空间到用户空间进程的转换开销，以及在主机上的用户空间中为I/O做少量工作的开销。这代表了使用QEMU的成本。由于这些操作涉及到world切换，而保存和恢复VGIC状态再次成为ARM的一项重大成本。KVM x86在I/O内核上比KVM/ARM快，但是在I/O用户上稍微慢一些。这是因为x86上关于world的切换的硬件优化占据了在内核中执行I/O操作大部分开销，但是在x86上，从内核到主机端的用户空间进程的转换开销更大，因为x86 KVM在进入用户空间时惰性地保存和恢复额外的状态。注意，访问用户空间的附加开销包括保存额外的状态、在用户空间中做一些工作、返回内核并处理KVM_RUN ioctl对KVM的调用。

IPI是一个虚拟CPU和向另一个虚拟CPU发出IPI的开销，且这两个虚拟CPU都运行在单独的物理内核上且都在虚拟机中积极运行。IPI测量从发送IPI到另一个虚拟CPU响应并完成IPI的时间。它涉及到多个world的切换以及发送和接收硬件IPI的操作。尽管ARM的world切换开销较高，但是ARM比x86更快，因为x86上的底层硬件IPI比较占据开销，x86上的APIC MMIO操作需要KVM x86执行ARM上不需要的指令解码，而在x86上完成中断的开销较大。没有VGIC/虚拟定时器的ARM比使用VGIC/虚拟定时器的ARM要慢得多，尽管它具有更低的world切换开销，因为发送、EOI和ACK都会导致陷入到hypervisor，并且由QEMU在用户空间中来处理。

EOI+ACK是在两个平台上完成虚拟中断的开销，它包括中断确认和ARM上的完成操作，但是在x86平台上其值包含的完成操作。ARM需要一个额外的操作，确认中断控制器，以便确定中断的来源。而x86并不会这样做，因为在引发中断时，中断源是由中断描述符表条目直接指示的。但是，ARM上的操作速度大约是x86上的5倍，因为在ARM平台上并不需要陷入hhypervisor，这是因为VGIC本来就支持这个操作。在x86上,必须模拟EOI操作，因此会给hypervisor造成一个trap。每个虚拟中断都需要这个操作，包括虚拟ip和来自虚拟设备的中断。

图3到7显示了相对于各自的本地执行系统的测量结果，虚拟化执行测试标准化了，开销更小。

 

 

 

 

图3和图4显示了在虚拟机中运行lmbench与直接在主机上运行lmbench的规范化性能。图3显示了KVM/ARM和KVM x86在单个CPU配置中也有类似的虚拟化开销。作为对比，我们还展示了没有VGIC/vtimer的VM/ARM性能。总的来说，使用VGIC/ vtimer提供了稍好一点的性能，但是管道和ctxsw工作负载的性能相差很大。在本例中，造成高开销的原因是每当进程阻塞时需要更新Linux调度器中的运行队列时钟，因为在没有虚拟计时器的情况下需要将计数器读入ARM平台的用户空间。我们在支持VGIC但没有虚拟定时器的情况下通过运行工作负载时读取计时器的数值验证了这一点。

图4显示了多核配置中KVM/ARM和KVM x86之间虚拟化开销存在更大差异，与KVM x86 fork和exec相比，KVM/ARM的开销更小，但开销更多被用于保护故障。但是，对于管道和ctxsw工作负载，这两个系统的开销都是最差的。这是由于每次从管道中的数据发送方向接收方重复发送IPI的开销以及在调度新进程时发送IPI的开销造成的。x86不仅具有比ARM更高的IPI开销，而且它还必须对每个IPI进行EOI，在x86上比在ARM上开销大得多，因为这需要让x86陷入hypervisor,而ARM并不需要。如果不使用VGIC/ 虚拟定时器，KVM/ARM与KVM x86的开销相当，因为它还会陷入hypervisor来对IPIs进行ACK和EOI。

图5和图6显示了在虚拟机中运行应用程序工作负载与直接在主机上运行应用程序工作负载的规范化性能。图5显示，除了MySQL工作负载之外，KVM/ARM和KVM x86在单个核心配置中的所有工作负载中都有类似的虚拟化开销，但是图6显示多核上的性能差异更大。在多核平台上，Apache和MySQL的开销在KVM/ARM上明显少于KVM x86。总的来说，在多核的情况下，在KVM/ARM上的所有应用程序的工作负载比直接在硬件上运行的情况多执行10%的任务量。而更成熟的KVM x86系统对于Apache和MySQL有更高的虚拟化开销。KVM/ARM的分裂模式虚拟化设计允许它利用ARM硬件支持，其性能与使用x86硬件支持的传统hypervisor相当。测量结果还表明，KVM/ARM在支持VGIC/虚拟计时器的情况下比没有支持的请看看下整体表现更好。

图7显示了对多核上的各种应用程序工作负载使用虚拟化和直接执行的标准化功耗。我们只比较了KVM/ARM的ARM平台与支持KVM x86的x86笔记本的功耗。在这些实验中使用的Intel Core i7 CPU是Intel最优的功耗处理器之一，我们预计服务器功耗会更高。测量结果表明，在除memcached和untar之外的所有情况下，使用VGIC/ 虚拟计时器的KVM/ARM都比KVM x86虚拟化更高效。这两个工作负载在两个平台上都不是CPU绑定的，功耗也不受虚拟化层的显著影响。但是，由于ARM对于这些工作负载的虚拟化开销略高，所以对于这两个工作负载，ARM的能源虚拟化开销略高。虽然对虚拟化的功耗方面的更详细的研究超出了本文的范围，但是这些测量提供了比较ARM和x86虚拟化功耗成本的有用数据。

 

5.3 实现的复杂度

我们将KVM/ARM的代码复杂度与Linux 3.10中的KVM x86进行比较。KVM/ARM是5812行代码，仅计算添加到其中的特定于体系结构的代码，其中lowvisor仅仅是718行。作为保守的比较，KVM x86是25367行，但不包括客户性能监控支持，KVM/ARM还不支持，AMD支持需要3311行。这些数字不包括KVM的体系结构通用代码。表格四展示将整个特定于hypervisor体系结构的代码分解为其主要组件的相关情况。

通过检查这些代码，我们注意到x86实现中惊人的额外复杂性主要来自以下五个原因。

1. 由于早期的硬件版本不支持EPT, KVM x86必须支持影子页表

2. 随着时间的推移，硬件虚拟化支持也在不断发展，要求软件有条件地检查对大量特性(如EPT)的支持

3. 许多操作需要对x86平台上的指令进行软件解码。而KVM/ARM的out-of-tree MMIO指令解码实现要简单得多，只有462行

4. x86上的各种分页模式需要更多的软件逻辑来处理页面错误

5. x86需要更多的软件逻辑来支持中断和计时器，而ARM提供VGIC/vtimer硬件支持，从而降低了软件的复杂性

KVM/ARM的代码数量比单独为HYP模式编程的程序少得多，而lowvisor代码数几乎要小一个数量级。与独立的hypervisor不同，KVM/ARM的代码复杂度非常小，因为Linux已经提供了许多功能，所以不必重新实现这些功能。表4不包括其他非hypervisor特定于体系结构的Linux代码，例如基本引导，这是非常多的代码。将独立的hypervisor(如Xen)从x86移植到ARM要复杂得多，因为用于基本系统功能的所有ARM代码都需要从头编写。相反，由于Linux在ARM上占主导地位，KVM/ARM只是利用了现有的Linux ARM在Linux支持的每个平台上运行。