虛擬化（Virtualization）這種起源于上世紀60年代IBM大型機系統(tǒng)的技術(shù)在處理器性能大幅度提升的當(dāng)下赏迟，再次迅速發(fā)展起來甩栈，并從最初的的裸機虛擬化（Type-I虛擬化）技術(shù)開始，演化出主機虛擬化（Type-II虛擬化）、混合虛擬化（Hybrid虛擬化）等更復(fù)雜的虛擬化模型，并在此基礎(chǔ)山發(fā)展出了當(dāng)下最熱門的云計算技術(shù)稽荧，極大地降低了IT成本，增強了系統(tǒng)的安全性，可靠性和擴展性。

嵌入式系統(tǒng)則是虛擬化技術(shù)在嵌入式領(lǐng)域的應(yīng)用矾飞。文中的Xvisor正是一款開源的采用裸機虛擬化技術(shù)的輕量級嵌入式Hypervisor价淌，具有良好的代碼架構(gòu)和和可移植性蝉衣，支持ARM和X86處理器的半虛擬化和基于硬件的全虛擬化技術(shù)。

文中圍繞嵌入式Hypervisor的5個核心部分 - 客戶機IO事件模擬有送、主機中斷、 鎖同步延遲涯塔、內(nèi)存管理和內(nèi)存占用匕荸，基于當(dāng)下最流行的ARM處理器架構(gòu)，進行了深入的闡述和對比枷邪。

本文翻譯自Embedded Hypervisor Xvisor: A Comparative Analysis每聪。譯者在翻譯時盡量逐詞翻譯，但是某些語句為了更清楚的表述根據(jù)譯者的理解進行了轉(zhuǎn)述齿风。若有不妥绑洛，請參考原文救斑。

• 摘要
• 1. 介紹
• 2. 虛擬化技術(shù)分類
  • 2.1 Hypervisor設(shè)計
  • 2.2 虛擬化模式
• 3. 嵌入式系統(tǒng)的開源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. 內(nèi)存管理
  • 7.1 Xen ARM
  • 7.2 KVM ARM
  • 7.3 Xvisor ARM
• 8. 內(nèi)存占用比較
• 9. 基準(zhǔn)測試程序
  • 9.1 Dhrystone
  • 9.2 Cachebench
  • 9.3 Stream
  • 9.4 Hackbench
• 10. 實驗
• 11. 結(jié)論
• 參考文獻

摘要

由于與減少費用、提高資源利用率和更高的性能直接相關(guān)真屯，虛擬化技術(shù)已經(jīng)在嵌入式系統(tǒng)中廣泛流行脸候。為了在嵌入式系統(tǒng)的嚴格時間約束和低內(nèi)存占用的虛擬化環(huán)境中獲得高效的性能，我們需要高效的Hypervisor（虛擬機管理器）绑蔫。雖然現(xiàn)在已經(jīng)有了一些開源的Hypervisor运沦，例如Xen，Linux KVM和OKL4 Microvisor配深，這仍然是第一篇介紹開源嵌入式虛擬機管理器Xvisor(eXtensible Versatile hypervisor)携添，并從對整個系統(tǒng)性能的影響上，與兩個常用虛擬機管理器KVM和Xen進行對比的論文篓叶。實驗證明烈掠，在ARM處理器架構(gòu)上，Xvisor具有更低的CPU開銷缸托，更高的內(nèi)存帶寬左敌，更低的鎖同步延遲和虛擬定時器中斷開銷，并且能夠全面提升嵌入式系統(tǒng)性能俐镐。

關(guān)鍵詞：嵌入式系統(tǒng); 虛擬化; Xen, Linux KVM; Xvisor矫限；ARM；Hypervisor（虛擬機管理器）；

1. 介紹

近年來叼风，多核嵌入式系統(tǒng)需求的增長已經(jīng)開始引領(lǐng)虛擬化技術(shù)在嵌入式系統(tǒng)中的研究取董。嵌入式系統(tǒng)通常具有資源有限，實時性約束咬扇，高性能要求甲葬，增長的應(yīng)用程序棧需求（必須使用有限外設(shè)）等特點[參考文獻1]。

虛擬化技術(shù)提供了在單核或多核處理器上以虛擬機（VM或客戶機）方式運行多個操作系統(tǒng)的方法懈贺。每個客戶機運行在一個或多個虛擬處理單元（vCPU）上经窖。進而，一個客戶機的所有vCPU（虛擬CPU）同另外一個客戶機的vCPU完全隔離梭灿，但是共享同一套外設(shè)画侣。

因此，虛擬化的應(yīng)用提供了如下優(yōu)勢[參考文獻2]：

