如何利用虛擬化技術解決物聯網開發難題？

物聯網市場的應用場景日益複雜，越來越多的上網設備需要支持更多的硬體資源、操作系統、軟體工具及應用程序，現有的解決方案顯然無法為數量龐大的物聯網設備提供相應的靈活性，這使開發者們面臨巨大的設計壓力。虛擬化技術是解決這些問題的關鍵。不過，現有的虛擬化解決方案並不能滿足物聯網開發的輕量級和靈活性的特殊要求。為了滿足當前物聯網市場的發展趨勢，Linux基金會推出了開源項目---ACRN，

ACRN到底具有哪些強大的功能,它又是怎麼實現的?今天我們就從架構到應用對ACRN進行詳細分析，讓開發者們快速上手使用ACRN進行產品設計。

ACRN是一個專為嵌入式設備設計的hypervisor，包括如下兩部分：一套hypervisor的參考軟體和架構，通過虛擬機監視器(Virtual Machine Manager)可以在同一個物理硬體上安全地同時運行多個操作系統。另外，它還為設備虛擬化模擬定義了一套參考設計框架，稱為「ACRN設備模型」。

ACRN hypervisor是一個Type-I的hypervisor，可以直接運行在物理硬體上，適用於各種物聯網和嵌入式設備解決方案。ACRN hypervisor解決了當前數據中心hypervisor和partitioning hypervisor之間存在的差距。ACRN hypervisor設計時把系統分為不同的功能域，並為物聯網和嵌入式設備精心挑選的用戶操作系統進行共享優化。

汽車應用案例

ACRN hypervisor的一個有趣的案例是用於汽車場景。ACRN hypervisor可以用於構建軟體定義駕駛艙(SDC)或者車載娛樂系統(IVE)。作為參考實現，ACRN可以為嵌入式hypervisor廠商的解決方案提供一個很好的基礎，以及一套I/O設備虛擬化的參考設計。

在這種場景下，汽車SDC系統由儀錶盤(IC)系統、車載信息娛樂系統(IVI)和一個或多個后座娛樂系統(RSE)組成。為了整體系統安全性考慮，每個系統都作為獨立的虛擬機運行。

儀錶盤系統(IC)用於顯示和駕駛員相關的車輛的駕駛操作信息，如：

汽車的速度、燃油、行駛里程和其它駕駛信息;

投影在擋風玻璃上的抬頭顯示，用以警告缺油或胎壓報警;

顯示後視攝像頭影像和車身的周邊攝像頭信息，用於輔助停車;

車載娛樂系統(IVI)的功能包括：

導航系統、收音機和其它娛樂系統;

連接到移動設備，可以打電話，播放音樂或者通過語音識別來控制應用程序;

通過手勢識別或觸控進行交互;

后座娛樂系統(RSE)可以運行：

娛樂系統;

虛擬辦公;

連接到前排座椅的IVI系統和移動設備(雲連接);

連接到移動設備，可以打電話，播放音樂或者通過語音識別來控制應用程序;

通過手勢識別或觸控進行交互;

ACRN hypervisor可以支持Linux*和Android*虛擬機作為用戶操作系統(UOS)，UOS由ACRN hypervisor進行管理。開發者和OEM廠商可以在ACRN hypervisor之上運行自己的虛擬機，以及IC、IVI和RSE VM。Service OS是作為VM0運行(在Xen* hypervisor中被稱為Dom0，在KVM* hypervisor中被稱為Host OS)，User OS用戶操作系統作為VM1運行(也被稱為DomU)。

註：Android*虛擬機的支持將在未來版本發布。

圖1顯示了一個使用ACRN hypervisor的實例框圖。

圖1：SOS和UOS運行在ACRN hypervisor之上

從ACRN hypervisor的架構圖中可以看到：

ACRN hypervisor直接位於bootloader之上，因而具備快速啟動的能力;

部分資源進行partitioning，以確保安全關鍵性應用和非安全關鍵業務可以共存在同一平台上;

豐富的I/O設備虛擬化提供在多個VM之間的I/O設備共享，從而提供全面的用戶體驗;

通過高效的虛擬化，一個SoC可以支持多個操作系統同時運行;

