Xvisor comparative analysis of embedded Virtual Machine Manager

• Translator's Preface
• Summary
• 1 Introduction
• 2. Virtualization Category
  • 2.1 Hypervisor Design
  • 2.2 virtualization mode
• 3. Embedded Systems Open Source Hypervisor
  • 2.1 XEN
  • 2.2 KVM
  • 2.3 Xvisor
• 4. Client IO event simulation
  • 4.1 Xen ARM
  • 4.2 KVM ARM
  • 4.3 Xvisor ARM
• 5. host interrupt
  • 5.1 Xen ARM
  • 5.2 KVM ARM
  • 5.3 Xvisor ARM
• 6. lock synchronization delay
• 7. Memory Management
  • 7.1 Xen ARM
  • 7.2 KVM ARM
  • 7.3 Xvisor ARM
• 8. Compare memory footprint
• 9. benchmark
  • 9.1 Dhrystone
  • 9.2 Cachebench
  • 9.3 Stream
  • 9.4 Hackbench
• 10. Experiment
• 11. Conclusion
• references

Translator's Preface

This translation from Embedded Hypervisor Xvisor: A Comparative the Analysis .

Virtualization (Virtualization) technology that originated in the 1960s of the last century IBM mainframe systems in processor performance greatly enhance the moment, again developed rapidly, and from the beginning of the bare-metal virtualization (Type-I virtualization) technology start, evolved host virtualization (Type-II virtualization) , mixed virtualization (hybrid virtualization) and other more complex virtual model, and on this basis to develop the mountain today is the most popular cloud computing technology, which greatly reduces IT costs, enhanced security, reliability and scalability.

Embedded system is application virtualization technology in the embedded field. The text of the Xvisor it is an open source using bare-metal virtualization lightweight embedded technology Hypervisor, with good structure and code and portability, support for ARM and X86 processor paravirtualization and based on full hardware virtualization technology.

Embedded Hypervisor paper around the five core part - Client IO event simulation, host interrupt, delay lock synchronization, memory management and memory usage, based on the currently most popular ARM processor architecture, conducted in-depth exposition and contrast.

The translator translate word by word as much as possible, but some statements in order to more clearly express understanding was quoted according to the translator. If inappropriate, please refer to the original.

Summary

Since directly related to reduce costs, improve resource utilization and higher performance, virtualization technology has been widely popular in embedded systems. In order to obtain efficient performance under strict time constraints of embedded systems and low memory footprint of the virtual environment, we need efficient Hypervisor (virtual machine manager). Although it has been some open source Hypervisor, such as Xen, Linux KVM and OKL4 Microvisor, this is still the first to introduce open source embedded virtual machine manager Xvisor (eXtensible Versatile hypervisor), and from the impact on the overall system performance, in contrast to the two papers were commonly used virtual machine Manager KVM and Xen. Experiments show that, on the ARM processor architecture, Xvisor has a lower CPU overhead, higher memory bandwidth, lower latency and virtual lock synchronization timer interrupt overhead and can enhance performance embedded systems.

Keywords : Embedded systems; virtualization; Xen, Linux KVM; Xvisor; ARM; Hypervisor ( virtual machine manager);

1 Introduction

In recent years, the growth of multi-core embedded systems demand has begun to lead the virtual technology research in embedded system technology. Embedded systems usually have limited resources, the real-time constraints, performance requirements, a growing demand application stack (peripherals must be limited), etc. [Reference 1].

Virtualization technology provides a method of running multiple operating systems on a single or multi-core processors to a virtual machine (VM or client) mode. Each client running on one or more virtual processing units (vCPUs) on. Furthermore, all vCPU a client (virtual CPU) with another vCPU a client completely isolated, but share the same set of peripherals.

Thus, the virtualized application provides the following advantages [Reference 2]:

1. Last run on different devices and services now available as multiple VM running on the same device;
2. The combined system operating in real-time property on the same equipment and general purpose properties, i.e., real-time program execution and a general procedure in a different VM, [Reference 3];
3. Better fault tolerance;
4. Provide isolation between the high-reliability applications.

Similarly, the embedded virtualization has been in the following areas eloquent testimony to its ability to:

