物聯網市場的應用場景日益復雜，越來越多的上網設備需要支持更多的硬件資源、操作系統、軟件工具及應用程序，現有的解決方案顯然無法為數量龐大的物聯網設備提供相應的靈活性，這使開發者們面臨巨大的設計壓力。虛擬化技術是解決這些問題的關鍵。不過，現有的虛擬化解決方案并不能滿足物聯網開發的輕量級和靈活性的特殊要求。為了滿足當前物聯網市場的發展趨勢，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 和 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驗證啟動的步驟。

圖 2： ACRN Hypervisor 啟動步驟

啟動引導順序執行如下：

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 設備模式架構

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

• 第一種架構被稱為 hypervisor中 的設備模擬，這是在 VMware 工作站產品（一個基于操作系統的 hypervisor）中實現的設備模擬方式。在這種方式中，hypervisor 負責模擬需要在各個虛機操作系統之間共享的常見設備，其中包括：虛擬磁盤、虛擬網絡適配器和其它必要的平臺資源。
• 第二種架構稱為用戶空間的設備模擬。顧名思義，不是將設備模擬的實現嵌入到 hypervisor 中，而是將其放在一個用戶空間的應用程序中實現。比如被各種獨立的 hypervisor 所使用的 QEMU 就提供了此類的設備模擬方式。這種架構的優勢在于設備模擬的實現不依賴于 hypervisor，所以其它 hypervisor 可以重用改實現。甚至它還可以做任意設備的模擬，而不必擔心其功能的實現會影響 hypervisor（其在特權模式下運行）。
• 第三種架構則是從基于 hypervisor 的設備模擬改變而來的半虛擬化驅動程序。該架構一開始是在XEN項目中引入的，其中 hypervisor 提供物理設備驅動，每個虛機操作系統則需要安裝一個與能與物理驅動配合使用的 hypervisor 感知的驅動程序。

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

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

ACRN 的設備模塊

在 ACRN 中，每個 User OS（簡稱 UOS）都需要有一個 ACRN 設備模型與之對應。ACRN 設備模型首先為 UOS 初始化虛擬硬件平臺（包括初始化 VCPU 狀態、分配并初始化內存、初始化 UOS 啟動腳本中所指定的虛擬設備）、加載 guest 平臺固件文件或 guest 操作系統內核文件等，并最終通過調用 ACRN hypervisor 提供的服務去執行guest指令。

ACRN 設備模型是運行在 Service OS（簡稱 SOS）上的應用程序，其架構如圖5所示。

圖 5： ACRN 設備模塊

在 ACRN 中， I/O 虛擬化主要依賴于以下三部分的協同工作：

1. 設備仿真
2. I/O 請求處理
3. VHM（Virtio 和 Hypervisor 服務模塊） 

設備仿真

設備仿真指的是一系列 I/O 設備仿真例程，用來模擬不同種類的設備，比如 PCI 總線設備、ACPI 設備等。這些設備仿真例程均會被注冊到 ACRN 設備模型中，由 ACRN 設備模型中的 I/O 調度器進行調度和分發。當 UOS 產生 I/O 設備訪問請求時，I/O  調度器會根據請求的 I/O 地址，PIO 或者 MMIO，進一步調用具體設備的仿真例程。 

I/O 請求（簡稱 IOREQ）處理

參照以下 ACRN-I/O-mediator 。 

VHM

VHM（Virtio 和 Hypervisor 服務模塊）作為 ACRN hypervisor 和設備模型之間的橋梁，為設備模型提供必要的服務。VHM 運行在 Service OS 中，以內核模塊的形式存在，其具體的服務流程，如下所述： 

