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

如果你認爲本系列文章對你有所幫助，請大家有錢的捧個錢場，點擊此處贊助，贊助額0.1元起步，多少隨意

聲明：本文只用於個人學習交流，若不慎造成侵權，請及時聯繫我，立即予以改正

鋒影

email:[email protected]

 

• 譯者序
• 摘要
• 1. 介紹
• 2. 虛擬化技術分類
  • 2.1 Hypervisor設計
  • 2.2 虛擬化模式
• 3. 嵌入式系統的開源Hypervisor
  • 2.1 XEN
  • 2.2 KVM
  • 2.3 Xvisor
• 4. 客戶機IO事件模擬
  • 4.1 Xen ARM
  • 4.2 KVM ARM
  • 4.3 Xvisor ARM
• 5. 主機中斷
  • 5.1 Xen ARM
  • 5.2 KVM ARM
  • 5.3 Xvisor ARM
• 6. 鎖同步延遲
• 7. 內存管理
  • 7.1 Xen ARM
  • 7.2 KVM ARM
  • 7.3 Xvisor ARM
• 8. 內存佔用比較
• 9. 基準測試程序
  • 9.1 Dhrystone
  • 9.2 Cachebench
  • 9.3 Stream
  • 9.4 Hackbench
• 10. 實驗
• 11. 結論
• 參考文獻

譯者序

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

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

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

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

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

摘要

由於與減少費用、提高資源利用率和更高的性能直接相關，虛擬化技術已經在嵌入式系統中廣泛流行。爲了在嵌入式系統的嚴格時間約束和低內存佔用的虛擬化環境中獲得高效的性能，我們需要高效的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]：

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

同樣的，嵌入式虛擬化已經有在如下方面有力的證明了它的能力：

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

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

1. 本次研究基於ARM架構。這是由於最新的ARM處理器架構已經提供了硬件虛擬化擴展，並且ARM處理器在嵌入式系統中已經得到了廣泛應用。另外，這3個Hypervisor共有的的大部分板級支持包（BSP）都使用了ARM架構處理器。

2. KVM和Xen被選中作爲對比的虛擬機管理器，是基於如下原因：
   • ARM架構支持[參考文獻7,8];
   • 允許我們沒有任何限制的收集性能數據的開源特性[參考文獻9]；
   • 與Xvisor支持同樣的單板；
   • 在嵌入式系統中得到了應用。

3. 實驗使用小型基準測試工具在客戶機上進行測試。這些測試工具測試內存訪問，Cache（高速緩存）訪問，整形操作，任務處理等。這些操作上的性能增強能夠提升系統的整體性能，不像是那些專注於測試某種特殊工作負荷（例如Web服務器，內核編譯，圖形渲染等）的宏基準測試工具。

4. 實驗僅使用通用目的操作系統（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種設計分類之一：

1. 完全宏內核設計

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

2. 部分宏內核設計

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

3. 微內核設計

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

2.2 虛擬化模式

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

1. 全虛擬化

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

2. 半虛擬化

   通過提供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個主要組件：

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