通过vmRT-Thread和VirtIO-SCMI攻克硬件分割依赖难点 | 前沿观点

硬件分割依赖难点是现代嵌入式系统和物联网设备开发中常见的问题。在多任务或多应用的系统中，不同任务或应用需要访问不同的硬件资源，传统的系统设计中，硬件资源的分配往往与软件紧密耦合，导致软件的可移植性和可扩展性受限。同时，硬件资源的共享访问可能导致资源竞争和冲突，进而影响系统的稳定性和安全性。特别是在安全关键的应用场景（如汽车电子、工业控制等）中，这种问题尤为突出。

 

RT-Thread睿赛德通过vmRT-Thread和VirtIO-SCMI的方式，提供一种攻克硬件分割依赖难点的思路，希望对大家有所帮助，也欢迎大家在留言中或者扫码小睿助手继续交流。

 

在嵌入式虚拟化环境中，外设硬分割（Partition/Passthrough）是充分发挥虚拟化硬件性能的重要手段。然而早期实现中，操作系统存在以下难题：

驱动需求繁复：虚拟机操作系统本身需要移植大量驱动，此类驱动本身较复杂。

 

 

虚拟机行为不可控：存在多个虚拟机依赖同一个外设的情况，由于无法保证多个虚拟机并发访问同一个物理资源为原子操作，行为不可控易导致不安全。

 

 

耦合严重且缺乏标准：可移植性差，固件更新困难；多操作系统（OS）/虚拟化下资源控制混乱，无法实现高级功耗与性能策略协同。

 

 

 

为解决上述问题，本文将介绍一种基于SCMI协议实现的依赖资源共享的虚拟化框架（VirtIO-SCMI），其架构如下图所示：

 

 

在vmRT-Thread中，普通虚拟机作为VirtIO-SCMI前端，仅转发硬件操作请求；驱动虚拟机作为后端，解析请求并校验权限后，通过procfs/ioctl操作真实硬件，两者均通过VirtIO通道通信。

 

 

同时，VirtIO-SCMI目前存在部分限制与要求：前端虚拟机需要选择合适的内核版本，后端虚拟机需要提供操作真实的硬件的procfs或者ioctl接口，并确保并发访问的原子性。

 

 

基于上述情况，vmRT-Thread可进行如下具体操作：

 

 

示例1

将VirtIO-SCMI前端虚拟机中某个uart中的clk，reset，pinctrl替换为VirtIO-SCMI。

大致步骤如下：

 

 

1. VirtIO-SCMI前端虚拟机需要修改设备树：

• 首先需要增加scmi的clk，reset，pinctrl的子协议设备树节点
•  
•  
•  
•  

firmware {scmi {compatible = "arm,scmi-virtio";#address-cells = <0x01>;#size-cells = <0x00>;scmi_clk: protocol@14 {reg = <0x14>;#clock-cells = <1>;};scmi_reset: protocol@16 {reg = <0x16>;#reset-cells = <1>;};scmi_pinctrl: protocol@19 {reg = <0x19>;uartA_0_pins: uartA_pins@0 {groups = "X", "Y";function = "1_uartA";bias-pull-up;drive-strength = <10>;};uartB_1_pins: uartB_pins@1 {groups = "M", "N";function = "1_gpio_in";};};};};

• 然后对应串口的设备树节点，需要引用scmi的clk，reset，pinctrl的子协议设备树节点，其中clk，reset还需要通过参数来提供索引号。
•  
•  
•  
•  
•  
•  
•  

uart@xxxxxx {clocks = <&scmi_clk U>;resets = <&scmi_reset V>;pinctrl-0 = <&uartA_0_pins>;pinctrl-1 = <&uartB_1_pins>;status = "okay";};

1. VirtIO-SCMI后端虚拟机需要修改VirtIO-SCMI Backend Service的配置文件，配置文件主要包含硬件的描述信息，索引关系，以及权限等等。
2. VirtIO-SCMI后端虚拟机启动VirtIO-SCMI Backend Service，然后再启动VirtIO-SCMI前端虚拟机，可以看到VirtIO-SCMI前端虚拟机的串口可以正常工作。

 

 

 

示例2

将VirtIO-SCMI前端虚拟机中某些CPU的频率替换为VirtIO-SCMI。

大致步骤如下：

1. VirtIO-SCMI前端虚拟机需要修改设备树：

• 首先需要增加scmi的perf的子协议设备树节点
•  
•  
•  
•  
•  
•  
•  
•  
•  
•  
•  

firmware {scmi {compatible = "arm,scmi-virtio";#address-cells = <0x01>;#size-cells = <0x00>;scmi_perf: protocol@13 {reg = <0x13>;phandle = <0x04>;};};};

• 然后对应CPU的设备树节点中的频率属性需要引用scmiperf子协议设备树节点，同时还需要通过参数来提供索引号。
•  
•  
•  
•  
•  

cpus {cpu@0 {clocks = <&scmi_perf C>;};};

1. VirtIO-SCMI后端虚拟机需要VirtIO-SCMI Backend Service的配置文件，配置文件主要包含硬件的描述信息，索引关系，以及权限等等。
2. VirtIO-SCMI后端虚拟机启动VirtIO-SCMI Backend Service，然后再启动VirtIO-SCMI前端虚拟机。
3. VirtIO-SCMI前端虚拟机首先配置CPU0频率为固定频率408MHZ，然后通过coremak测试跑分效果；然后再配置CPU0频率为固定频率2.4GHZ，然后通过coremak测试跑分效果；进行对比，对比之后可以看到CPU固定频率提升之后，跑分测试分数从3011.594639提升到17049.329393，符合预期。
    

效果图1

效果图2

该方法基于VirtIO-SCMI的嵌入式虚拟化解决方案，通过将硬件资源访问虚拟化，使前端虚拟机只需通过VirtIO-SCMI协议转发请求，而后端驱动虚拟机通过procfs/ioctl统一处理真实硬件操作，既实现了多虚拟机间的资源隔离与安全管控，又避免了重复移植clock/power等驱动，为车载、物联网等需要严格外设隔离的场景提供新路径。