1. 過去運行在不同設(shè)備上的服務(wù)現(xiàn)在可以作為多個VM運行在同一個設(shè)備上堡妒；
2. 在同一個設(shè)備上合并操作系統(tǒng)的實時特性和通用目的特性配乱，即在不同的VM中執(zhí)行實時程序和通用程序[參考文獻3]；
3. 更好的容錯性皮迟；
4. 提供高可靠應(yīng)用間的隔離性搬泥。

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

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

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

1. 本次研究基于ARM架構(gòu)吱韭。這是由于最新的ARM處理器架構(gòu)已經(jīng)提供了硬件虛擬化擴展，并且ARM處理器在嵌入式系統(tǒng)中已經(jīng)得到了廣泛應(yīng)用鱼的。另外杉女，這3個Hypervisor共有的的大部分板級支持包（BSP）都使用了ARM架構(gòu)處理器。

2. KVM和Xen被選中作為對比的虛擬機管理器鸳吸，是基于如下原因：

   • ARM架構(gòu)支持[參考文獻7,8];
   • 允許我們沒有任何限制的收集性能數(shù)據(jù)的開源特性[參考文獻9]熏挎；
   • 與Xvisor支持同樣的單板；
   • 在嵌入式系統(tǒng)中得到了應(yīng)用晌砾。

3. 實驗使用小型基準(zhǔn)測試工具在客戶機上進行測試坎拐。這些測試工具測試內(nèi)存訪問，Cache（高速緩存）訪問，整形操作哼勇，任務(wù)處理等都伪。這些操作上的性能增強能夠提升系統(tǒng)的整體性能，不像是那些專注于測試某種特殊工作負荷（例如Web服務(wù)器积担，內(nèi)核編譯陨晶，圖形渲染等）的宏基準(zhǔn)測試工具。

4. 實驗僅使用通用目的操作系統(tǒng)（GPOS）Linux作為客戶機帝璧。因為先誉，這是唯一可被這3種Hypervisor支持的客戶機操作系統(tǒng)。目前沒有一個通用的實時操作系統(tǒng)可以同時為這3種ypervisor所支持的烁。因此時間約束測試將通過如下因素的吞吐量測試來實施：

   • Hypervisor的低內(nèi)存和CPU開銷褐耳；
   • Hypervisor最小負荷情況下的客戶機調(diào)度效率。

Xen渴庆，KVM和Xvisor實現(xiàn)的說明和限制的討論如下所示：

• 本文第2章解釋了虛擬化技術(shù)的分類铃芦；
• 本文第3章介紹了Xvisor并提供一個開源虛擬機管理器Xen和KVM的概況。影響到對比因素的主要組件的實現(xiàn)細節(jié)的解釋在后續(xù)章節(jié)中會被顯著說明襟雷。后續(xù)章節(jié)將包括一個基于ARM處理器架構(gòu)的上述3種Hypervisor的對比分析[參考文獻10]刃滓。
• 我們在第4講述客戶機IO模擬，而在第5耸弄，6注盈，7，8章講述主機中斷處理叙赚，鎖同步機制，內(nèi)存管理和內(nèi)存占用僚饭。
• 我們分析測試時用到的應(yīng)用程序基準(zhǔn)測試程序的簡單說明放在第9章震叮，測試結(jié)果放在隨后的第10章，而結(jié)論則放在文末鳍鸵。

2. 虛擬化技術(shù)分類

基于如下兩個特征[參考文獻11]苇瓣，我們把虛擬化技術(shù)劃分為5類：

• Hypervisor設(shè)計；
• 圖1所示的虛擬化模式偿乖。

相應(yīng)的击罪，虛擬化技術(shù)分類在通過客戶機獲取的性能測量中扮演著重要角色。

2.1 Hypervisor設(shè)計

Hypervisor的角色是硬件和虛擬機之間的接口贪薪。這些Hypervisor的實現(xiàn)風(fēng)格決定了他們作為虛擬化管理器的操作效率媳禁。給予他們的實現(xiàn)，所有Hypervisor都屬于下面3種設(shè)計分類之一：

1. 完全宏內(nèi)核設(shè)計

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

2. 部分宏內(nèi)核設(shè)計

   部分宏內(nèi)核Hypervisor通常是一個通用目的宏內(nèi)核操作系統(tǒng)（例如Linux，F(xiàn)reeBSD毫别，NETBSD娃弓，Windows等）的擴展。他們在操作系統(tǒng)內(nèi)核支持主機硬件訪問和CPU虛擬化岛宦，并通過用戶空間軟件支持客戶機IO模擬台丛。例如Linux KVM和VMware Workstation[參考文獻13]。

3. 微內(nèi)核設(shè)計

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

2.2 虛擬化模式

虛擬化模式?jīng)Q定了能夠在Hypervisor上運行的客戶機的類型[參考文獻17硅蹦，18]：

