物聯網市場的應用場景日益復雜，越來越多的上網設備需要支持更多的硬件資源、操作系統、軟件工具及應用程序，現有的解決方案顯然無法為數量龐大的物聯網設備提供相應的靈活性，這使開發(fā)者們面臨巨大的設計壓力。虛擬化技術是解決這些問題的關鍵。不過，現有的虛擬化解決方案并不能滿足物聯網開發(fā)的輕量級和靈活性的特殊要求。為了滿足當前物聯網市場的發(fā)展趨勢，Linux基金會推出了開源項目---ACRN，
ACRN到底具有哪些強大的功能,它又是怎么實現的?今天我們就從架構到應用對ACRN進行詳細分析，讓開發(fā)者們快速上手使用ACRN進行產品設計。
ACRN是一個專為嵌入式設備設計的hypervisor，包括如下兩部分：一套hypervisor的參考軟件和架構，通過虛擬機監(jiān)視器(Virtual Machine Manager)可以在同一個物理硬件上安全地同時運行多個操作系統。另外，它還為設備虛擬化模擬定義了一套參考設計框架，稱為“ACRN設備模型”。
ACRN hypervisor是一個Type-I的hypervisor，可以直接運行在物理硬件上，適用于各種物聯網和嵌入式設備解決方案。ACRN hypervisor解決了當前數據中心hypervisor和partitioning hypervisor之間存在的差距。ACRN hypervisor設計時把系統分為不同的功能域，并為物聯網和嵌入式設備精心挑選的用戶操作系統進行共享優(yōu)化。
汽車應用案例
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進行管理。開發(fā)者和OEM廠商可以在ACRN hypervisor之上運行自己的虛擬機，以及IC、IVI和RSE VM。Service OS是作為VM0運行(在Xen* hypervisor中被稱為Dom0，在KVM* hypervisor中被稱為Host OS)，User OS用戶操作系統作為VM1運行(也被稱為DomU)。
注：Android*虛擬機的支持將在未來版本發(fā)布。
圖1顯示了一個使用ACRN hypervisor的實例框圖。
圖1：SOS和UOS運行在ACRN hypervisor之上
從ACRN hypervisor的架構圖中可以看到：
ACRN hypervisor直接位于bootloader之上，因而具備快速啟動的能力;
部分資源進行partitioning，以確保安全關鍵性應用和非安全關鍵業(yè)務可以共存在同一平臺上;
豐富的I/O設備虛擬化提供在多個VM之間的I/O設備共享，從而提供全面的用戶體驗;
通過高效的虛擬化，一個SoC可以支持多個操作系統同時運行;
圖1中的黃色部分是ACRN項目的軟件棧。該架構框圖中列出的某些功能還沒有完全實現，歡迎社區(qū)共同參與開發(fā)實現。另外，圖中的其他模塊來自于別的開源項目，這里僅供參考。
例如，Service OS和Guest Linux來源于https://clearlinux.org上的Clear Linux項目，而未來Guest Android的支持將會來自https://01.org/android-ia項目。
當前ACRN所支持的功能列表，請參照發(fā)布說明。
許可證
ACRN hypervisor和ACRN Device Model軟件采用的都是自由許可證的BSD-3-Clause，它允許以“源代碼和二進制再次發(fā)布和使用，無論是否進行了修改”， 許可證中也注明了完整版權聲明和免責聲明。
ACRN Device Model, Service OS, and User OS
為了使ACRN hypervisor代碼盡可能精悍且高效，用于實現I/O設備共享的device model代碼運行在Service OS中而非ACRN Hypervisor。哪些I/O設備被共享以及其實現細節(jié)將在下面的pass-through章節(jié)具體介紹。
Service OS在所有虛擬機里，以最高優(yōu)先權運行，以滿足那些對時間響應要求很高的需求和系統服務質量的需求(QoS)。具體到Service OS中的任務(task)，他們的優(yōu)先級則有高有低。例如響應User OS請求的回調函數，其運行在Service OS的軟件(或者mediator)就會繼承User OS的優(yōu)先級。另外，在Service OS中還有一些在后臺運行的任務也是低優(yōu)先級。
在上述的車載系統示例中，User OS是駕駛控制和車內娛樂的中心樞紐。它能提供收音機和各種娛樂選項、車內空調和通風控制、車輛導航顯示等支持。它可以讓第三方設備使用USB、藍牙或者WiFi等連接技術與車載系統進行交互，例如：Android Auto* 或者 Apple CarPlay*, 還能提供許多其它功能。
啟動步驟
在圖2中，我們展示了在一個采用英特爾架構平臺的NUC上使用UEFI驗證啟動的步驟。
Figure 2 ACRN Hypervisor Boot Flow
啟動引導順序執(zhí)行如下：
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的運行信息，并控制用戶虛擬機的開始、停止和暫停，還能暫?；蛘呋謴蛨?zhí)行單個虛擬CPU。
圖3 ACRN Hypervisor 架構圖
ACRN hypervisor采用了英特爾虛擬化技術(Intel VT)，其運行在虛擬機擴展模式(VMX)的root模式下，也稱為主機模式或VMM模式。其他所有的用戶虛擬機包括UOS和SOS都運行在VMX non-root模式或guest模式下。(以下為了簡略，我們將繼續(xù)使用術語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一般不被商業(yè)操作系統所使用)。
圖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模式。一般處理器會在響應某些指令和事件時發(fā)生VM exit。
在guest模式下，處理器的執(zhí)行是由一個虛擬機控制結構(VMCS)所控制的。VMCS包含了虛機狀態(tài)(在VM Entry時加載并在VM Exit時保存)，主機狀態(tài)(在VM exit時加載)，以及虛機的控制執(zhí)行。ACRN hypervisor為每個虛擬CPU創(chuàng)建了一個VMCS數據結構，并使用該VMCS來控制運行在guest模式下處理器的行為。
當虛機執(zhí)行到一個敏感指令時，就會觸發(fā)一次定義在VMCS配置中的VM exit事件。當VM exit發(fā)生后，系統的控制權就交給了ACRN hypervisor。ACRN hypervisor會模擬虛機的指令(如果VM exit的原因是由于指令權限問題)，然后恢復虛機繼續(xù)執(zhí)行它的下一條指令，或者根據VM exit的原因進行相關處理(例如，一個虛機的存儲頁面需要建立映射關系)，然后恢復虛機重新執(zhí)行該條指令。
需要注意的是用于VMM模式的地址空間和用于guest模式的地址空間是不同的。guest模式和VMM模式下使用不同的內存映射表，因此虛機是無法訪問ACRN hypervisor的。ACRN hypervisor使用EPT來映射虛機地址，虛機頁表會將虛機的線性地址映射到虛機的物理地址， EPT表則將虛機的物理地址映射到機器物理地址或主機物理地址(HPA)。
ACRN Device Model Architecture
因為系統設備可能需要在不同的虛機之間被共享，虛機內應用程序(和操作系統)要對這些共享設備進行訪問就需要借助設備模擬。一般來說，設備模擬有三種架構：
第一種架構被稱為hypervisor中的設備模擬，這是在VMware*工作站產品(一個基于操作系統的hypervisor)中實現的設備模擬方式。在這種方式中，hypervisor負責模擬需要在各個虛機操作系統之間共享的常見設備，其中包括：虛擬磁盤、虛擬網絡適配器和其它必要的平臺資源。
第二種架構稱為用戶空間的設備模擬。顧名思義，不是將設備模擬的實現嵌入到hypervisor中，而是將其放在一個用戶空間的應用程序中實現。比如被各種獨立的hypervisor所使用的QEMU就提供了此類的設備模擬方式。這種架構的優(yōu)勢在于設備模擬的實現不依賴于hypervisor，所以其它hypervisor可以重用改實現。甚至它還可以做任意設備的模擬，而不必擔心其功能的實現會影響hypervisor(其在特權模式下運行)。
第三種架構則是從基于hypervisor的設備模擬改變而來的半虛擬化驅動程序。該架構一開始是在XEN項目中引入的，其中hypervisor提供物理設備驅動，每個虛機操作系統則需要安裝一個與能與物理驅動配合使用的hypervisor感知的驅動程序。
在以上討論的設備模擬架構中，共享設備都需要付出代價。因為不管設備模擬是在hypervisor中，還是在每個虛機內的用戶空間中，都存在相應的系統開銷。不過只要系統設備需要被多個虛機操作系統共享，這種開銷就是值得的。反之如果設備不需要被共享，那么就可以使用更有效的方法來訪問設備，例如使用“直通”。
看完以上的分析，你是否對ACRN有了更深入的了解?也是否有更多問題急需解答? 不用著急，我們將在下期中繼續(xù)講解各種技術細節(jié)，例如ACRN設備模塊架構、設備pass through， ACRN I/O mediator, Virtio框架結構等一一為你展示。
ACRN的設備模塊
在ACRN中，每個User OS(簡稱UOS)都需要有一個ACRN設備模型與之對應。ACRN設備模型首先為UOS初始化虛擬硬件平臺(包括初始化VCPU狀態(tài)、分配并初始化內存、初始化UOS啟動腳本中所指定的虛擬設備)、加載guest平臺固件文件或guest操作系統內核文件等，并最終通過調用ACRN hypervisor提供的服務去執(zhí)行guest指令。
ACRN設備模型是運行在Service OS(簡稱SOS)上的應用程序，其架構如圖5所示。
圖5 ACRN 設備模塊
在ACRN中， I/O虛擬化主要依賴于以下三部分的協同工作：
1)設備仿真
2)I/O請求處理
3)VHM(Virtio and Hypervisor service Module)。
設備仿真：
設備仿真指的是一系列I/O設備仿真例程，用來模擬不同種類的設備，比如PCI總線設備、ACPI設備等。這些設備仿真例程均會被注冊到ACRN設備模型中，由ACRN設備模型中的I/O調度器進行調度和分發(fā)。當UOS產生I/O設備訪問請求時，I/O調度器會根據請求的I/O地址，PIO或者MMIO，進一步調用具體設備的仿真例程。
I/O請求(簡稱IOREQ)處理：
參照以下ACRN-I/O-mediator
VHM：
VHM(Virtio and Hypervisor service Module)模塊作為ACRN hypervisor和設備模型之間的橋梁，為設備模型提供必要的服務。VHM運行在Service OS中，以內核模塊的形式存在，其具體的服務流程，如下所述：
1 ACRN hypervisor通過中斷的方式通知VHM新的IOREQ到來;
2 VHM首先將IOREQ標記為“正在處理”，同時將其發(fā)送給VHM的用戶(如設備模型、gvt-g、VBS-K等)做進一步處理。之后，VHM可以處理新的IOREQ;
3 實際對IOREQ進行處理的可以是運行在SOS用戶態(tài)的ACRN設備模型，也可以是運行在SOS內核態(tài)中的其他設備模型，如gvt-g和VBS-K。一旦IOREQ被處理完成，VHM將被通知(內核態(tài)直接通過函數調用方式通知，而用戶態(tài)則通過IOCTL的方式通知)，之后VHM通過hypercall的方式，進一步通知ACRN hypervisor該IOREQ已經處理完成。
用戶態(tài)程序：ACRN設備模型;
內核態(tài)模塊：VHM、VBS-K、gvt-g等;
設備直通
總體上講，設備直通是為了將指定設備排他性提供給某個客戶操作系統獨立使用。
圖6 設備直通
通過設備直通可以實現幾乎原生的性能。在不需要在多個虛擬機中共享同一個設備的情況下，如系統中有多塊物理設備，設備直通對于某些高I/O需求的設備來說是最佳選擇，因為通過hypervisor(無論是在hypervisor中還是在用戶空間中)虛擬設備會產生額外的性能下降。
除了性能角度考量外，有些設備先天不能被用在多個虛擬共享環(huán)境中，如USB device模式的xDCI端口。對于這類設備，ACRN中則直接采用設備直通的方式供客戶操作系統使用。
設備直通的硬件支持
英特爾目前的處理器架構使用VT-d為設備直通提供支持。VT-d將客戶平臺物理地址映射到本地平臺機器物理地址，從而客戶操作系統能夠通過訪問客戶平臺物理地址進而訪問到本地平臺的物理硬件。在這個過程中，VT-d負責設備的發(fā)訪問和保護，而客戶平臺操作系統只需像非虛擬化環(huán)境中一樣，直接訪問設備。除此之外，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操作系統執(zhí)行I/O指令(PIO 或 MMIO)時，VM-Exit發(fā)生，ACRN hypervisor獲得處理器控制權，首先會判斷虛擬機執(zhí)行退出的原因。在我們的例子中，VM-Exit是因為guest中發(fā)生了PIO訪問，退出原因的號碼為VMX_EXIT_REASON_IO_INSTRUCTION。
2、除了根據VM-Exit的原因號碼，ACRN hypervisor還會對產生VM-Exit的指令進行譯碼。在我們的例子中，hypervisor會注意到是PIO指令(例如：in AL, 20h)。接下來，hypervisor將譯碼得到的相關信息(包括PIO訪問、訪問字節(jié)數、讀/寫方式、目標寄存器等)放到與ACRN VHM、ACRN設備模型共享的物理頁面之中，然后以中斷的方式通知SOS/VHM去做進一步處理。
3、SOS中的VHM接收到中斷后，查詢該IOREQ有關的所有信息。
4、VHM首先會檢查是否應該由內核態(tài)的設備模型來處理該IOREQ，如果是，那么相應的內核模塊之前注冊的callback函數會被VHM調用。否則，如果沒有內核態(tài)設備模型來處理IOREQ，那么VHM則會將該IOREQ保留在共享頁面中，并喚醒ACRN設備模型對該IOREQ進行處理。
5、ACRN設備模型采用與VHM相同的機制對IOREQ進行處理。設備模型的I/O執(zhí)行線程會首先查詢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的執(zhí)行。
針對guest中MMIO訪問的處理，與上面例子中的PIO訪問處理類似，除了VM-Exit的原因不同：MMIO對應的VM-Exit原因代碼是VMX_EXIT_REASON_EPT_VIOLATION。
Virtio框架架構
Virtio是一種通用的面向虛擬設備的抽象，可以應用在任何hypervisor中。在ACRN參考設計中，我們的Virtio實現兼容Virtio標準規(guī)范0.9和1.0。帶來的好處是，對于虛擬設備的實現，虛擬環(huán)境和客戶平臺可以復用一套直觀、高效、標準和可擴展的機制，而無需根據每個環(huán)境或者操作系統進行定制。
Virtio提供一個通用的前端/后端驅動程序框架，它不僅標準化virtio設備的訪問接口，而且還增加了不同的虛擬化平臺上的代碼重用。
圖8 Virtio 架構
為了更好地理解Virtio，尤其是它在ACRN項目中的使用，下面列舉幾個Virtio的關鍵概念：
Virtio前端驅動程序
Virtio采用了前端-后端架構，分別為前端和后端Virtio驅動程序提供一個簡單又靈活的框架。Virtio前端驅動框架提供了前端Virtio API來配置硬件、傳遞消息、提交請求、通知后端Virtio驅動程序等。因此，Virtio前端驅動程序很容易實現，并且性能與設備模擬仿真相比有較大提升。
后端Virtio驅動程序
與Virtio前端驅動程序類似，Virtio后端驅動程序運行在宿主平臺(內核態(tài)或者用戶態(tài))。Virtio后端驅動程序處理來自于前端驅動程序的請求，并按需將請求進一步發(fā)送到本地設備驅動程序。一旦請求被Virtio后端驅動程序處理完成，后端驅動程序就會通知前端驅動程序“請求已完成”。
直觀：Virtio設備復用已有設備總線
Virtio復用已有設備總線，而不是創(chuàng)建全新類型的設備總線，帶來的好處是Virtio前端和后端驅動可以直接利用已有的代碼進行交互。例如，Virtio前端驅動程序可以直接讀/寫虛擬設備(由Virtio后端驅動程序虛擬)的寄存器，同時虛擬設備(由Virtio后端驅動程序虛擬)可以直接以中斷的方式通知前端驅動程序事件的發(fā)生。目前，Virtio標準規(guī)范定義了幾種總線結果，如PCI/PCIe總線、MMIO總線、CCW總線等。目前ACRN項目只支持PCI/PCIe總線。
高效：鼓勵批處理操作
批處理操作和延遲通知對于實現高性能I/O非常重要，因為Virtio前端和后端驅動程序之間的通知會導致代價高昂的VM-Exit等。因此應當盡可能批量處理數據，同時減少事件的通知。
標準：virtqueue
所有Virtio設備使用同一套稱為virtqueue的機制，其內部實現是兩個標準環(huán)形緩沖區(qū)和一個描述符列表，如圖6所示。Virtqueue是一個分散-聚集緩沖區(qū)隊列，主要有以下三種操作方式：
add_buf 在virtqueue中添加請求/響應;
get_buf 在virtqueue中獲得響應/請求;
kick 通知對方virtqueue已經被更新;
virtqueue由Virtio前端驅動程序在guest物理內存中創(chuàng)建。Virtio后端驅動程序只需要調用Virtio API解析virtqueue的結構即可獲得請求或響應。如何構建virtqueue則取決于guest操作系統。在Linux中實現Virtio時，virtqueue被實現為一個稱為vring的環(huán)形緩沖結構。
在ACRN的Virtio前端驅動程序開發(fā)過程中，virtqueue API可被直接利用，從而用戶無需關心virtqueue的具體內部細節(jié)。關于virtqueue實現的更多細節(jié)，請參考您所使用的guest操作系統。
可擴展：特征bit
每個Virtio設備和其Virtio前端驅動程序之間都存在一個簡單可擴展的特征協商(feature negotiation)機制。每個Virtio設備都可以聲明其設備特定的功能，而相應地Virtio前端驅動程序可以表示自己能夠理解哪些硬件特征。這種特征協商的機制能夠保證驅動程序向前和向后兼容。
在ACRN參考實現中，Virtio前端驅動程序存在于guest操作系統的內核態(tài)空間，而Virtio后端驅動程序則存在兩種可能：用戶態(tài)和內核態(tài)。圖9顯示了ACRN中用戶態(tài)的Virtio后端驅動程序架構。
Figure 9 Virtio框架 – 用戶態(tài)程序
在ACRN virtio后端驅動框架中，該實現兼容virtio標準規(guī)范0.9和1.0版本。VBS-U與設備模型靜態(tài)鏈接，并通過PCIe/PCI虛擬設備接口(PIO/MMIO或MSI/MSIx)與設備模型通信。VBS-U通過用戶態(tài)virtqueue API來訪問Virtio前端驅動程序在共享內存中放置的數據。SOS訪問UOS物理內存則是基于ACRN hypervisor的幫助。
Figure 10 Virtio框架- 內核態(tài)程序
從性能角度出發(fā)，為了支持一些性能要求較高的設備，數據平面(data plane)的處理可以從用戶態(tài)挪到內核態(tài)，從而避免Virtio后端驅動在用戶態(tài)和內核態(tài)切換時產生額外的數據搬運;而控制平面(control plane)的處理，仍然保留在用戶空間，即VBS-U中。VBS-U需要選擇在正確的時間初始化VBS-K，例如，Virtio前端驅動設置VIRTIO_CONFIG_S_DRIVER_OK時就是一個不錯的時機。運行在內核態(tài)的Virtio后端驅動可以使用VBS-K virtqueue API前端驅動共享的數據?？紤]到易用性，VBS-K virtqueue API與VBS-U virqueue API設計得極為相似。此外，VBS-K依賴于VHM，即VHM負責分發(fā)IOREQ給VBS-K模塊。每個VBS-K需要處理一類或者多類IOREQ請求，具體多少取決于特定的VBS-K需要監(jiān)聽多少段連續(xù)的寄存器空間。最后，VBS-K借助于VHM的API來通過中斷的方式通知Virtio前端驅動程序。
看到這里，開發(fā)者們是不是有興趣親自動手實踐了，如果您在項目設計中遇到關于ACRN的技術問題，歡迎訪問ACRN社區(qū)進行討論，社區(qū)地址
免責聲明：本網站內容主要來自原創(chuàng)、合作伙伴供稿和第三方自媒體作者投稿，凡在本網站出現的信息，均僅供參考。本網站將盡力確保所提供信息的準確性及可靠性，但不保證有關資料的準確性及可靠性，讀者在使用前請進一步核實，并對任何自主決定的行為負責。本網站對有關資料所引致的錯誤、不確或遺漏，概不負任何法律責任。任何單位或個人認為本網站中的網頁或鏈接內容可能涉嫌侵犯其知識產權或存在不實內容時，應及時向本網站提出書面權利通知或不實情況說明，并提供身份證明、權屬證明及詳細侵權或不實情況證明。本網站在收到上述法律文件后，將會依法盡快聯系相關文章源頭核實，溝通刪除相關內容或斷開相關鏈接。
