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

物聯網市場的應用場景日益複雜，越來越多的上網裝置需要支援更多的硬體資源、作業系統、軟體工具及應用程式，現有的解決方案顯然無法為數量龐大的物聯網裝置提供相應的靈活性，這使開發者們面臨巨大的設計壓力。虛擬化技術是解決這些問題的關鍵。不過，現有的虛擬化解決方案並不能滿足物聯網開發的輕量級和靈活性的特殊要求。為了滿足當前物聯網市場的發展趨勢，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框架結構等一一為你展示。

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 and Hypervisor service Module）。

裝置模擬：

裝置模擬指的是一系列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 and Hypervisor service Module）模組作為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後端驅動程式架構。

Figure 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的幫助。

Figure 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社群進行討論，社群地址：

https://projectacrn.github.io/latest/index.html