1. 全虛擬化

   通過提供系統(tǒng)虛擬機（例如模擬類似于真實硬件的整個系統(tǒng)），允許未經(jīng)修改的客戶機操作系統(tǒng)作為客戶機運行闷煤。（譯者注：該模式需要借助硬件的虛擬化支持童芹，例如X86架構(gòu)AMD-V/Intel VT，ARMv8和Power架構(gòu)的虛擬化profile等鲤拿。）

2. 半虛擬化

   通過提供Hypercall（虛擬機調(diào)用接口）假褪，允許修改過的的客戶機操作系統(tǒng)作為客戶機運行。這個模式要求客戶機使用Hypercall來進行各種IO操作（例如近顷，網(wǎng)絡(luò)收發(fā)生音，塊讀寫，終端讀寫等等）和在某些時候執(zhí)行某些關(guān)鍵指令窒升。這些Hypercall會觸發(fā)一個trap（陷阱）中斷以進入Hypervisor缀遍。這些trap中斷基于Hypercall參數(shù)，使得Hypervisor為客戶機提供期待的服務(wù)饱须。

3. 嵌入式系統(tǒng)的開源Hypervisor

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

由于我們研究中對性能比較的關(guān)系蓉媳，我們講述了這些Hypervisor中已知的招致客戶機運行并由此影響整個虛擬化嵌入式系統(tǒng)性能的系統(tǒng)組件的實現(xiàn)細節(jié)譬挚。這包括每個Hypervisor如何處理CPU虛擬化，客戶機IO模擬和主機硬件訪問酪呻。另外减宣，每個Hypervisor的某些主要優(yōu)勢也會被提及。

2.1 XEN

如圖2所示玩荠，Xen Hypervisor是一個支持全虛擬化和半虛擬化客戶機的微內(nèi)核Hypervisor蚪腋。Xen Hypervisor內(nèi)核是一個輕量級微內(nèi)核丰歌，提供：

• CPU虛擬化；
• MMU虛擬化：
• 虛擬中斷處理屉凯；
• 客戶機間通訊[參考文獻19]立帖。

Domain（域）是Xen內(nèi)核相應(yīng)于虛擬機或客戶機的概念。

Domain0（Dom0）是一個特殊類型的域悠砚，運行著一個Linux內(nèi)核的修改版本晓勇。Dommain0必須運行在一個比任何其他VM或客戶機更高的優(yōu)先級上，并且具有對主機硬件的完全訪問權(quán)限灌旧。Dom0的主要目的是利用Linux內(nèi)核提供IO虛擬化和客戶機管理服務(wù)绑咱。

DomainU（DomU）相應(yīng)于運行著一個客戶機操作系統(tǒng)的客戶虛擬機∈嗵客戶機的IO事件模擬和半虛擬化通過DomU和Dom0之間的通訊來實現(xiàn)描融。這一目的通過使用Xen事件通道來完成。半虛擬化客戶機衡蚂，相應(yīng)于DomU PVM窿克，使用Xen事件通道來訪問Dom0半虛擬化IO服務(wù)∶祝可是年叮，全虛擬化客戶機，相應(yīng)于DomU HVM玻募，使用運行在Dom0用戶空間中的QEMU來模擬客戶機IO事件只损。

所有用來管理客戶機或域的用戶接口都通過運行在Dom0用戶控件的Xen工具棧來完成。沒有Dom0七咧，Xen不能提供DomU PVM或者DomU HVM跃惫。

Xen最重要的優(yōu)勢是使用Linux內(nèi)核作為Dom0，因為這能幫助Xen重用Linux內(nèi)核現(xiàn)有的設(shè)備驅(qū)動和其他部分艾栋”妫可是，這個優(yōu)勢帶來了后面章節(jié)將會提到的額外代價裹粤。也就是說，作為Dom0運行的Linux內(nèi)核比直接運行在真實硬件上（沒有Xen）稍微慢了一點蜂林。這是因為遥诉，Dom0只是Xen的另一個域，有它自己的嵌套頁表噪叙，并且可能被Xen調(diào)度器調(diào)度出去矮锈。

2.2 KVM

KVM(基于內(nèi)核的虛擬機)是一個支持全虛擬化和半虛擬化技術(shù)的部分宏內(nèi)核Hypervisor。KVM主要提供全虛擬化客戶機睁蕾，并以可選的VirtIO設(shè)備[參考文獻20]的形式提供半虛擬化支持苞笨。

如圖2所示寥枝，KVM包含2個主要組件：

1. 內(nèi)核空間字符設(shè)備驅(qū)動宪塔，通過一個字符設(shè)備文件/dev/kvm提供CPU虛擬化服務(wù)和內(nèi)存虛擬化服務(wù)；
2. 提供客戶機硬件模擬的用戶空間模擬器（通常是QEMU）囊拜。

與這兩個組件之間的服務(wù)請求通訊某筐，例如虛擬機和vCPU的創(chuàng)建，通常通過/dev/kvm設(shè)備文件的IOCTRL操作來處理冠跷。

