在嵌入式虛擬化環境中，顯示模塊往往是搶手而又珍貴的資源，也因此SoC 廠商往往為了性能和成本，顯示器模塊很少會實現成可硬件分區的方式，而虛擬機往往需要多個顯示功能以應對不同專業的場景，同時還要面臨以下技術問題：

性能，常見的純軟件手段需要CPU 做數據復制，這會導致性能大打折扣，同時還影響圖形服務的啟動速度；

隔離，比如類似AMP 硬分區部署場景，如果其中一個虛擬機因為發生故障需要下線或者重啟，這時候可能會由于硬件無法徹底硬分區而導致虛擬機重啟階段重新初始化硬件，影響其他虛擬機使用的設備。

適配，當遇到不同的OS，以及不同類型的驅動時不容易適配，這會導致需要花大量時間進行方案適配，同時如果虛擬機部署場景發生改變，可能需要重新進行適配，導致產品落地時間延長。

為了解決這些問題，本文將介紹一種基于虛擬機通信（IVC）的顯示共享技術，其架構如下圖所示：

架構圖

在vmRT-Thread 中，Driver OS 控制實際的物理顯示設備，并提供共享顯示服務，通過 IVC 與普通虛擬機共享顯示設備，由于 IVC Manager 可支持共享內存方式 + 內存虛擬化技術，在共享顯示的前后端驅動中，CPU 幾乎可以不參與拷貝工作。

在這種架構下，Driver OS 作為特權虛擬機，其他虛擬機作為非特權虛擬機，尤其是偏提供娛樂、多媒體的虛擬機中容易發生故障而導致重啟，共享顯示架構還支持虛擬機下線、重新上線檢測，以保證Driver OS 與發生故障的虛擬機通信時不會導致崩潰，同時故障虛擬機重啟后，可繼續使用共享顯示服務。

普通虛擬機可基于共享顯示驅動，直接將共享的顯示設備（顯示區域）作為獨立顯示器使用。當然，普通虛擬機需要使用vmRT-Thread 支持的共享顯示驅動，如 RT-Thread 提供 Framebuffer 版本驅動，Linux 提供 Framebuffer/DRM，Android 額外提供的 HWC，Gralloc 驅動。而這些驅動只要對應內核版本，API 版本兼容，可以在不同 BSP 下直接使用，虛擬機/產品無需關心 SoC 的物理顯示信息。

涉及到人機交互場景，虛擬機需要額外使用半虛擬化輸入驅動，本文不涉及。

原理圖

在Driver OS 啟動后，會立即啟動共享顯示服務，在初始化的過程中，將平臺的圖層根據配置與 IVC 顯存進行映射，初始化圖層后等待顯示客戶端接入。

顯示客戶端OS 啟動時，用戶可選擇使用加載共享顯示 FB 驅動或者 DRM 驅動，共享顯示驅動使用 IVC 請求共享顯示服務，多次請求后，完成顯示模塊的信息獲?。洪L、寬、顏色格式，顯存行長度，雙緩沖支持等。共享顯示驅動獲取完顯示信息后，將根據用戶加載的驅動版本注冊 DRM 或者 FB 設備，共享顯示驅動采用標準 DRM/FB 驅動開發方式實現，不需要針對平臺進行重新適配。

當顯示客戶端顯示應用請求顯示功能時，操作系統圖形棧將用戶繪制結果提交至前臺，前臺通過DRM/FB 編程接口提交刷新請求到共享顯示驅動，共享顯示驅動再通過 IVC 請求共享顯示服務刷新圖層，再由共享顯示服務提交繪制結果至物理設備。在上述的請求路徑中，共享顯示驅動通過圖層限制管理，使圖形棧和顯示應用始終認為共享內存就是具體的顯存，也就是：

共享顯示驅動與IVC 共享內存——IVC 共享內存與共享顯示服務——共享顯示服務與平臺圖形驅動框架訪問的顯存

都是同一塊物理顯存，因此除圖形棧自身圖像軟件合成外，CPU 不用額外參與拷貝工作。

共享顯示服務始終等待顯示客戶端

IVC 請求，由于 IVC 采用阻塞等待機制，對顯示客戶端不存在依賴，當顯示客戶端下線或者突然崩潰時無法繼續請求顯示服務時，共享顯示服務不會處理任何通知，始終認為顯示客戶端處于沒有提交請求的狀態。當顯示客戶端重啟后，會重新建立 IVC 通信，可重新通過 IVC 請求獲取顯示信息并繼續工作。

vmRT-Thread 平臺采用配置工具對共享顯示進行部署：

虛擬化系統部署

在SoC 平臺上部署 vmRT-Thread；創建一個 Driver OS 以及一到兩個普通虛擬機，同時要配置好硬件分區，IVC 通道。

由于IVC 以及共享顯示模塊掛載于 PCI Bus，僅需要對虛擬機設備樹導入 PCI 控制器節點：

Driver OS 部署

在Driver OS 構建工具中，啟用共享顯示服務，并配置顯示器（顯示區域）分區，綁定與顯示分區的 IVC 通道。

Android 部署

在AOSP 工程中，啟用 Kernel 共享顯示內核模塊，IVC 驅動內核模塊，并啟用共享顯示 HWC2、Gralloc4 模塊。

RT-Thread 部署（可選）

在RT-Thread 工程中以及 vmRT-Thread Guest 配置中，啟用共享顯示和 IVC 驅動組件，并部署好 LVGL 或 Qt 工程。

示例1

在某些場景中，Driver OS 也可以直接擔任顯示功能的虛擬機，同時 Android 使用另外一個顯示器：

此時Driver OS 獨占一個物理顯示模塊，如果需要在此場景進行分區顯示，需要使用 GPU 虛擬化模塊，本文不涉及。

效果圖

1

Driver OS 啟動后會立即開啟共享顯示服務、顯示功能用例；Android （未專門定制的情況下）啟動時間會較長。

示例2

Driver OS 不使用屏幕，僅共享顯示器給虛擬機，Android 使用共享顯示模塊獨占一個顯示器：

效果圖2

示例3

Driver OS 不使用屏幕，僅共享顯示器給虛擬機，RT-Thread 占用一個顯示器，Android 占用一個顯示器：

效果圖3

示例4

在一個屏幕上，RT-Thread 和 Buildroot Linux 進行顯示分區：

效果圖4

該方法基于共享顯示的嵌入式虛擬化解決方案，通過將硬件資源訪問虛擬化，使虛擬機只需通過增加設備驅動的方式訪問顯示設備，而后端驅動虛擬機通過平臺顯示驅動+ 虛擬化擴展服務，實現了更可控，更高性能的顯示分區，為車載、工業混合部署等多種顯示功能的場景提供新的解決方案。