圖1中的黃色部分是ACRN項目的軟體棧。該架構框圖中列出的某些功能還沒有完全實現，歡迎社區共同參與開發實現。另外，圖中的其他模塊來自於別的開源項目，這裡僅供參考。

例如，Service OS和Guest Linux來源於https://clearlinux.org上的Clear Linux項目，而未來Guest Android的支持將會來自https://01.org/android-ia項目。

當前ACRN所支持的功能列表，請參照發布說明。

許可證

ACRN hypervisor和ACRN Device Model軟體採用的都是自由許可證的BSD-3-Clause，它允許以「源代碼和二進位再次發布和使用，無論是否進行了修改」， 許可證中也註明了完整版權聲明和免責聲明。

ACRN Device Model, Service OS, and User OS

為了使ACRN hypervisor代碼儘可能精悍且高效，用於實現I/O設備共享的device model代碼運行在Service OS中而非ACRN Hypervisor。哪些I/O設備被共享以及其實現細節將在下面的pass-through章節具體介紹。

Service OS在所有虛擬機里，以最高優先權運行，以滿足那些對時間響應要求很高的需求和系統服務質量的需求(QoS)。具體到Service OS中的任務(task)，他們的優先順序則有高有低。例如響應User OS請求的回調函數，其運行在Service OS的軟體(或者mediator)就會繼承User OS的優先順序。另外，在Service OS中還有一些在後台運行的任務也是低優先順序。

在上述的車載系統示例中，User OS是駕駛控制和車內娛樂的中心樞紐。它能提供收音機和各種娛樂選項、車內空調和通風控制、車輛導航顯示等支持。它可以讓第三方設備使用USB、藍牙或者WiFi等連接技術與車載系統進行交互，例如：Android Auto* 或者 Apple CarPlay*, 還能提供許多其它功能。

啟動步驟

在圖2中，我們展示了在一個採用英特爾架構平台的NUC上使用UEFI驗證啟動的步驟。

Figure 2 ACRN Hypervisor Boot Flow

啟動引導順序執行如下：

1 UEFI驗證和啟動ACRN hypervisor和Service OS的引導載入程序;

2 UFEI(或Service OS的引導載入程序)驗證並啟動Service OS內核;

3 Service OS的內核通過dm-verity驗證並且載入ACRN Device Model和虛擬引導載入程序;

4 虛擬引導載入程序啟動用戶端的驗證啟動進程;

ACRN Hypervisor架構

ACRN hypervisor是Type 1的虛擬機管理程序，能夠直接運行在硬體系統上。它是一個混合的VMM架構，採用一個運行在特權級的Service OS來管理和協調I/O設備的使用。它能支持多個用戶虛擬機，其中每個虛擬機都可以運行Linux或者安卓操作系統作為用戶操作系統。

在虛擬機內運行的操作系統是與其它虛擬機內的系統或應用程序相互隔離的，從而縮小了潛在的被攻擊可能性，最大限度地減小安全隱患。當然由於系統運行在虛擬機內也可能會給其應用程序的運行帶來額外的延遲。

圖3顯示了ACRN hypervisor、車載系統中的Instrumental Cluster (IC) VM和Service VM一起協同工作的架構圖。Service OS(SOS)負責包括平台設備在內的大部分設備的管理，並提供I/O的協調功能。某些PCIe設備可以通過VM配置直通給User OS使用。IC應用程序和虛擬機特定的應用程序都運行在SOS中，例如：ACRN device model和ACRN VM管理器。

ACRN hypervisor內還有ACRN虛機管理器，用來收集User OS的運行信息，並控制用戶虛擬機的開始、停止和暫停，還能暫停或者恢復執行單個虛擬CPU。

圖3 ACRN Hypervisor 架構圖

ACRN hypervisor採用了英特爾虛擬化技術(Intel VT)，其運行在虛擬機擴展模式(VMX)的root模式下，也稱為主機模式或VMM模式。其他所有的用戶虛擬機包括UOS和SOS都運行在VMX non-root模式或guest模式下。(以下為了簡略，我們將繼續使用術語VMM模式和guest模式)。