KVM最重要的優(yōu)勢（類似于Xen）是使用Linux內(nèi)核作為主機內(nèi)核南誊。這樣有助于KVM重用Linux內(nèi)核現(xiàn)有的設(shè)備驅(qū)動和其他部分。然而蔽莱，由于KVM依賴于嵌套頁表故障機制的客戶機模式到主機模式的虛擬機切換弟疆，特殊指令陷阱（Trap），主機中斷盗冷，客戶機IO事件怠苔，和另一個從主機模式喚醒客戶機執(zhí)行的虛擬機切換，這個優(yōu)勢也導(dǎo)致了KVM整體性能本質(zhì)上的降低仪糖。

2.3 Xvisor

圖4中的Xvisor是一個支持全虛擬化和半虛擬化技術(shù)的完全宏內(nèi)核Hypervisor柑司。它的目的是提供一個僅需少量系統(tǒng)開銷和很小內(nèi)存占用的在嵌入式系統(tǒng)中使用的輕量級Hypervisor。Xvisor主要提供全虛擬化客戶機锅劝，并以VirtIO設(shè)備[參考文獻20]的形式提供半虛擬化支持攒驰。

Xvisor的所有核心組件，例如CPU虛擬化故爵，客戶機IO模擬玻粪，后端線程，半虛擬化服務(wù)诬垂，管理服務(wù)和設(shè)備驅(qū)動劲室，都作為一個獨立的軟件層運行，不需要任何必備的工具或者二進制文件结窘。

客戶機操作系統(tǒng)運行在Xvisor上很洋，具有更少的特權(quán)；而Xvisor的實現(xiàn)負責(zé)調(diào)用標(biāo)準(zhǔn)vCPU纱皆。此外，所有設(shè)備驅(qū)動和管理功能的后端處理運行在不具有最高優(yōu)先級的孤兒vCPU（沒有分配給某個客戶機的vCPU）上岸浑≡鹁玻客戶機配置信息以設(shè)備樹(Device Tree)[參考文獻21]的形式維護塑荒。這種方式通過使用設(shè)備樹腳本（DTS），使得客戶機硬件信息的維護更加容易仆葡。換句話說韧掩，為嵌入式系統(tǒng)定制一個虛擬機時不需要修改代碼箍铲。

Xvisor最重要的優(yōu)勢是運行在提供所有虛擬化相關(guān)服務(wù)的最高特權(quán)等級上的單一軟件層聋庵。不像KVM，Xvisor的上下文切換非常輕量級（參見第5章）芙粱，因此嵌套頁表祭玉、特殊指令陷阱、主機中斷和客戶機IO事件等的處理也非炒号希快速脱货。進而，所有設(shè)備驅(qū)動都作為Xvisor的一部分直接運行律姨，具有完全的特權(quán)并且沒有嵌套頁表振峻，以確保不會出現(xiàn)性能退化。另外择份，Xvisor的vCPU調(diào)度器是基于單CPU的扣孟，不處理多核系統(tǒng)的負載均衡。在Xvisor中荣赶，多核系統(tǒng)的負載均衡器是一個分離的部分凤价，獨立于vCPU調(diào)度器（不像KVM和XEN）鸽斟。在Xvisor中，vCPU調(diào)度器和負載均衡器都是可擴展的利诺。

Xvisor唯一的限制是缺少Linux那樣豐富的單板和設(shè)備驅(qū)動富蓄。為了處理這個限制，Xvisor提供了Linux兼容層頭文件以方便從Linux內(nèi)核移植設(shè)備驅(qū)動框架和設(shè)備驅(qū)動慢逾。盡管不能完全解決問題立倍，移植成本也可以大幅度減少。

4. 客戶機IO事件模擬

嵌入式系統(tǒng)需要作為虛擬機（VM）或客戶機運行傳統(tǒng)軟件侣滩。傳統(tǒng)嵌入式軟件可能期待需要Hypervisor模擬的特殊硬件口注。這就是為什么Hypervisor必須盡可能減小客戶機IO事件模擬的開銷。后面的小章節(jié)解釋了前面提及的Hypervisor在ARM處理器架構(gòu)上模擬的客戶機IO事件的生命周期君珠。注意疆导，這非常重要。因為在這些Hypervisor中葛躏，客戶機IO事件流在所有處理器架構(gòu)包括ARM上都是相同的澈段。

4.1 Xen ARM

圖5展示了Xen ARM用于DomU HVM（全虛擬化客戶機）的客戶機IO事件模擬的生命周期。從標(biāo)志1開始舰攒，一個客戶機IO事件被觸發(fā)败富，然后使用標(biāo)志2和標(biāo)志3所示的Xen事件通道轉(zhuǎn)發(fā)到Dom0內(nèi)核。隨后摩窃，運行在Dom0用戶空間的QEMU在標(biāo)志4模擬客戶機IO事件兽叮。最后在標(biāo)志5，控制返回到DomU猾愿。

