硬件分割依賴難點是現代嵌入式系統和物聯網設備開發中常見的問題。在多任務或多應用的系統中，不同任務或應用需要訪問不同的硬件資源，傳統的系統設計中，硬件資源的分配往往與軟件緊密耦合，導致軟件的可移植性和可擴展性受限。同時，硬件資源的共享訪問可能導致資源競爭和沖突，進而影響系統的穩定性和安全性。特別是在安全關鍵的應用場景（如汽車電子、工業控制等）中，這種問題尤為突出。

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等驅動，為車載、物聯網等需要嚴格外設隔離的場景提供新路徑。