1. ACRN hypervisor 通過中斷的方式通知 VHM 新的 IOREQ 到來；
2. VHM 首先將 IOREQ 標記為“正在處理”，同時將其發送給 VHM 的用戶（如設備模型、gvt-g、VBS-K 等）做進一步處理。之后，VHM 可以處理新的 IOREQ；
3. 實際對 IOREQ 進行處理的可以是運行在 SOS 用戶態的ACRN設備模型，也可以是運行在 SOS 內核態中的其他設備模型，如 gvt-g 和 VBS-K。一旦 IOREQ 被處理完成，VHM 將被通知（內核態直接通過函數調用方式通知，而用戶態則通過 IOCTL 的方式通知），之后 VHM 通過 hypercall 的方式，進一步通知 ACRN hypervisor 該 IOREQ 已經處理完成。

用戶態程序：ACRN 設備模型；

內核態模塊：VHM、VBS-K、gvt-g 等； 

設備直通

總體上講，設備直通是為了將指定設備排他性提供給某個客戶操作系統獨立使用。

圖 6： 設備直通

通過設備直通可以實現幾乎原生的性能。在不需要在多個虛擬機中共享同一個設備的情況下，如系統中有多塊物理設備，設備直通對于某些高 I/O 需求的設備來說是最佳選擇，因為通過 hypervisor（無論是在 hypervisor 中還是在用戶空間中）虛擬設備會產生額外的性能下降。

除了性能角度考量外，有些設備先天不能被用在多個虛擬共享環境中，如 USB device 模式的 xDCI 端口。對于這類設備，ACRN 中則直接采用設備直通的方式供客戶操作系統使用。 

設備直通的硬件支持

英特爾目前的處理器架構使用 VT-d 為設備直通提供支持。VT-d 將客戶平臺物理地址映射到本地平臺機器物理地址，從而客戶操作系統能夠通過訪問客戶平臺物理地址進而訪問到本地平臺的物理硬件。在這個過程中，VT-d 負責設備的發訪問和保護，而客戶平臺操作系統只需像非虛擬化環境中一樣，直接訪問設備。除此之外，VT-d 還能防止物理設備惡意訪問屬于其他 VM 或者 hypervisor 的內存，從而能夠提高安全性。

此外，在 ACRN 項目中，設備主要使用 MSIx/MSI 中斷，而不是傳統的基于中斷 pin 的方式通知 guest。從而帶來的好處在于不僅能夠很好地處理來自于多個 VM 多個中斷的情況，而且能夠保證中斷源的隔離。 

設備直通的 hypervisor 支持

較新的英特爾處理器架構均支持 VT-d，因此各主流 hypervisor（Xen 和 KVM）均可以基于 VT-d 實現設備直通的功能。ACRN 同樣基于 VT-d 實現設備直通的功能。 

ACRN 虛擬 I/O 設備

圖 7 展示了ACRN 中訪問一個虛擬 I/O 所經歷的流程。

圖 7 I/O 虛擬流程（Port IO） 

以下是圖 7 中的編號項目：

