在嵌入式虛擬化環(huán)境中，顯示模塊往往是搶手而又珍貴的資源，也因此SoC 廠商往往為了性能和成本，顯示器模塊很少會(huì)實(shí)現(xiàn)成可硬件分區(qū)的方式，而虛擬機(jī)往往需要多個(gè)顯示功能以應(yīng)對(duì)不同專業(yè)的場景，同時(shí)還要面臨以下技術(shù)問題：

性能，常見的純軟件手段需要CPU 做數(shù)據(jù)復(fù)制，這會(huì)導(dǎo)致性能大打折扣，同時(shí)還影響圖形服務(wù)的啟動(dòng)速度；

隔離，比如類似AMP 硬分區(qū)部署場景，如果其中一個(gè)虛擬機(jī)因?yàn)榘l(fā)生故障需要下線或者重啟，這時(shí)候可能會(huì)由于硬件無法徹底硬分區(qū)而導(dǎo)致虛擬機(jī)重啟階段重新初始化硬件，影響其他虛擬機(jī)使用的設(shè)備。

適配，當(dāng)遇到不同的OS，以及不同類型的驅(qū)動(dòng)時(shí)不容易適配，這會(huì)導(dǎo)致需要花大量時(shí)間進(jìn)行方案適配，同時(shí)如果虛擬機(jī)部署場景發(fā)生改變，可能需要重新進(jìn)行適配，導(dǎo)致產(chǎn)品落地時(shí)間延長。

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

架構(gòu)圖

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

在這種架構(gòu)下，Driver OS 作為特權(quán)虛擬機(jī)，其他虛擬機(jī)作為非特權(quán)虛擬機(jī)，尤其是偏提供娛樂、多媒體的虛擬機(jī)中容易發(fā)生故障而導(dǎo)致重啟，共享顯示架構(gòu)還支持虛擬機(jī)下線、重新上線檢測，以保證Driver OS 與發(fā)生故障的虛擬機(jī)通信時(shí)不會(huì)導(dǎo)致崩潰，同時(shí)故障虛擬機(jī)重啟后，可繼續(xù)使用共享顯示服務(wù)。

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

涉及到人機(jī)交互場景，虛擬機(jī)需要額外使用半虛擬化輸入驅(qū)動(dòng)，本文不涉及。

原理圖

在Driver OS 啟動(dòng)后，會(huì)立即啟動(dòng)共享顯示服務(wù)，在初始化的過程中，將平臺(tái)的圖層根據(jù)配置與 IVC 顯存進(jìn)行映射，初始化圖層后等待顯示客戶端接入。

顯示客戶端OS 啟動(dòng)時(shí)，用戶可選擇使用加載共享顯示 FB 驅(qū)動(dòng)或者 DRM 驅(qū)動(dòng)，共享顯示驅(qū)動(dòng)使用 IVC 請(qǐng)求共享顯示服務(wù)，多次請(qǐng)求后，完成顯示模塊的信息獲取：長、寬、顏色格式，顯存行長度，雙緩沖支持等。共享顯示驅(qū)動(dòng)獲取完顯示信息后，將根據(jù)用戶加載的驅(qū)動(dòng)版本注冊(cè) DRM 或者 FB 設(shè)備，共享顯示驅(qū)動(dòng)采用標(biāo)準(zhǔn) DRM/FB 驅(qū)動(dòng)開發(fā)方式實(shí)現(xiàn)，不需要針對(duì)平臺(tái)進(jìn)行重新適配。

當(dāng)顯示客戶端顯示應(yīng)用請(qǐng)求顯示功能時(shí)，操作系統(tǒng)圖形棧將用戶繪制結(jié)果提交至前臺(tái)，前臺(tái)通過DRM/FB 編程接口提交刷新請(qǐng)求到共享顯示驅(qū)動(dòng)，共享顯示驅(qū)動(dòng)再通過 IVC 請(qǐng)求共享顯示服務(wù)刷新圖層，再由共享顯示服務(wù)提交繪制結(jié)果至物理設(shè)備。在上述的請(qǐng)求路徑中，共享顯示驅(qū)動(dòng)通過圖層限制管理，使圖形棧和顯示應(yīng)用始終認(rèn)為共享內(nèi)存就是具體的顯存，也就是：

