嵌入式虛擬機管理器Xvisor對比分析

時間 2019-11-10

原文原文鏈接

譯者序

本文翻譯自Embedded Hypervisor Xvisor: A Comparative Analysis。html

虛擬化（Virtualization）這種起源於上世紀60年代IBM大型機系統的技術在處理器性能大幅度提高的當下，再次迅速發展起來，並從最初的的裸機虛擬化（Type-I虛擬化）技術開始，演化出主機虛擬化（Type-II虛擬化）、混合虛擬化（Hybrid虛擬化）等更復雜的虛擬化模型，並在此基礎山發展出了當下最熱門的雲計算技術，極大地下降了IT成本，加強了系統的安全性，可靠性和擴展性。linux

嵌入式系統則是虛擬化技術在嵌入式領域的應用。文中的Xvisor正是一款開源的採用裸機虛擬化技術的輕量級嵌入式Hypervisor，具備良好的代碼架構和和可移植性，支持ARM和X86處理器的半虛擬化和基於硬件的全虛擬化技術。編程

文中圍繞嵌入式Hypervisor的5個核心部分 - 客戶機IO事件模擬、主機中斷、鎖同步延遲、內存管理和內存佔用，基於當下最流行的ARM處理器架構，進行了深刻的闡述和對比。ubuntu

譯者在翻譯時儘可能逐詞翻譯，可是某些語句爲了更清楚的表述根據譯者的理解進行了轉述。如有不妥，請參考原文。後端

摘要

因爲與減小費用、提升資源利用率和更高的性能直接相關，虛擬化技術已經在嵌入式系統中普遍流行。爲了在嵌入式系統的嚴格時間約束和低內存佔用的虛擬化環境中得到高效的性能，咱們須要高效的Hypervisor（虛擬機管理器）。雖然如今已經有了一些開源的Hypervisor，例如Xen，Linux KVM和OKL4 Microvisor，這仍然是第一篇介紹開源嵌入式虛擬機管理器Xvisor(eXtensible Versatile hypervisor)，並從對整個系統性能的影響上，與兩個經常使用虛擬機管理器KVM和Xen進行對比的論文。實驗證實，在ARM處理器架構上，Xvisor具備更低的CPU開銷，更高的內存帶寬，更低的鎖同步延遲和虛擬定時器中斷開銷，而且可以全面提高嵌入式系統性能。數組

關鍵詞：嵌入式系統; 虛擬化; Xen, Linux KVM; Xvisor；ARM；Hypervisor（虛擬機管理器）；緩存

1. 介紹

近年來，多核嵌入式系統需求的增加已經開始引領虛擬化技術在嵌入式系統中的研究。嵌入式系統一般具備資源有限，實時性約束，高性能要求，增加的應用程序棧需求（必須使用有限外設）等特色[參考文獻1]。安全

虛擬化技術提供了在單核或多核處理器上以虛擬機（VM或客戶機）方式運行多個操做系統的方法。每一個客戶機運行在一個或多個虛擬處理單元（vCPU）上。進而，一個客戶機的全部vCPU（虛擬CPU）同另一個客戶機的vCPU徹底隔離，可是共享同一套外設。服務器

所以，虛擬化的應用提供了以下優點[參考文獻2]：網絡

過去運行在不一樣設備上的服務如今能夠做爲多個VM運行在同一個設備上；
在同一個設備上合併操做系統的實時特性和通用目的特性，即在不一樣的VM中執行實時程序和通用程序[參考文獻3]；
更好的容錯性；
提供高可靠應用間的隔離性。

一樣的，嵌入式虛擬化已經有在以下方面有力的證實了它的能力：

摩托羅拉Evoke，第一個虛擬化手機[參考文獻4]；
工業自動化，虛擬化容許添加額外的應用而不須要增長更多的處理單元[參考文獻5]；
汽車能夠經過在若干個互相隔離的VM（虛擬機）上分別運行娛樂信息操做系統、AUTOSAR（汽車開放系統架構）操做系統和RTOS（實時操做系統），從而使得多個服務能夠在同一套硬件上運行[參考文獻6]；
其餘用戶案例，例如零售和博彩行業。

基於下面的考慮，文中的分析性研究將新的嵌入式Hypervisor - Xvisor與2個現存的嵌入式開源Hypervisor - KVM/Xen進行對比：

本次研究基於ARM架構。這是因爲最新的ARM處理器架構已經提供了硬件虛擬化擴展，而且ARM處理器在嵌入式系統中已經獲得了普遍應用。另外，這3個Hypervisor共有的的大部分板級支持包（BSP）都使用了ARM架構處理器。
KVM和Xen被選中做爲對比的虛擬機管理器，是基於以下緣由：
- ARM架構支持[參考文獻7,8];
- 容許咱們沒有任何限制的收集性能數據的開源特性[參考文獻9]；
- 與Xvisor支持一樣的單板；
- 在嵌入式系統中獲得了應用。
實驗使用小型基準測試工具在客戶機上進行測試。這些測試工具測試內存訪問，Cache（高速緩存）訪問，整形操做，任務處理等。這些操做上的性能加強可以提高系統的總體性能，不像是那些專一於測試某種特殊工做負荷（例如Web服務器，內核編譯，圖形渲染等）的宏基準測試工具。
實驗僅使用通用目的操做系統（GPOS）Linux做爲客戶機。由於，這是惟一可被這3種Hypervisor支持的客戶機操做系統。目前沒有一個通用的實時操做系統能夠同時爲這3種ypervisor所支持。所以時間約束測試將經過以下因素的吞吐量測試來實施：
- Hypervisor的低內存和CPU開銷；
- Hypervisor最小負荷狀況下的客戶機調度效率。

