通过 vmRT-Thread 和共享显示支持汽车座舱开发

在嵌入式虚拟化环境中，显示模块往往是抢手而又珍贵的资源，也因此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 请求共享显示服务，多次请求后，完成显示模块的信息获取：长、宽、颜色格式，显存行长度，双缓冲支持等。共享显示驱动获取完显示信息后，将根据用户加载的驱动版本注册 DRM 或者 FB 设备，共享显示驱动采用标准 DRM/FB 驱动开发方式实现，不需要针对平台进行重新适配。

当显示客户端显示应用请求显示功能时，操作系统图形栈将用户绘制结果提交至前台，前台通过DRM/FB 编程接口提交刷新请求到共享显示驱动，共享显示驱动再通过 IVC 请求共享显示服务刷新图层，再由共享显示服务提交绘制结果至物理设备。在上述的请求路径中，共享显示驱动通过图层限制管理，使图形栈和显示应用始终认为共享内存就是具体的显存，也就是：

共享显示驱动与IVC 共享内存——IVC 共享内存与共享显示服务——共享显示服务与平台图形驱动框架访问的显存

都是同一块物理显存，因此除图形栈自身图像软件合成外，CPU 不用额外参与拷贝工作。

共享显示服务始终等待显示客户端

IVC 请求，由于 IVC 采用阻塞等待机制，对显示客户端不存在依赖，当显示客户端下线或者突然崩溃时无法继续请求显示服务时，共享显示服务不会处理任何通知，始终认为显示客户端处于没有提交请求的状态。当显示客户端重启后，会重新建立 IVC 通信，可重新通过 IVC 请求获取显示信息并继续工作。

vmRT-Thread 平台采用配置工具对共享显示进行部署：