共享顯示驅(qū)動(dòng)與IVC 共享內(nèi)存——IVC 共享內(nèi)存與共享顯示服務(wù)——共享顯示服務(wù)與平臺(tái)圖形驅(qū)動(dòng)框架訪問的顯存

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

共享顯示服務(wù)始終等待顯示客戶端

IVC 請(qǐng)求，由于 IVC 采用阻塞等待機(jī)制，對(duì)顯示客戶端不存在依賴，當(dāng)顯示客戶端下線或者突然崩潰時(shí)無法繼續(xù)請(qǐng)求顯示服務(wù)時(shí)，共享顯示服務(wù)不會(huì)處理任何通知，始終認(rèn)為顯示客戶端處于沒有提交請(qǐng)求的狀態(tài)。當(dāng)顯示客戶端重啟后，會(huì)重新建立 IVC 通信，可重新通過 IVC 請(qǐng)求獲取顯示信息并繼續(xù)工作。

vmRT-Thread 平臺(tái)采用配置工具對(duì)共享顯示進(jìn)行部署：

虛擬化系統(tǒng)部署

在SoC 平臺(tái)上部署 vmRT-Thread；創(chuàng)建一個(gè) Driver OS 以及一到兩個(gè)普通虛擬機(jī)，同時(shí)要配置好硬件分區(qū)，IVC 通道。

由于IVC 以及共享顯示模塊掛載于 PCI Bus，僅需要對(duì)虛擬機(jī)設(shè)備樹導(dǎo)入 PCI 控制器節(jié)點(diǎn)：

Driver OS 部署

在Driver OS 構(gòu)建工具中，啟用共享顯示服務(wù)，并配置顯示器（顯示區(qū)域）分區(qū)，綁定與顯示分區(qū)的 IVC 通道。

Android 部署

在AOSP 工程中，啟用 Kernel 共享顯示內(nèi)核模塊，IVC 驅(qū)動(dòng)內(nèi)核模塊，并啟用共享顯示 HWC2、Gralloc4 模塊。

RT-Thread 部署（可選）

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

示例1

在某些場景中，Driver OS 也可以直接擔(dān)任顯示功能的虛擬機(jī)，同時(shí) Android 使用另外一個(gè)顯示器：

此時(shí)Driver OS 獨(dú)占一個(gè)物理顯示模塊，如果需要在此場景進(jìn)行分區(qū)顯示，需要使用 GPU 虛擬化模塊，本文不涉及。

效果圖

1

Driver OS 啟動(dòng)后會(huì)立即開啟共享顯示服務(wù)、顯示功能用例；Android （未專門定制的情況下）啟動(dòng)時(shí)間會(huì)較長。

示例2

Driver OS 不使用屏幕，僅共享顯示器給虛擬機(jī)，Android 使用共享顯示模塊獨(dú)占一個(gè)顯示器：

效果圖2

示例3

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

效果圖3

示例4

在一個(gè)屏幕上，RT-Thread 和 Buildroot Linux 進(jìn)行顯示分區(qū)：

效果圖4

該方法基于共享顯示的嵌入式虛擬化解決方案，通過將硬件資源訪問虛擬化，使虛擬機(jī)只需通過增加設(shè)備驅(qū)動(dòng)的方式訪問顯示設(shè)備，而后端驅(qū)動(dòng)虛擬機(jī)通過平臺(tái)顯示驅(qū)動(dòng)+ 虛擬化擴(kuò)展服務(wù)，實(shí)現(xiàn)了更可控，更高性能的顯示分區(qū)，為車載、工業(yè)混合部署等多種顯示功能的場景提供新的解決方案。