1. 當 guest 操作系統執行 I/O 指令（PIO 或 MMIO）時，VM-Exit 發生，ACRN hypervisor 獲得處理器控制權，首先會判斷虛擬機執行退出的原因。在我們的例子中，VM-Exit 是因為 guest 中發生了 PIO 訪問，退出原因的號碼為VMX_EXIT_REASON_IO_INSTRUCTION。
2. 除了根據 VM-Exit 的原因號碼，ACRN hypervisor 還會對產生 VM-Exit 的指令進行譯碼。在我們的例子中，hypervisor會注意到是 PIO 指令（例如：in AL, 20h）。接下來，hypervisor 將譯碼得到的相關信息（包括 PIO 訪問、訪問字節數、讀/寫方式、目標寄存器等）放到與 ACRN VHM、ACRN 設備模型共享的物理頁面之中，然后以中斷的方式通知 SOS/VHM 去做進一步處理。
3. SOS 中的 VHM 接收到中斷后，查詢該 IOREQ 有關的所有信息。
4. VHM 首先會檢查是否應該由內核態的設備模型來處理該 IOREQ，如果是，那么相應的內核模塊之前注冊的callback函數會被 VHM 調用。否則，如果沒有內核態設備模型來處理 IOREQ，那么 VHM 則會將該 IOREQ 保留在共享頁面中，并喚醒 ACRN 設備模型對該 IOREQ 進行處理。
5. ACRN 設備模型采用與 VHM 相同的機制對 IOREQ 進行處理。設備模型的 I/O 執行線程會首先查詢 IOREQ 具體的信息，同時檢查是否有設備仿真模塊實現了該 IOREQ 對應的邏輯。如果有相應的模塊，那么該模塊對應的 callback 函數將會被調用。
6. ACRN 設備模型完成設備模擬仿真后（本示例中是對端口 IO 20h 的訪問），uDev1 將結果保存到共享頁面（示例中保存在 AL 寄存器）。
7. 完成相應 IOREQ 的模擬和仿真后，ACRN 設備模型通過 VHM 的 API 將控制權返回給 ACRN hypervisor。
8. ACRN hypervisor 得知 IOREQ 已經處理完成，則會結果保存到 VCPU 的相應寄存器中。
9. ACRN hypervisor 更新完 VCPU 寄存器后，進一步更新IP地址寄存器指向下一條 guest 指令，同時重啟 guest 的執行。

針對 guest 中 MMIO 訪問的處理，與上面例子中的 PIO 訪問處理類似，除了 VM-Exit 的原因不同：MMIO 對應的 VM-Exit 原因代碼是 VMX_EXIT_REASON_EPT_VIOLATION。

Virtio 框架架構

Virtio 是一種通用的面向虛擬設備的抽象，可以應用在任何 hypervisor 中。在 ACRN 參考設計中，我們的 Virtio 實現兼容 Virtio 標準規范 0.9 和 1.0。帶來的好處是，對于虛擬設備的實現，虛擬環境和客戶平臺可以復用一套直觀、高效、標準和可擴展的機制，而無需根據每個環境或者操作系統進行定制。

Virtio 提供一個通用的前端/后端驅動程序框架，它不僅標準化 virtio 設備的訪問接口，而且還增加了不同的虛擬化平臺上的代碼重用。

圖 8： Virtio 架構 

為了更好地理解 Virtio，尤其是它在 ACRN 項目中的使用，下面列舉幾個 Virtio 的關鍵概念：

Virtio 前端驅動程序

Virtio 采用了前端-后端架構，分別為前端和后端 Virtio 驅動程序提供一個簡單又靈活的框架。Virtio 前端驅動框架提供了前端Virtio API 來配置硬件、傳遞消息、提交請求、通知后端 Virtio 驅動程序等。因此，Virtio 前端驅動程序很容易實現，并且性能與設備模擬仿真相比有較大提升。

后端 Virtio 驅動程序

與 Virtio 前端驅動程序類似，Virtio 后端驅動程序運行在宿主平臺（內核態或者用戶態）。Virtio 后端驅動程序處理來自于前端驅動程序的請求，并按需將請求進一步發送到本地設備驅動程序。一旦請求被 Virtio 后端驅動程序處理完成，后端驅動程序就會通知前端驅動程序“請求已完成”。

直觀：Virtio 設備復用已有設備總線

Virtio 復用已有設備總線，而不是創建全新類型的設備總線，帶來的好處是 Virtio 前端和后端驅動可以直接利用已有的代碼進行交互。例如，Virtio 前端驅動程序可以直接讀/寫虛擬設備（由 Virtio 后端驅動程序虛擬）的寄存器，同時虛擬設備（由 Virtio 后端驅動程序虛擬）可以直接以中斷的方式通知前端驅動程序事件的發生。目前，Virtio 標準規范定義了幾種總線結果，如PCI/PCIe 總線、MMIO 總線、CCW 總線等。目前 ACRN 項目只支持 PCI/PCIe 總線。

高效：鼓勵批處理操作