1. Motorola Evoke, a first virtual phone [Reference 4];
2. Industrial automation, allowing additional virtual applications without the need to add more processing units [Ref. 5];
3. Each car can run on a number of mutually isolated VM (Virtual Machine) operating system, infotainment, AUTOSAR (Automotive Open System Architecture) operating systems and RTOS (Real Time Operating System), which allows multiple services on the same set of hardware run [Ref. 6];
4. Other use cases, such as retail and gaming industries.

Based on the following considerations, research and analysis of the text of the new Embedded Hypervisor - Xvisor with two existing open-source embedded Hypervisor - KVM / Xen comparison:

1. This study is based on ARM architecture. This is due to the latest ARM processor architecture has provided hardware virtualization extensions, ARM processors and embedded systems have been widely used. In addition, the three most common Hypervisor Board Support Package (BSP) use the ARM architecture processors.

2. KVM and Xen was selected as a comparison of Virtual Machine Manager, is based on the following reasons:
   • ARM architecture supports [Ref 7,8];
   • It allows us to collect performance data limits do not have any open-source characteristic of [Ref. 9];
   • The same board and Xvisor support;
   • It has been used in embedded systems.

3. Experiments using a small benchmarking tool for testing on the client. These testing tools to test memory access, Cache (cache) access, shaping operations, tasking. Performance on the operation of these enhancements can improve overall system performance, unlike those macro benchmarking tool focused on testing a particular workload (such as a Web server, compile the kernel, graphics rendering, etc.).

4. Experiments using only general-purpose operating system (GPOS) Linux as a client. Because this is the only supported these three Hypervisor guest operating system. There is no a universal real-time operating system at the same time as these three ypervisor supported. Thus the test time constraints will be implemented by a certain test of the following factors:
   • Hypervisor low memory and CPU overhead;
   • Client scheduling efficiency under minimum load conditions the Hypervisor.

And limiting discussion illustrates Xen, KVM and Xvisor implemented as follows:

• In Chapter 2 explains the classification of virtualization technology;
• This article Chapter 3 introduces the Xvisor and provide an open source hypervisor Xen and KVM profiles. Explains implementation details of the major components of the contrast factors influence will be significantly described in the following sections. Subsequent chapters include a comparison based on the above three Hypervisor ARM processor architecture analysis [Reference 10].
• Our clients tell IO simulation in the fourth, while in Chapter 5,6,7,8 told host interrupt handling, lock synchronization, memory management and memory footprint.
• We analyze a simple description of the application benchmark testing program used when placed in Chapter 9, the test results on the subsequent Chapter 10, and then placed in the end the conclusion.

2. Virtualization Category

Wherein based on the two [Ref. 11], we virtualization divided into five categories:

• Hypervisor design;
• Virtualization mode shown in FIG.

Accordingly, the virtualization technology plays an important role in the classification performance measurements acquired by the client.

2.1 Hypervisor Design

Hypervisor role is the interface between the hardware and the virtual machines. These Hypervisor implementations style determines the efficiency of their operations as the virtualization manager. Give them true, all belong to one of three Hypervisor Design Category below:

1. Fully monolithic design

   Fully monolithic Hypervisor using a single software layer responsible for accessing the host hardware, CPU virtualization and client IO simulation. E.g. Xvisor and the VMware Server ESXi [Ref. 12].

2. Part of the macro core design

   Hypervisor is usually part of a monolithic general-purpose monolithic operating system (such as Linux, FreeBSD, NETBSD, Windows, etc.) extensions. They visit and CPU virtualization, and support the client through the user IO space simulation software in the operating system kernel supports a host hardware. E.g. Linux KVM and the VMware Workstation [Reference 13].

3. Microkernel design

   Hypervisor microkernel is generally lightweight micro-kernel to provide basic hardware access and the host CPU Hypervisor virtualization capabilities in core species. They rely on a VM management hardware to support a whole host access client IO simulation, and other services. These micro-kernel to run some of the Hypervisor each host device driver in a separate VM drive instead of running on a general purpose management VM. For example the Xen , Microsoft-V the Hyper [Ref. 14], OKL4 Microvisor [Ref. 15] and the INTEGRITY Multivisor [Ref. 16].

2.2 virtualization mode