圖中所示流程導(dǎo)致了一定數(shù)目的開銷鹦聪。首先，盡管已經(jīng)進行過優(yōu)化蒂秘，基于域間通信的Xen事件通道還是具有非零開銷泽本。其次，Dom0內(nèi)核到用戶空間和相反方向的上下文切換增加了客戶機IO事件模擬的開銷姻僧。

4.2 KVM ARM

圖6展示了客戶機IO事件模擬在KVM ARM上的處理流程规丽。圖中場景開始在標(biāo)志1，即一個客戶機IO事件被觸發(fā)的時刻撇贺《妮海客戶機IO事件引起一個VM-Exit事件，引起KVM從客戶機模式切換到主機模式松嘶。然后艘狭，如標(biāo)志2和3所示，客戶機IO事件被運行在用戶空間的QEMU處理。最后巢音，在標(biāo)志4處鼓鲁，VM-enter發(fā)生，引起KVM從主機模式切換到客戶機模式港谊。

處理開銷主要由VM-exit和Vm-ente上下文切換引起，而這正是KVM眾所周知的嚴重開銷橙弱。

4.3 Xvisor ARM

不像其他Hypervisor歧寺，Xvisor ARM在客戶機IO事件模擬上不會引發(fā)額外的調(diào)度或者上下文切換的開銷。如圖7所示棘脐，流程開始在標(biāo)志1斜筐，一個客戶機IO事件被Xvisor ARM捕獲時。隨后蛀缝，事件在標(biāo)志2處的不可睡眠的通用上下文中被處理以確保時間被處理顷链，并具有預(yù)期的開銷。

5. 主機中斷

嵌入式系統(tǒng)在處理主機中斷時屈梁，必須遵守嚴格的時間約束嗤练。在虛擬化環(huán)境中，Hypervisor在處理主機中斷時可能會有額外的開銷在讶，轉(zhuǎn)而影響主機IO性能煞抬。請重點注意，文中所述的Hypervisor的主機中斷處理流程對所有處理器架構(gòu)包括ARM都是相同的构哺。

5.1 Xen ARM

在Xen中革答，主機設(shè)備驅(qū)動作為Dom0 Linux內(nèi)核的一部分運行。因此所有主機中斷都被轉(zhuǎn)發(fā)到Dom0曙强。如圖8所示残拐，流程開始在標(biāo)志1，一個主機IRQ（中斷請求）被觸發(fā)碟嘴，然后在標(biāo)志2處被轉(zhuǎn)發(fā)到Dom0溪食。如圖中標(biāo)志3和4所示，所有主機中斷由Dom0處理娜扇。如果一個主機中斷在DomU運行時被觸發(fā)眠菇，那么它將在Dom0被調(diào)度進來后才能得到處理，因此主機中斷處理引發(fā)了調(diào)度開銷袱衷。

5.2 KVM ARM

圖9所示為KVM ARM上客戶機正在運行時的主機中斷處理流程[參考文獻22]捎废。如圖中標(biāo)志1所示，每個主機中斷觸發(fā)一個VM-exit致燥。一旦中斷如圖中標(biāo)志2和3所示登疗，被主機內(nèi)核處理，KVM通過標(biāo)志4處的VM-entry恢復(fù)客戶機。當(dāng)某個KVM客戶機處于運行狀態(tài)時辐益，VM-exit和VM-entry增加了相當(dāng)大的主機中斷處理開銷断傲。進而，如果主機中斷被轉(zhuǎn)發(fā)到KVM客戶機智政，那么調(diào)度開銷也會存在认罩。

5.3 Xvisor ARM

Xvisor的主機設(shè)備驅(qū)動通常作為Xvisor的一部分以最高權(quán)限運行。因此续捂，圖10中垦垂，處理主機中斷時是不需要引發(fā)調(diào)度和上下文切換開銷的。只有當(dāng)主機中斷被轉(zhuǎn)發(fā)到一個當(dāng)前沒有運行的客戶機時牙瓢，才會引發(fā)調(diào)度開銷劫拗。

6. 鎖同步延遲

在虛擬化環(huán)境中烹玉，鎖同步延遲問題是[參考文獻23]中提到的一個眾所周知的問題虫给。這個問題因如下2個調(diào)度器的存在而產(chǎn)生：

• Hypervisor調(diào)度器
• 客戶機OS調(diào)度器

這里竣况，兩個調(diào)度器互相意識不到對方置侍，導(dǎo)致客戶機vCPU被Hypervisor隨意搶占厉颤。我們給出了一個關(guān)于這種延遲和所有3個Hypervisor如何處理它們的一個簡要介紹转唉。

同一個客戶機中vCPU之間鎖同步的低效處理導(dǎo)致了圖11和12中顯示的兩個不確定場景：vCPU搶占和vCPU堆積問題孽惰。兩種問題都可能導(dǎo)致在獲取同一個客戶機的vCPU鎖時增加等待時間轨淌。