VMM模式下有4種許可權的ring模式，但ACRN hypervisor僅在ring 0的特權模式下運行，其餘ring 1-3並未使用。運行在guest模式下的用戶系統(包括SOS和UOS)也有自己的4個ring模式(ring 0-3)。用戶系統的內核運行在guest模式下的ring 0，而用戶系統的應用程序則在guest模式下運行於ring 3(ring 1和ring 2一般不被商業操作系統所使用)。

圖4 VMX 簡介

如圖4所示，VMM模式和guest模式通過VM Exit和VM Entry進行切換。當引導載入程序將控制權交給ACRN hypervisor時，處理器還未啟動VMX模式。ACRN hypervisor首先需要通過VMXON指令啟用VMX模式。啟用VMX後，處理器處於VMM模式，它可以通過VM resume指令進入guest模式(或者通過第一次VM launch指令)，然後可以通過處理器的VM exit事件回到VMM模式。一般處理器會在響應某些指令和事件時發生VM exit。

在guest模式下，處理器的執行是由一個虛擬機控制結構(VMCS)所控制的。VMCS包含了虛機狀態(在VM Entry時載入並在VM Exit時保存)，主機狀態(在VM exit時載入)，以及虛機的控制執行。ACRN hypervisor為每個虛擬CPU創建了一個VMCS數據結構，並使用該VMCS來控制運行在guest模式下處理器的行為。

當虛機執行到一個敏感指令時，就會觸發一次定義在VMCS配置中的VM exit事件。當VM exit發生後，系統的控制權就交給了ACRN hypervisor。ACRN hypervisor會模擬虛機的指令(如果VM exit的原因是由於指令許可權問題)，然後恢復虛機繼續執行它的下一條指令，或者根據VM exit的原因進行相關處理(例如，一個虛機的存儲頁面需要建立映射關係)，然後恢復虛機重新執行該條指令。

需要注意的是用於VMM模式的地址空間和用於guest模式的地址空間是不同的。guest模式和VMM模式下使用不同的內存映射表，因此虛機是無法訪問ACRN hypervisor的。ACRN hypervisor使用EPT來映射虛機地址，虛機頁表會將虛機的線性地址映射到虛機的物理地址， EPT表則將虛機的物理地址映射到機器物理地址或主機物理地址(HPA)。

ACRN Device Model Architecture

因為系統設備可能需要在不同的虛機之間被共享，虛機內應用程序(和操作系統)要對這些共享設備進行訪問就需要藉助設備模擬。一般來說，設備模擬有三種架構：

第一種架構被稱為hypervisor中的設備模擬，這是在VMware*工作站產品(一個基於操作系統的hypervisor)中實現的設備模擬方式。在這種方式中，hypervisor負責模擬需要在各個虛機操作系統之間共享的常見設備，其中包括：虛擬磁碟、虛擬網路適配器和其它必要的平台資源。

第二種架構稱為用戶空間的設備模擬。顧名思義，不是將設備模擬的實現嵌入到hypervisor中，而是將其放在一個用戶空間的應用程序中實現。比如被各種獨立的hypervisor所使用的QEMU就提供了此類的設備模擬方式。這種架構的優勢在於設備模擬的實現不依賴於hypervisor，所以其它hypervisor可以重用改實現。甚至它還可以做任意設備的模擬，而不必擔心其功能的實現會影響hypervisor(其在特權模式下運行)。

第三種架構則是從基於hypervisor的設備模擬改變而來的半虛擬化驅動程序。該架構一開始是在XEN項目中引入的，其中hypervisor提供物理設備驅動，每個虛機操作系統則需要安裝一個與能與物理驅動配合使用的hypervisor感知的驅動程序。

在以上討論的設備模擬架構中，共享設備都需要付出代價。因為不管設備模擬是在hypervisor中，還是在每個虛機內的用戶空間中，都存在相應的系統開銷。不過只要系統設備需要被多個虛機操作系統共享，這種開銷就是值得的。反之如果設備不需要被共享，那麼就可以使用更有效的方法來訪問設備，例如使用「直通」。

看完以上的分析，你是否對ACRN有了更深入的了解?也是否有更多問題急需解答? 不用著急，我們將在下期中繼續講解各種技術細節，例如ACRN設備模塊架構、設備pass through， ACRN I/O mediator, Virtio框架結構等一一為你展示。

大家敬請繼續關注～～

--end--

喜歡這篇文章嗎？立刻分享出去讓更多人知道吧！