Virtualization mode determines the type capable of running on a client Hypervisor [References 17 and 18]:

1. Full virtualization

   By providing a system virtual machine (such as simulation of the entire system is similar to real hardware), allows unmodified guest operating system runs as a client. ( Translator's Note : With this mode requires hardware virtualization support, such as X86 architecture AMD-V / Intel VT, ARMv8 Power Architecture and virtualization profile and so on.)

2. Paravirtualization

   By providing Hypercall (VM call interface), allows modified guest operating system running as a client. This mode requires the use of the client to perform various Hypercall IO operations (e.g., a network transceiver, the block read, write terminal, etc.) and in certain implementation of certain critical instructions. These Hypercall triggers a trap (trap) to break into the Hypervisor. These trap interrupt Hypercall based on parameters such Hypervisor provides the client with expectations of service.

3. Embedded Systems Open Source Hypervisor

The following is a brief introduction of two open source hypervisor Xen and KVM, for comparison with Xvisor Hypervisor in the study.

As we study the relationship between performance comparison, we describe these Hypervisor known incur a client running and thus affect the implementation details of the entire virtualized system performance embedded system components. This includes how to deal with each Hypervisor CPU virtualization, client and host IO analog hardware access. In addition, some of the main advantages of each Hypervisor will also be mentioned.

2.1 XEN

As shown, Xen Hypervisor is a 2 supports full virtualization Hypervisor microkernel and paravirtualized machine . Xen Hypervisor core is a lightweight micro-kernel , provides:

• CPU virtualization;
• MMU Virtualization:
• Virtual interrupt processing;
• Communication between the client [Ref. 19].

Domain (domain) is the Xen kernel corresponding to the virtual machine or client concept.

Domain0 ( Dom0 ) is a special type of field, running a modified version of the Linux kernel. Dommain0 must be run on a priority than any other VM or higher client machine, and have full access to the host hardware. The main purpose is to provide Dom0 IO virtualization and management services to clients using the Linux kernel.

DomainU ( DomU ) corresponding to running a guest operating system guest virtual machine. IO event simulation client and paravirtualization be achieved through communication between DomU and Dom0. This object is accomplished by using the Xen event channel. Paravirtual client, corresponding to DomU PVM, using the Xen Dom0 event channel to access the IO paravirtualization service. However, full virtualization client, corresponding to DomU HVM, use QEMU to run in user space Dom0 to simulate client IO event.

All used to manage client or domain user interfaces are run in Xen Dom0 tool stack of user controls to complete. No Dom0, Xen can not provide DomU PVM or DomU HVM.

The most important advantage is the use of the Linux kernel as a Xen Dom0, because it helps Xen reuse existing Linux kernel device driver and other parts. However, this advantage brings additional costs will be mentioned later chapters. In other words, as Dom0 running Linux kernel than running on real hardware (not Xen) a little bit slow. This is because, Dom0 Xen is just another domain, has its own nested page tables, and can be scheduled to go out Xen scheduler.

2.2 KVM

KVM(基于内核的虚拟机)是一个支持全虚拟化和半虚拟化技术的部分宏内核Hypervisor。KVM主要提供全虚拟化客户机，并以可选的VirtIO设备[参考文献20]的形式提供半虚拟化支持。

KVM扩展Linux内核的执行模式以允许Linux作为一个Hypervisor来工作。除了已有的2种执行模式（内核模式和用户模式），客户机模式被作为一种新的模式添加到Linux内核中。这种方式允许客户机操作系统与主机操作系统运行在相同的执行模式下（除了某些特殊指令和寄存器访问），并且IO访问将陷入到主机Linux内核。主机Linux内核将把一个虚拟机视作一个QEMU进程。KVM只能在主机内核上虚拟化CPU，并且依赖于运行在用户控件的QEMU来处理客户机IO事件的模拟和半虚拟化。

如图2所示，KVM包含2个主要组件：

1. 内核空间字符设备驱动，通过一个字符设备文件/dev/kvm提供CPU虚拟化服务和内存虚拟化服务；
2. 提供客户机硬件模拟的用户空间模拟器（通常是QEMU）。

与这两个组件之间的服务请求通讯，例如虚拟机和vCPU的创建，通常通过/dev/kvm设备文件的IOCTRL操作来处理。

KVM最重要的优势（类似于Xen）是使用Linux内核作为主机内核。这样有助于KVM重用Linux内核现有的设备驱动和其他部分。然而，由于KVM依赖于嵌套页表故障机制的客户机模式到主机模式的虚拟机切换，特殊指令陷阱（Trap），主机中断，客户机IO事件，和另一个从主机模式唤醒客户机执行的虚拟机切换，这个优势也导致了KVM整体性能本质上的降低。

2.3 Xvisor

图4中的Xvisor是一个支持全虚拟化和半虚拟化技术的完全宏内核Hypervisor。它的目的是提供一个仅需少量系统开销和很小内存占用的在嵌入式系统中使用的轻量级Hypervisor。Xvisor主要提供全虚拟化客户机，并以VirtIO设备[参考文献20]的形式提供半虚拟化支持。

Xvisor的所有核心组件，例如CPU虚拟化，客户机IO模拟，后端线程，半虚拟化服务，管理服务和设备驱动，都作为一个独立的软件层运行，不需要任何必备的工具或者二进制文件。

客户机操作系统运行在Xvisor上，具有更少的特权；而Xvisor的实现负责调用标准vCPU。此外，所有设备驱动和管理功能的后端处理运行在不具有最高优先级的孤儿vCPU（没有分配给某个客户机的vCPU）上。客户机配置信息以设备树(Device Tree)[参考文献21]的形式维护。这种方式通过使用设备树脚本（DTS），使得客户机硬件信息的维护更加容易。换句话说，为嵌入式系统定制一个虚拟机时不需要修改代码。

Xvisor最重要的优势是运行在提供所有虚拟化相关服务的最高特权等级上的单一软件层。不像KVM，Xvisor的上下文切换非常轻量级（参见第5章），因此嵌套页表、特殊指令陷阱、主机中断和客户机IO事件等的处理也非常快速。进而，所有设备驱动都作为Xvisor的一部分直接运行，具有完全的特权并且没有嵌套页表，以确保不会出现性能退化。另外，Xvisor的vCPU调度器是基于单CPU的，不处理多核系统的负载均衡。在Xvisor中，多核系统的负载均衡器是一个分离的部分，独立于vCPU调度器（不像KVM和XEN）。在Xvisor中，vCPU调度器和负载均衡器都是可扩展的。

Xvisor唯一的限制是缺少Linux那样丰富的单板和设备驱动。为了处理这个限制，Xvisor提供了Linux兼容层头文件以方便从Linux内核移植设备驱动框架和设备驱动。尽管不能完全解决问题，移植成本也可以大幅度减少。

4. 客户机IO事件模拟

嵌入式系统需要作为虚拟机（VM）或客户机运行传统软件。传统嵌入式软件可能期待需要Hypervisor模拟的特殊硬件。这就是为什么Hypervisor必须尽可能减小客户机IO事件模拟的开销。后面的小章节解释了前面提及的Hypervisor在ARM处理器架构上模拟的客户机IO事件的生命周期。注意，这非常重要。因为在这些Hypervisor中，客户机IO事件流在所有处理器架构包括ARM上都是相同的。

4.1 Xen ARM

图5展示了Xen ARM用于DomU HVM（全虚拟化客户机）的客户机IO事件模拟的生命周期。从标志1开始，一个客户机IO事件被触发，然后使用标志2和标志3所示的Xen事件通道转发到Dom0内核。随后，运行在Dom0用户空间的QEMU在标志4模拟客户机IO事件。最后在标志5，控制返回到DomU。

图中所示流程导致了一定数目的开销。首先，尽管已经进行过优化，基于域间通信的Xen事件通道还是具有非零开销。其次，Dom0内核到用户空间和相反方向的上下文切换增加了客户机IO事件模拟的开销。

4.2 KVM ARM

图6展示了客户机IO事件模拟在KVM ARM上的处理流程。图中场景开始在标志1，即一个客户机IO事件被触发的时刻。客户机IO事件引起一个VM-Exit事件，引起KVM从客户机模式切换到主机模式。然后，如标志2和3所示，客户机IO事件被运行在用户空间的QEMU处理。最后，在标志4处，VM-enter发生，引起KVM从主机模式切换到客户机模式。

处理开销主要由VM-exit和Vm-ente上下文切换引起，而这正是KVM众所周知的严重开销。

4.3 Xvisor ARM

不像其他Hypervisor，Xvisor ARM在客户机IO事件模拟上不会引发额外的调度或者上下文切换的开销。如图7所示，流程开始在标志1，一个客户机IO事件被Xvisor ARM捕获时。随后，事件在标志2处的不可睡眠的通用上下文中被处理以确保时间被处理，并具有预期的开销。

5. 主机中断

嵌入式系统在处理主机中断时，必须遵守严格的时间约束。在虚拟化环境中，Hypervisor在处理主机中断时可能会有额外的开销，转而影响主机IO性能。请重点注意，文中所述的Hypervisor的主机中断处理流程对所有处理器架构包括ARM都是相同的。

5.1 Xen ARM

在Xen中，主机设备驱动作为Dom0 Linux内核的一部分运行。因此所有主机中断都被转发到Dom0。如图8所示，流程开始在标志1，一个主机IRQ（中断请求）被触发，然后在标志2处被转发到Dom0。如图中标志3和4所示，所有主机中断由Dom0处理。如果一个主机中断在DomU运行时被触发，那么它将在Dom0被调度进来后才能得到处理，因此主机中断处理引发了调度开销。

5.2 KVM ARM

图9所示为KVM ARM上客户机正在运行时的主机中断处理流程[参考文献22]。如图中标志1所示，每个主机中断触发一个VM-exit。一旦中断如图中标志2和3所示，被主机内核处理，KVM通过标志4处的VM-entry恢复客户机。当某个KVM客户机处于运行状态时，VM-exit和VM-entry增加了相当大的主机中断处理开销。进而，如果主机中断被转发到KVM客户机，那么调度开销也会存在。

5.3 Xvisor ARM

Xvisor的主机设备驱动通常作为Xvisor的一部分以最高权限运行。因此，图10中，处理主机中断时是不需要引发调度和上下文切换开销的。只有当主机中断被转发到一个当前没有运行的客户机时，才会引发调度开销。

6. 锁同步延迟

在虚拟化环境中，锁同步延迟问题是[参考文献23]中提到的一个众所周知的问题。这个问题因如下2个调度器的存在而产生：

• Hypervisor调度器
• 客户机OS调度器

这里，两个调度器互相意识不到对方，导致客户机vCPU被Hypervisor随意抢占。我们给出了一个关于这种延迟和所有3个Hypervisor如何处理它们的一个简要介绍。

同一个客户机中vCPU之间锁同步的低效处理导致了图11和12中显示的两个不确定场景：vCPU抢占和vCPU堆积问题。两种问题都可能导致在获取同一个客户机的vCPU锁时增加等待时间。

当一个运行在持有锁的某主机CPU（pCPU0）上的vCPU（vCPU0）被抢占，而同时另一个运行在其他主机CPU（pCPU1）上的vCPU（vCPU1）正在等待这个锁，那么vCPU抢占问题就会发生。另外，发生在一个运行着多个vCPU的单主机CPU上的锁调度冲突问题也会导致vCPU堆积问题发生。也就是说，希望获取某个锁的vCPU（vCPU1）抢占了运行在同一个主机CPU上的vCPU（vCPU0），但是vCPU0正在持有这个锁。


在ARM机构上，操作系统典型的使用WFE（等待事件）指令来等待请求一个锁，并使用SEV（发送事件）指令来释放一个锁。ARM架构允许WFE指令被Hypervisor捕获，但是SEV指令不能被捕获。为了解决vCPU堆积问题，所有3种Hypervisor（Xen ARM，KVM ARM和Xvisor ARM）都使用捕获WFE指令的方法使得vCPU让出时间片。ARM架构的vCPU抢占问题能够通过使用半虚拟化锁的方式来解决，但是需要对客户机操作系统进行源码级的修改。

7. 内存管理

嵌入式系统要求有效的内存处理。对于嵌入式Hypervisor来说，内存管理的开销需要慎重考虑。ARM架构提供2级翻译表（或者说嵌套页表），用于客户机内存虚拟化,即图13所示的2阶段MMU。客户机操作系统负责编程第1阶段页表，将客户机虚拟地址(GVA)翻译到间接物理地址（IPA）。ARM Hypervisor负责编程第2阶段页表来从将间接物理地址（IPA）翻译成实际物理地址（PA）。

TLB-miss（Translation Look-aside Buffers miss，即页表缓冲缺失）时必须检索翻译表。这个过程中使用的第2阶段页表的级数影响内存带宽和虚拟化系统的整体性能。比如最糟糕的情况下，N级第1阶段翻译表和M级第2阶段翻译表需要NxM次内存访问。对任何虚拟化系统上的客户机来说，TLB-miss损失都是非常昂贵的。为了减少2阶段MMU中的TLB-miss损失，ARM Hypervisor在第2阶段创建更大的页。

7.1 Xen ARM

Xen ARM为每个客户机或域（Dom0或DomU）创建一个独立的3级第2阶段翻译表。Xen ARM能创建4K字节，2M字节或1G字节的第2阶段翻译表项。Xen ARM也按需分配客户机内存，并试图基于IPA和PA对齐构造尽可能最大的第2阶段翻译表项。

7.2 KVM ARM

KVM用户空间工具（QEMU）预先分配作为客户机RAM使用的用户空间内存，并向KVM内核模块通知其位置。KVM内核模块为每个客户机vCPU创建一个独立的3级第2阶段翻译表。典型的，KVM ARM将创建4K字节大小的第2阶段翻译表项，但是也能够使用巨大化TLB优化模式创建2M字节大小的第2阶段翻译表项。

7.3 Xvisor ARM

Xvisor ARM在客户机创建时，预先分配连续的主机内存以做为客户机RAM。它为每个客户机创建一个独立的3级第2阶段翻译表。Xvisor ARM能创建4K字节，2M字节或1G字节的第2阶段翻译表项。另外，Xvisor ARM总是基于IPA和PA对齐创建尽可能最大的第2阶段翻译表项。最后，客户机RAM是扁平化和连续的（不像其它Hypervisor）。这有助于缓存预取访问，从而进一步提升客户机内存访问性能。

8. 内存占用比较

嵌入式系统要求小内存占用（[参考文献[24]）。下表I，II和III显示Cubieboard2（[参考文献[25]）上的安装需求和最小内存占用。因此后面问题答复如下：

1. 需要满足什么条件才能使Xen ARM，KVM ARM和Xvisor ARM运行在系统上？
2. Xen ARM，KVM ARM和Xvisor ARM需要消耗的的最小内存是多少？

上图中：

• a) Xen工具栈与其它依赖库单独安装。这个工具栈允许用户管理虚拟机创建、销毁和配置。它可以通过命令行终端和图形接口使用（[参考文献[10]）。
• b) Xen保留大量内存，用于事件通道。
  
  
  上图中：
• c) Xvisor内核在单个二进制文件中包含完整的虚拟化功能，并且随着更多新特性的增加从而增长到2~3M字节；
• d) Xvisor使用编译选项来限制自己的内存占用，ARM架构默认设置为16M字节。