Xen，KVM和Xvisor實現的說明和限制的討論以下所示：

本文第2章解釋了虛擬化技術的分類；
本文第3章介紹了Xvisor並提供一個開源虛擬機管理器Xen和KVM的概況。影響到對比因素的主要組件的實現細節的解釋在後續章節中會被顯著說明。後續章節將包括一個基於ARM處理器架構的上述3種Hypervisor的對比分析[參考文獻10]。
咱們在第4講述客戶機IO模擬，而在第5，6，7，8章講述主機中斷處理，鎖同步機制，內存管理和內存佔用。
咱們分析測試時用到的應用程序基準測試程序的簡單說明放在第9章，測試結果放在隨後的第10章，而結論則放在文末。

2. 虛擬化技術分類

基於以下兩個特徵[參考文獻11]，咱們把虛擬化技術劃分爲5類：

Hypervisor設計；
圖1所示的虛擬化模式。

相應的，虛擬化技術分類在經過客戶機獲取的性能測量中扮演着重要角色。

2.1 Hypervisor設計

Hypervisor的角色是硬件和虛擬機之間的接口。這些Hypervisor的實現風格決定了他們做爲虛擬化管理器的操做效率。給予他們的實現，全部Hypervisor都屬於下面3種設計分類之一：

徹底宏內核設計

徹底宏內核Hypervisor使用一個單一的軟件層來負責主機硬件訪問，CPU虛擬化和客戶機IO模擬。例如Xvisor和VMware ESXi Server[參考文獻12]。
部分宏內核設計

部分宏內核Hypervisor一般是一個通用目的宏內核操做系統（例如Linux，FreeBSD，NETBSD，Windows等）的擴展。他們在操做系統內核支持主機硬件訪問和CPU虛擬化，並經過用戶空間軟件支持客戶機IO模擬。例如Linux KVM和VMware Workstation[參考文獻13]。
微內核設計

微內核Hypervisor一般是在Hypervisor內核種提供基本的主機硬件訪問和CPU虛擬化功能的輕量級微內核。它們依賴於一個管理VM來支持整個主機的硬件訪問，客戶機IO模擬和其餘服務。這些微內核Hypervisor中的一些在一個分離的驅動VM上運行每個主機設備驅動程序而不是在通用管理VM上運行。例如Xen，微軟Hyper-V[參考文獻14]，OKL4 Microvisor[參考文獻15]和INTEGRITY Multivisor[參考文獻16]。

2.2 虛擬化模式

虛擬化模式決定了可以在Hypervisor上運行的客戶機的類型[參考文獻17，18]：

全虛擬化

經過提供系統虛擬機（例如模擬相似於真實硬件的整個系統），容許未經修改的客戶機操做系統做爲客戶機運行。（譯者注：該模式須要藉助硬件的虛擬化支持，例如X86架構AMD-V/Intel VT，ARMv8和Power架構的虛擬化profile等。）
半虛擬化

經過提供Hypercall（虛擬機調用接口），容許修改過的的客戶機操做系統做爲客戶機運行。這個模式要求客戶機使用Hypercall來進行各類IO操做（例如，網絡收發，塊讀寫，終端讀寫等等）和在某些時候執行某些關鍵指令。這些Hypercall會觸發一個trap（陷阱）中斷以進入Hypervisor。這些trap中斷基於Hypercall參數，使得Hypervisor爲客戶機提供期待的服務。

3. 嵌入式系統的開源Hypervisor

下面是兩個開源虛擬機管理器Xen和KVM的一個簡單介紹，用於在Hypervisor研究中跟Xvisor進行對照。

因爲咱們研究中對性能比較的關係，咱們講述了這些Hypervisor中已知的招致客戶機運行並由此影響整個虛擬化嵌入式系統性能的系統組件的實現細節。這包括每一個Hypervisor如何處理CPU虛擬化，客戶機IO模擬和主機硬件訪問。另外，每一個Hypervisor的某些主要優點也會被說起。

2.1 XEN

如圖2所示，Xen Hypervisor是一個支持全虛擬化和半虛擬化客戶機的微內核Hypervisor。Xen Hypervisor內核是一個輕量級微內核，提供：

CPU虛擬化；
MMU虛擬化：
虛擬中斷處理；
客戶機間通信[參考文獻19]。

Domain（域）是Xen內核相應於虛擬機或客戶機的概念。