當(dāng)一個運行在持有鎖的某主機CPU（pCPU0）上的vCPU（vCPU0）被搶占控妻，而同時另一個運行在其他主機CPU（pCPU1）上的vCPU（vCPU1）正在等待這個鎖欲逃，那么vCPU搶占問題就會發(fā)生。另外饼暑，發(fā)生在一個運行著多個vCPU的單主機CPU上的鎖調(diào)度沖突問題也會導(dǎo)致vCPU堆積問題發(fā)生稳析。也就是說，希望獲取某個鎖的vCPU（vCPU1）搶占了運行在同一個主機CPU上的vCPU（vCPU0）弓叛，但是vCPU0正在持有這個鎖彰居。

在ARM機構(gòu)上，操作系統(tǒng)典型的使用WFE（等待事件）指令來等待請求一個鎖撰筷，并使用SEV（發(fā)送事件）指令來釋放一個鎖陈惰。ARM架構(gòu)允許WFE指令被Hypervisor捕獲，但是SEV指令不能被捕獲毕籽。為了解決vCPU堆積問題抬闯，所有3種Hypervisor（Xen ARM，KVM ARM和Xvisor ARM）都使用捕獲WFE指令的方法使得vCPU讓出時間片关筒。ARM架構(gòu)的vCPU搶占問題能夠通過使用半虛擬化鎖的方式來解決溶握，但是需要對客戶機操作系統(tǒng)進行源碼級的修改。

7. 內(nèi)存管理

嵌入式系統(tǒng)要求有效的內(nèi)存處理蒸播。對于嵌入式Hypervisor來說睡榆，內(nèi)存管理的開銷需要慎重考慮萍肆。ARM架構(gòu)提供2級翻譯表（或者說嵌套頁表），用于客戶機內(nèi)存虛擬化,即圖13所示的2階段MMU胀屿√链В客戶機操作系統(tǒng)負責(zé)編程第1階段頁表，將客戶機虛擬地址(GVA)翻譯到間接物理地址（IPA）宿崭。ARM Hypervisor負責(zé)編程第2階段頁表來從將間接物理地址（IPA）翻譯成實際物理地址（PA）亲铡。

TLB-miss（Translation Look-aside Buffers miss，即頁表緩沖缺失）時必須檢索翻譯表葡兑。這個過程中使用的第2階段頁表的級數(shù)影響內(nèi)存帶寬和虛擬化系統(tǒng)的整體性能奖蔓。比如最糟糕的情況下，N級第1階段翻譯表和M級第2階段翻譯表需要NxM次內(nèi)存訪問铁孵。對任何虛擬化系統(tǒng)上的客戶機來說，TLB-miss損失都是非常昂貴的房资。為了減少2階段MMU中的TLB-miss損失蜕劝，ARM Hypervisor在第2階段創(chuàng)建更大的頁。

7.1 Xen ARM

Xen ARM為每個客戶機或域（Dom0或DomU）創(chuàng)建一個獨立的3級第2階段翻譯表轰异。Xen ARM能創(chuàng)建4K字節(jié)岖沛，2M字節(jié)或1G字節(jié)的第2階段翻譯表項。Xen ARM也按需分配客戶機內(nèi)存搭独，并試圖基于IPA和PA對齊構(gòu)造盡可能最大的第2階段翻譯表項婴削。

7.2 KVM ARM

KVM用戶空間工具（QEMU）預(yù)先分配作為客戶機RAM使用的用戶空間內(nèi)存，并向KVM內(nèi)核模塊通知其位置牙肝。KVM內(nèi)核模塊為每個客戶機vCPU創(chuàng)建一個獨立的3級第2階段翻譯表唉俗。典型的，KVM ARM將創(chuàng)建4K字節(jié)大小的第2階段翻譯表項配椭，但是也能夠使用巨大化TLB優(yōu)化模式創(chuàng)建2M字節(jié)大小的第2階段翻譯表項虫溜。

7.3 Xvisor ARM

Xvisor ARM在客戶機創(chuàng)建時，預(yù)先分配連續(xù)的主機內(nèi)存以做為客戶機RAM股缸。它為每個客戶機創(chuàng)建一個獨立的3級第2階段翻譯表衡楞。Xvisor ARM能創(chuàng)建4K字節(jié)，2M字節(jié)或1G字節(jié)的第2階段翻譯表項敦姻。另外瘾境，Xvisor ARM總是基于IPA和PA對齊創(chuàng)建盡可能最大的第2階段翻譯表項。最后镰惦，客戶機RAM是扁平化和連續(xù)的（不像其它Hypervisor）迷守。這有助于緩存預(yù)取訪問，從而進一步提升客戶機內(nèi)存訪問性能旺入。