9. 基准测试程序

我们实验中使用的基准测试程序专注于从CPU开销、内存带宽和锁同步机制方面比较Hypervisor。

9.1 Dhrystone

Dhrystone是一个用于测量处理器整形性能的简单基准测试（[参考文献[26]）。Dhrystone基准测试的每秒总迭代次数被称为每秒Dhrystones。进而，Dhrystone结果的另外一个表示是DMIPS（每秒百万条Dhrystone指令数），也就是每秒Dhrystones除以1757。DMIPS只不过是与VAX 11/780，，典型的1 MIPS机器（[参考文献[27]）进行比较的计算机系统的性能。

9.2 Cachebench

Cachebench来评估计算机系统内存体系的性能。它专注于把处理器内外的高速缓存的多个级别参数化。Cachebench进行不同缓冲区大小的测试：内存设置、内存复制、整数读取，整数写入和整数读取-修改-写入。对于我们的实验，我们将生成以兆字节每秒为单位的内存复制和整数读取-修改-写入测试的结果。

9.3 Stream

内存带宽已经被认为能够影响系统性能（[参考文献[29]）。STREAM是一个设计用来测量持续内存带宽（以兆字节每秒为单位）的简单复合基准测试程序。STREAM基准测试被明确的设计在任何系统的非常大的数据集合上工作，而不是可用的高速缓冲上。我们实验中使用的STREAM版本是v5.10，2000000数组大小（大约45.8M字节）

9.4 Hackbench

Hackbench通过确定调度给定数目任务花费的时间来测量系统调度器性能。Hackbench的主要工作是调度线程和进程。调度实体通过套接字或管道收发数据来通讯。运行测试程序时能够对数据大小和消息数目进行设置。

10. 实验

后面的实验目的在于评估近期提议的嵌入式Hypervisor - Xvisor相较KVM和Xen的效率。本文试图在Cubieboard2（[参考文献[25]）上的客户机Linux上运行4个基准测试程序。Cubieboard2是一块包含1GB RAM的ARM Cortex-A7双核1GHz单板。试验中使用了如下Hypervisor版本：

1. KVM: 最新的Linux-3.16-rc3被用作主机KVM内核。客户机内核是Linux-3.16-rc3。
2. Xen：2014年8月3日发布的最新的Xen-4.5-unstable内核被用作Hypervisor。Dom0内核和DomU均为Linux-3.16-rc3。
3. Xvisor：2014年7月18日发布的最新的Xvisor-0.2.4+被用作Hypervisor。客户机内核是Linux-3.16-rc3。

实验结果通过两个测试向量获取。第一个运行在一个单核上，而另一个运行在一个双核上。测试系统（SUT，systems under test）如下：

1. 没有任何Hypervisor的主机；
2. Xvisor客户机；
3. KVM客户机；
4. HugeTLB模式KVM客户机；
5. Xen客户机。

为了确保只有CPU开销，内存带宽和锁同步延迟被引入测试结果，两个测试向量都有一个具有2个vCPU的半虚拟化客户机。而且，所有Hypervisor都进行了如下优化：

• 没有来自于通用中断控制器的维护中断；
• Xen ARM超级页支持；
• WFE指令捕获-出让vCPU机制。

表IV和V显示以DMIPS为单位的Dhrystone结果。Xvisor客户机的DMIPS比KVM客户机高大约0.2%，比HugeTLB模式KVM客户机高0.19%，比Xen DomU高0.46%。Dhrystone基准测试很小，在运行时几乎可以放在高速缓存中，因此内存访问开销不会对其产生影响。尽管只有2个DMIPS的提升，这仍然提升了整个系统性能，因为1个DMIPS等于每秒1757次迭代。所以，使肌体上将是每秒数千次迭代（通常是几百万条机器指令）。




表VI, VII, VIII和IX显示内存复制和整数读取-修改-写入两种操作的Cachebench结果。Xvisor客户机的内存复制结果比KVM客户机高大约18%，比HugeTLB模式KVM客户机高1.2%，比Xen DomU高0.67%。Xvisor客户机的整数读取-修改-写入结果也比KVM客户机高大约1.14%，比HugeTLB模式KVM客户机高1.2%，比Xen DomU高1.64%。

表X和XI显示Xvisor客户机的持续性内存带宽比KVM客户机高大约0.72%，比HugeTLB模式KVM客户机高1.57%，比Xen DomU高1.2%。

表XII和XIII中的Hackbench结果显示示Xvisor客户机的任务分发延迟比KVM客户机低大约12.5%，比HugeTLB模式KVM客户机低5.62%，比Xen DomU低6.39%。

11. 结论

这篇论文介绍了作为开源Hypervisor - Xen和KVM性能缺点解决方案的新嵌入式Hypervisor - Xvisor。Xvisor的实现优点体现在如下几个方面：

• 客户机IO模拟;
• 主机中断处理；
• 锁同步延迟；
• 内存占用；
• 内存管理。

而且，4种不同基础准测试的显示结果支撑了Xvisor的实现优势。

实验结果显示Dhrystone，Cachebench和Stream基准测试在Xvisor ARM客户机上具有更高的速率。这证明Xvisor ARM客户机具有相对于KVM ARM客户机和Xen ARM DomU更低的CPU开销和更高的内存带宽。进而，Hackbench在Xvisor ARM客户机上具有更少的执行时间。这说明Xvisor ARM客户机具有相对于KVM ARM客户机和Xen ARM DomU更低的锁同步延迟和虚拟定时器中断开销。这些结果意味着Xvisor ARM下的客户机相对于KVM ARM和Xen ARM更接近原生性能。最后， Xvisor ARM更小的内存占用允许它在嵌入式系统上更有效的利用有限的内存。

Xvisor允许额外的板级支持包（BSP）。更多的多核体验（不止是双核）也是可能的。而且，基于上述测量数据已经证明的性能提升，Xvisor将来在网络和存储虚拟化方面的实现也能具有更好的性能。

参考文献

1. Motivation for running a Hypervisor on Embedded Systems
2. R.Kaiser, "Complex embedded systems-A case for virtualization," in Intelligent solutions in Embedded Systems, 2009 Seventh Workshop on, pp. 135-140. IEEE, 2009.
3. Heiser, Gernot. "The role of virtualization in embedded systems," in Proceedings of the 1st workshop on Isolation and integration in embedded systems, pp. 11-16. ACM, 2008.
4. Heiser, Gernot. "The Motorola Evoke QA4-A Case Study in Mobile Virtualization." Open Kernel Labs (2009).
5. “Case Study: The Use of Virtualization in Embedded Systems,” white paper,2013.
6. G.Heiser, "Virtualizing embedded systems: why bother?," in Proceedings of the 48th Design Automation Conference, pp. 901-905. ACM, 2011.
7. Dall, Christoffer, and Jason Nieh. "KVM/ARM: Experiences Building the Linux ARM Hypervisor." (2013).
8. Rossier, Daniel. "EmbeddedXEN: A Revisited Architecture of the XEN hypervisor to support ARM-based embedded virtualization." White paper, Switzerland (2012).
9. Soriga, Stefan Gabriel, and Mihai Barbulescu. "A comparison of the performance and scalability of Xen and KVM hypervisors." In Networking in Education and Research, 2013 RoEduNet International Conference 12th Edition, pp. 1-6. IEEE, 2013.
10. ARMv7-AR architecture reference manual
11. Xvisor open-source bare metal monolithic hypervisor
12. The Architecture of VMware ESXi
13. E. Bugnion, S. Devine, M. Rosenblum, J. Sugerman, and E. Y.Wang, “Bringing Virtualization to the x86 Architecture the Origiinal VMware Workstation,” ACM Transactions on Computer Systems, 30(4):12:1-12:51, Nov 2012.
14. OKL4 Microvisor
15. H. Fayyad-Kazan, L. Perneel and M. Timerman, “Benchmarking the Performance of Microsoft Hyper-V server, VMware ESXi, and Xen Hypervisors”, Journal of Emerging Trends in Computing and Information Sciences, Vol. 4, No. 12, Dec 2013.
16. INTEGRITY Multivisor
17. Full Virtualization
18. Paravirtualization
19. Xen Project Beginners Guide
20. R. Russell. Virtio PCI Card Specification v0.9.5 DRAFT, May
21. G.Likely, and J.Boyer, "A symphony of flavours: Using the device tree to describe embedded hardware," in Proceedings of the Linux Symposium, vol. 2, pp. 27-37. 2008.
22. R.Ma, F.Zhou, E.Zhu, and H.GUAN, "Performance Tuning Towards a KVM-based Embedded Real-Time Virtualization System." Journal of Information Science and Engineering 29, no. 5 (2013): 1021-1035.
23. X.Song, J.Shi, H.Chen, and B.Zang, "Schedule processes, not vcpus," in Proceedings of the 4th Asia-Pacific Workshop on Systems, p. 1. ACM, 2013.
24. Memory Footprint
25. Cubiboard
26. RP.Weicker, "Dhrystone: a synthetic systems programming benchmark," Communications of the ACM 27, no. 10 (1984):1013-1030.
27. Dhrystone
28. PJ.Mucci, K.London, and J.Thurman. "The cachebench report."University of Tennessee, Knoxville, TN 19 (1998).
29. Stream
30. Hackbench Ubuntu Manuals

Reproduced in: https: //www.cnblogs.com/EmbeddedLiving/p/7426501.html