Domain0（Dom0）是一個特殊類型的域，運行着一個Linux內核的修改版本。Dommain0必須運行在一個比任何其餘VM或客戶機更高的優先級上，而且具備對主機硬件的徹底訪問權限。Dom0的主要目的是利用Linux內核提供IO虛擬化和客戶機管理服務。

DomainU（DomU）相應於運行着一個客戶機操做系統的客戶虛擬機。客戶機的IO事件模擬和半虛擬化經過DomU和Dom0之間的通信來實現。這一目的經過使用Xen事件通道來完成。半虛擬化客戶機，相應於DomU PVM，使用Xen事件通道來訪問Dom0半虛擬化IO服務。但是，全虛擬化客戶機，相應於DomU HVM，使用運行在Dom0用戶空間中的QEMU來模擬客戶機IO事件。

全部用來管理客戶機或域的用戶接口都經過運行在Dom0用戶控件的Xen工具棧來完成。沒有Dom0，Xen不能提供DomU PVM或者DomU HVM。 Xen最重要的優點是使用Linux內核做爲Dom0，由於這能幫助Xen重用Linux內核現有的設備驅動和其餘部分。但是，這個優點帶來了後面章節將會提到的額外代價。也就是說，做爲Dom0運行的Linux內核比直接運行在真實硬件上（沒有Xen）稍微慢了一點。這是由於，Dom0只是Xen的另外一個域，有它本身的嵌套頁表，而且可能被Xen調度器調度出去。

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個主要組件：

內核空間字符設備驅動，經過一個字符設備文件/dev/kvm提供CPU虛擬化服務和內存虛擬化服務；
提供客戶機硬件模擬的用戶空間模擬器（一般是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]）上的安裝需求和最小內存佔用。所以後面問題答覆以下：

須要知足什麼條件才能使Xen ARM，KVM ARM和Xvisor ARM運行在系統上？
Xen ARM，KVM ARM和Xvisor ARM須要消耗的的最小內存是多少？

上圖中：

1. Xen工具棧與其它依賴庫單獨安裝。這個工具棧容許用戶管理虛擬機建立、銷燬和配置。它能夠經過命令行終端和圖形接口使用（[參考文獻[10]）。
1. Xen保留大量內存，用於事件通道。上圖中：
1. Xvisor內核在單個二進制文件中包含完整的虛擬化功能，而且隨着更多新特性的增長從而增加到2~3M字節；
1. 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版本：

KVM: 最新的Linux-3.16-rc3被用做主機KVM內核。客戶機內核是Linux-3.16-rc3。
Xen：2014年8月3日發佈的最新的Xen-4.5-unstable內核被用做Hypervisor。Dom0內核和DomU均爲Linux-3.16-rc3。
Xvisor：2014年7月18日發佈的最新的Xvisor-0.2.4+被用做Hypervisor。客戶機內核是Linux-3.16-rc3。

實驗結果經過兩個測試向量獲取。第一個運行在一個單核上，而另外一個運行在一個雙核上。測試系統（SUT，systems under test）以下：

沒有任何Hypervisor的主機；
Xvisor客戶機；
KVM客戶機；
HugeTLB模式KVM客戶機；
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未來在網絡和存儲虛擬化方面的實現也能具備更好的性能。

參考文獻

Motivation for running a Hypervisor on Embedded Systems
R.Kaiser, "Complex embedded systems-A case for virtualization," in Intelligent solutions in Embedded Systems, 2009 Seventh Workshop on, pp. 135-140. IEEE, 2009.
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.
Heiser, Gernot. "The Motorola Evoke QA4-A Case Study in Mobile Virtualization." Open Kernel Labs (2009).
「Case Study: The Use of Virtualization in Embedded Systems,」 white paper,2013.
G.Heiser, "Virtualizing embedded systems: why bother?," in Proceedings of the 48th Design Automation Conference, pp. 901-905. ACM, 2011.
Dall, Christoffer, and Jason Nieh. "KVM/ARM: Experiences Building the Linux ARM Hypervisor." (2013).
Rossier, Daniel. "EmbeddedXEN: A Revisited Architecture of the XEN hypervisor to support ARM-based embedded virtualization." White paper, Switzerland (2012).
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.
[ARMv7-AR architecture reference manual](http://infocenter.arm.com/help/topic/com.arm.doc.ddi0406c/index. html)
Xvisor open-source bare metal monolithic hypervisor
The Architecture of VMware ESXi
1. 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.
OKL4 Microvisor
1. 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.
INTEGRITY Multivisor
Full Virtualization
Paravirtualization
Xen Project Beginners Guide
1. Russell. Virtio PCI Card Specification v0.9.5 DRAFT, May
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.
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.
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.
Memory Footprint
Cubiboard
RP.Weicker, "Dhrystone: a synthetic systems programming benchmark," Communications of the ACM 27, no. 10 (1984):1013-1030.
Dhrystone
PJ.Mucci, K.London, and J.Thurman. "The cachebench report."University of Tennessee, Knoxville, TN 19 (1998).
Stream
Hackbench Ubuntu Manuals