8. 內(nèi)存占用比較

嵌入式系統(tǒng)要求小內(nèi)存占用（[參考文獻[24]）盒犹。下表I，II和III顯示Cubieboard2（[參考文獻[25]）上的安裝需求和最小內(nèi)存占用。因此后面問題答復(fù)如下：

1. 需要滿足什么條件才能使Xen ARM急膀，KVM ARM和Xvisor ARM運行在系統(tǒng)上沮协？
2. Xen ARM，KVM ARM和Xvisor ARM需要消耗的的最小內(nèi)存是多少卓嫂？

上圖中：

• a) Xen工具棧與其它依賴庫單獨安裝慷暂。這個工具棧允許用戶管理虛擬機創(chuàng)建、銷毀和配置晨雳。它可以通過命令行終端和圖形接口使用（[參考文獻[10]）行瑞。

• b) Xen保留大量內(nèi)存，用于事件通道餐禁。

  
  
  
  
  
  

  上圖中：

• c) Xvisor內(nèi)核在單個二進制文件中包含完整的虛擬化功能血久，并且隨著更多新特性的增加從而增長到2~3M字節(jié)；
• d) Xvisor使用編譯選項來限制自己的內(nèi)存占用帮非，ARM架構(gòu)默認設(shè)置為16M字節(jié)氧吐。

9. 基準(zhǔn)測試程序

我們實驗中使用的基準(zhǔn)測試程序?qū)Ｗ⒂趶腃PU開銷、內(nèi)存帶寬和鎖同步機制方面比較Hypervisor末盔。

9.1 Dhrystone

