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

RT-Thread睿賽德通過vmRT-Thread和VirtIO-SCMI的方式，提供一種攻克硬件分割依賴難點的思路，希望對大家有所幫助，也歡迎大家在留言中或者掃碼小睿助手繼續(xù)交流。

在嵌入式虛擬化環(huán)境中，外設硬分割（Partition/Passthrough）是充分發(fā)揮虛擬化硬件性能的重要手段。然而早期實現(xiàn)中，操作系統(tǒng)存在以下難題：

驅動需求繁復：虛擬機操作系統(tǒng)本身需要移植大量驅動，此類驅動本身較復雜。

虛擬機行為不可控：存在多個虛擬機依賴同一個外設的情況，由于無法保證多個虛擬機并發(fā)訪問同一個物理資源為原子操作，行為不可控易導致不安全。

耦合嚴重且缺乏標準：可移植性差，固件更新困難；多操作系統(tǒng)（OS）/虛擬化下資源控制混亂，無法實現(xiàn)高級功耗與性能策略協(xié)同。

為解決上述問題，本文將介紹一種基于SCMI協(xié)議實現(xiàn)的依賴資源共享的虛擬化框架（VirtIO-SCMI），其架構如下圖所示：

在vmRT-Thread中，普通虛擬機作為VirtIO-SCMI前端，僅轉發(fā)硬件操作請求；驅動虛擬機作為后端，解析請求并校驗權限后，通過procfs/ioctl操作真實硬件，兩者均通過VirtIO通道通信。

同時，VirtIO-SCMI目前存在部分限制與要求：前端虛擬機需要選擇合適的內(nèi)核版本，后端虛擬機需要提供操作真實的硬件的procfs或者ioctl接口，并確保并發(fā)訪問的原子性。

基于上述情況，vmRT-Thread可進行如下具體操作：

示例1

將VirtIO-SCMI前端虛擬機中某個uart中的clk，reset，pinctrl替換為VirtIO-SCMI。

大致步驟如下：

1. VirtIO-SCMI前端虛擬機需要修改設備樹：

• 首先需要增加scmi的clk，reset，pinctrl的子協(xié)議設備樹節(jié)點

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";};};};};

• 然后對應串口的設備樹節(jié)點，需要引用scmi的clk，reset，pinctrl的子協(xié)議設備樹節(jié)點，其中clk，reset還需要通過參數(shù)來提供索引號。

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的子協(xié)議設備樹節(jié)點

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

• 然后對應CPU的設備樹節(jié)點中的頻率屬性需要引用scmiperf子協(xié)議設備樹節(jié)點，同時還需要通過參數(shù)來提供索引號。

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固定頻率提升之后，跑分測試分數(shù)從3011.594639提升到17049.329393，符合預期。
   

效果圖1

效果圖2

該方法基于VirtIO-SCMI的嵌入式虛擬化解決方案，通過將硬件資源訪問虛擬化，使前端虛擬機只需通過VirtIO-SCMI協(xié)議轉發(fā)請求，而后端驅動虛擬機通過procfs/ioctl統(tǒng)一處理真實硬件操作，既實現(xiàn)了多虛擬機間的資源隔離與安全管控，又避免了重復移植clock/power等驅動，為車載、物聯(lián)網(wǎng)等需要嚴格外設隔離的場景提供新路徑。