批處理操作和延遲通知對于實現高性能 I/O 非常重要，因為Virtio前端和后端驅動程序之間的通知會導致代價高昂的VM-Exit等。因此應當盡可能批量處理數據，同時減少事件的通知。 

標準：virtqueue

所有 Virtio 設備使用同一套稱為 virtqueue 的機制，其內部實現是兩個標準環形緩沖區和一個描述符列表，如圖 6 所示。Virtqueue 是一個分散-聚集緩沖區隊列，主要有以下三種操作方式：

• add_buf 在 virtqueue 中添加請求/響應；
• get_buf 在 virtqueue 中獲得響應/請求；
• kick 通知對方 virtqueue 已經被更新；

virtqueue 由 Virtio 前端驅動程序在 guest 物理內存中創建。Virtio 后端驅動程序只需要調用 Virtio API 解析 virtqueue 的結構即可獲得請求或響應。如何構建 virtqueue 則取決于 guest 操作系統。在 Linux 中實現 Virtio 時，virtqueue 被實現為一個稱為 vring 的環形緩沖結構。

在 ACRN 的 Virtio 前端驅動程序開發過程中，virtqueue API 可被直接利用，從而用戶無需關心 virtqueue 的具體內部細節。關于 virtqueue 實現的更多細節，請參考您所使用的 guest 操作系統。

可擴展：特征 bit

每個 Virtio 設備和其 Virtio 前端驅動程序之間都存在一個簡單可擴展的特征協商（feature negotiation）機制。每個Virtio設備都可以聲明其設備特定的功能，而相應地 Virtio 前端驅動程序可以表示自己能夠理解哪些硬件特征。這種特征協商的機制能夠保證驅動程序向前和向后兼容。 

在 ACRN 參考實現中，Virtio 前端驅動程序存在于 guest 操作系統的內核態空間，而 Virtio 后端驅動程序則存在兩種可能：用戶態和內核態。圖 9 顯示了 ACRN 中用戶態的 Virtio 后端驅動程序架構。

圖 9： Virtio 框架 – 用戶態程序

在 ACRN virtio 后端驅動框架中，該實現兼容 virtio 標準規范 0.9 和 1.0 版本。VBS-U 與設備模型靜態鏈接，并通過 PCIe/PCI 虛擬設備接口（PIO/MMIO 或 MSI/MSIx）與設備模型通信。VBS-U 通過用戶態 virtqueue API 來訪問 Virtio 前端驅動程序在共享內存中放置的數據。SOS 訪問 UOS 物理內存則是基于 ACRN hypervisor 的幫助。

圖 10: Virtio 框架- 內核態程序

從性能角度出發，為了支持一些性能要求較高的設備，數據平面（data plane）的處理可以從用戶態挪到內核態，從而避免 Virtio 后端驅動在用戶態和內核態切換時產生額外的數據搬運；而控制平面（control plane）的處理，仍然保留在用戶空間，即 VBS-U 中。VBS-U需要選擇在正確的時間初始化 VBS-K，例如，Virtio 前端驅動設置 VIRTIO_CONFIG_S_DRIVER_OK 時就是一個不錯的時機。運行在內核態的 Virtio 后端驅動可以使用 VBS-K virtqueue API 前端驅動共享的數據?？紤]到易用性，VBS-K virtqueue API 與 VBS-U virqueue API 設計得極為相似。此外，VBS-K 依賴于 VHM，即 VHM 負責分發 IOREQ 給 VBS-K 模塊。每個 VBS-K 需要處理一類或者多類 IOREQ 請求，具體多少取決于特定的VBS-K需要監聽多少段連續的寄存器空間。最后，VBS-K 借助于 VHM 的 API 來通過中斷的方式通知 Virtio 前端驅動程序。

看到這里，開發者們是不是有興趣親自動手實踐了，如果您在項目設計中遇到關于ACRN的技術問題，歡迎訪問ACRN社區進行討論，社區地