Dhrystone是一個用于測量處理器整形性能的簡單基準(zhǔn)測試（[參考文獻[26]）筑舅。Dhrystone基準(zhǔn)測試的每秒總迭代次數(shù)被稱為每秒Dhrystones。進而陨舱，Dhrystone結(jié)果的另外一個表示是DMIPS（每秒百萬條Dhrystone指令數(shù)）翠拣，也就是每秒Dhrystones除以1757。DMIPS只不過是與VAX 11/780游盲，误墓，典型的1 MIPS機器（[參考文獻[27]）進行比較的計算機系統(tǒng)的性能。

9.2 Cachebench

Cachebench來評估計算機系統(tǒng)內(nèi)存體系的性能益缎。它專注于把處理器內(nèi)外的高速緩存的多個級別參數(shù)化优烧。Cachebench進行不同緩沖區(qū)大小的測試：內(nèi)存設(shè)置、內(nèi)存復(fù)制链峭、整數(shù)讀取畦娄，整數(shù)寫入和整數(shù)讀取-修改-寫入。對于我們的實驗弊仪，我們將生成以兆字節(jié)每秒為單位的內(nèi)存復(fù)制和整數(shù)讀取-修改-寫入測試的結(jié)果熙卡。

9.3 Stream

內(nèi)存帶寬已經(jīng)被認為能夠影響系統(tǒng)性能（[參考文獻[29]）。STREAM是一個設(shè)計用來測量持續(xù)內(nèi)存帶寬（以兆字節(jié)每秒為單位）的簡單復(fù)合基準(zhǔn)測試程序励饵。STREAM基準(zhǔn)測試被明確的設(shè)計在任何系統(tǒng)的非常大的數(shù)據(jù)集合上工作驳癌，而不是可用的高速緩沖上。我們實驗中使用的STREAM版本是v5.10役听，2000000數(shù)組大型窍省（大約45.8M字節(jié)）

9.4 Hackbench

Hackbench通過確定調(diào)度給定數(shù)目任務(wù)花費的時間來測量系統(tǒng)調(diào)度器性能表窘。Hackbench的主要工作是調(diào)度線程和進程。調(diào)度實體通過套接字或管道收發(fā)數(shù)據(jù)來通訊甜滨。運行測試程序時能夠?qū)?shù)據(jù)大小和消息數(shù)目進行設(shè)置乐严。

10. 實驗

后面的實驗?zāi)康脑谟谠u估近期提議的嵌入式Hypervisor - Xvisor相較KVM和Xen的效率。本文試圖在Cubieboard2（[參考文獻[25]）上的客戶機Linux上運行4個基準(zhǔn)測試程序衣摩。Cubieboard2是一塊包含1GB RAM的ARM Cortex-A7雙核1GHz單板昂验。試驗中使用了如下Hypervisor版本：

1. KVM: 最新的Linux-3.16-rc3被用作主機KVM內(nèi)核“纾客戶機內(nèi)核是Linux-3.16-rc3既琴。
2. Xen：2014年8月3日發(fā)布的最新的Xen-4.5-unstable內(nèi)核被用作Hypervisor。Dom0內(nèi)核和DomU均為Linux-3.16-rc3泡嘴。
3. Xvisor：2014年7月18日發(fā)布的最新的Xvisor-0.2.4+被用作Hypervisor甫恩。客戶機內(nèi)核是Linux-3.16-rc3酌予。

實驗結(jié)果通過兩個測試向量獲取磺箕。第一個運行在一個單核上，而另一個運行在一個雙核上霎终。測試系統(tǒng)（SUT滞磺，systems under test）如下：

1. 沒有任何Hypervisor的主機升薯；
2. Xvisor客戶機莱褒；
3. KVM客戶機；
4. HugeTLB模式KVM客戶機涎劈；
5. Xen客戶機广凸。

為了確保只有CPU開銷，內(nèi)存帶寬和鎖同步延遲被引入測試結(jié)果蛛枚，兩個測試向量都有一個具有2個vCPU的半虛擬化客戶機谅海。而且，所有Hypervisor都進行了如下優(yōu)化：

• 沒有來自于通用中斷控制器的維護中斷蹦浦；
• Xen ARM超級頁支持扭吁；
• WFE指令捕獲-出讓vCPU機制。

表IV和V顯示以DMIPS為單位的Dhrystone結(jié)果盲镶。Xvisor客戶機的DMIPS比KVM客戶機高大約0.2%侥袜，比HugeTLB模式KVM客戶機高0.19%，比Xen DomU高0.46%溉贿。Dhrystone基準(zhǔn)測試很小枫吧，在運行時幾乎可以放在高速緩存中，因此內(nèi)存訪問開銷不會對其產(chǎn)生影響宇色。盡管只有2個DMIPS的提升九杂，這仍然提升了整個系統(tǒng)性能颁湖，因為1個DMIPS等于每秒1757次迭代。所以例隆，使肌體上將是每秒數(shù)千次迭代（通常是幾百萬條機器指令）甥捺。

表VI, VII, VIII和IX顯示內(nèi)存復(fù)制和整數(shù)讀取-修改-寫入兩種操作的Cachebench結(jié)果。Xvisor客戶機的內(nèi)存復(fù)制結(jié)果比KVM客戶機高大約18%裳擎，比HugeTLB模式KVM客戶機高1.2%涎永，比Xen DomU高0.67%。Xvisor客戶機的整數(shù)讀取-修改-寫入結(jié)果也比KVM客戶機高大約1.14%鹿响，比HugeTLB模式KVM客戶機高1.2%羡微，比Xen DomU高1.64%。

表X和XI顯示Xvisor客戶機的持續(xù)性內(nèi)存帶寬比KVM客戶機高大約0.72%惶我，比HugeTLB模式KVM客戶機高1.57%妈倔，比Xen DomU高1.2%。

表XII和XIII中的Hackbench結(jié)果顯示示Xvisor客戶機的任務(wù)分發(fā)延遲比KVM客戶機低大約12.5%绸贡，比HugeTLB模式KVM客戶機低5.62%盯蝴，比Xen DomU低6.39%。

11. 結(jié)論

這篇論文介紹了作為開源Hypervisor - Xen和KVM性能缺點解決方案的新嵌入式Hypervisor - Xvisor听怕。Xvisor的實現(xiàn)優(yōu)點體現(xiàn)在如下幾個方面：

• 客戶機IO模擬;
• 主機中斷處理捧挺；
• 鎖同步延遲；
• 內(nèi)存占用尿瞭；
• 內(nèi)存管理闽烙。

而且，4種不同基礎(chǔ)準(zhǔn)測試的顯示結(jié)果支撐了Xvisor的實現(xiàn)優(yōu)勢声搁。

實驗結(jié)果顯示Dhrystone黑竞，Cachebench和Stream基準(zhǔn)測試在Xvisor ARM客戶機上具有更高的速率。這證明Xvisor ARM客戶機具有相對于KVM ARM客戶機和Xen ARM DomU更低的CPU開銷和更高的內(nèi)存帶寬疏旨。進而很魂，Hackbench在Xvisor ARM客戶機上具有更少的執(zhí)行時間。這說明Xvisor ARM客戶機具有相對于KVM ARM客戶機和Xen ARM DomU更低的鎖同步延遲和虛擬定時器中斷開銷檐涝。這些結(jié)果意味著Xvisor ARM下的客戶機相對于KVM ARM和Xen ARM更接近原生性能遏匆。最后， Xvisor ARM更小的內(nèi)存占用允許它在嵌入式系統(tǒng)上更有效的利用有限的內(nèi)存谁榜。

Xvisor允許額外的板級支持包（BSP）幅聘。更多的多核體驗（不止是雙核）也是可能的。而且惰爬，基于上述測量數(shù)據(jù)已經(jīng)證明的性能提升喊暖，Xvisor將來在網(wǎng)絡(luò)和存儲虛擬化方面的實現(xiàn)也能具有更好的性能。

參考文獻

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](http://infocenter.arm.com/help/topic/com.arm.doc.ddi0406c/index.
    html)
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