2.4.3  關(guān)鍵技術(shù)解讀

1.  CPU 虛擬化和節(jié)能降耗技術(shù)

車載高性能處理器一般采用多核 CPU 架構(gòu)。在 SMP（Symmetric Multi-Processing 對稱多處理） 架構(gòu)下，Hypervisor 調(diào)度器會根據(jù) CPU 的親和性配置讓客戶機操作系統(tǒng)在指定的 CPU 上運行，虛擬機的操作系統(tǒng)可按照自己的調(diào)度方式，比如 : ：優(yōu)先級方式在 CPU 上進行任務(wù)調(diào)度。為了最大化地利用系統(tǒng)資源，Hypervisor 也支持多個虛擬機對某個 CPU 的共享使用。在共享核上，Hypervisor 可通過優(yōu)先級或時間分區(qū)方式對虛擬機進行調(diào)度，確保虛擬機運行時間和調(diào)度策略是確定的。Hypervisor 的調(diào)度算法需要確保不能夠出現(xiàn)分區(qū)內(nèi)某個虛擬機出現(xiàn)死循環(huán)或故障而長期占用處理器資源，導(dǎo)致其他虛擬機的業(yè) 務(wù)無法得到合理時間配額的問題。

虛擬機調(diào)度還需要考慮節(jié)能降耗問題，在工作負載較高的情況下系統(tǒng)提升主頻提升用戶體驗，在工 作負載較低的情況下系統(tǒng)自動節(jié)能降頻提升續(xù)航。車載高性能處理器本身為了節(jié)能降耗需求設(shè)計為大小 核架構(gòu)，CPU 以及之上運行的復(fù)雜操作系統(tǒng)需要支持大小核調(diào)度，動態(tài)調(diào)頻，低功耗設(shè)置，關(guān)閉 CPU 核， 休眠（Suspend to RAM/Suspend to Disk）等節(jié)能降耗功能。系統(tǒng)虛擬化后，CPU 等物理資源都需要Hypervisor 才能直接訪問，Hypervisor 調(diào)度算法也需要完成對虛擬機節(jié)能降耗的支持。

2.  IO 設(shè)備虛擬化

出于性能考慮，一般嵌入式領(lǐng)域多使用半虛擬化技術(shù)。半虛擬化技術(shù)需要 Guest OS 中的前端驅(qū)動與Hypervisor 中的后端驅(qū)動配合實現(xiàn)。前端驅(qū)動將 Guest OS 的請求通過 Hypervisor 提供的通信機制發(fā)送給后端驅(qū)動，后端驅(qū)動通過調(diào)用物理驅(qū)動實現(xiàn)對設(shè)備的訪問。這就涉及到不同廠商的 Guest OS 與不同廠商的 Hypervisor 生態(tài)對接問題。

Virtio 是目前最流行的一種 I/O 半虛擬化解決方案。Virtio 是 OASIS 標(biāo)準組管理的開放協(xié)議和接口，以使得虛擬機能夠標(biāo)準化方式訪問 IO 設(shè)備。Virtio 于 2016 年 3 月正式標(biāo)準化，2020 發(fā)布 V1.1 版本。Virtio 標(biāo)準采用通用和標(biāo)準化的抽象模型，支持設(shè)備類型不斷增加，性能高效，在云計算領(lǐng)域廣泛應(yīng)用， 開源活躍度高，Linux 等操作系統(tǒng)已有穩(wěn)定的前端驅(qū)動代碼。大部分商業(yè)和開源 Hypervisor 都已經(jīng)支持Virtio 標(biāo)準。

Virtio 是車載行業(yè)比較常用的半虛擬化技術(shù)的實現(xiàn)，如圖 2.4-6 所示，在 Guest OS 內(nèi)部虛擬一條設(shè)備總線 Virtio-bus，通過 Virtio Ring 雙向通信機制，前端驅(qū)動與掛載在 Virtio-bus 上遵循 Virtio 標(biāo)準的后端虛擬設(shè)備，進行訪問與通信。Virtio 提供了全面的 Virtio 總線和設(shè)備控制接口，包括 virtio-net，vir- tio-blk，virtio-console，virtio-input 等。

圖 2.4-6Virtio虛擬化實現(xiàn)模型

·  利用 virtio-blk 技術(shù)實現(xiàn)塊設(shè)備共享

塊設(shè)備是使用緩存機制讀寫的存儲設(shè)備，分配給 Hypervisor 所在的操作系統(tǒng)進行管理。virtio-blk driver 是符合 virtio 標(biāo)準的塊設(shè)備驅(qū)動，vdev virtio block 是后端的虛擬塊設(shè)備，virtio  blk  driver 通過該vdev 設(shè)備完成對物理塊設(shè)備的讀寫，并獲取執(zhí)行結(jié)果。

·  利用 virtio-net 技術(shù)實現(xiàn)跨系統(tǒng)通信

Virtio-net 實現(xiàn)了多系統(tǒng)間點對點的通信，Guest 系統(tǒng)內(nèi)部的 virtio-net driver 通過 virtqueue 與Hypervisor 所在系統(tǒng)的 virtio-net 設(shè)備進行全雙工通信，實現(xiàn)多系統(tǒng)之間的控制類、配置類的指令、數(shù)據(jù)的交互。適合音視頻流以外的數(shù)據(jù)傳輸，穩(wěn)定性較好，因 virtqueue 的控制邏輯復(fù)雜，對實時性有一定影響。

·  利用 virtio 技術(shù)實現(xiàn)觸摸共享

觸摸設(shè)備是字符型設(shè)備，通過 virtio-input driver、vdev-input 實現(xiàn)前端驅(qū)動和后端設(shè)備。設(shè)備端通過 virtqueue 向驅(qū)動上報觸摸坐標(biāo)數(shù)據(jù)。

3.  實時性技術(shù)

實時性是嵌入式實時操作系統(tǒng)的關(guān)鍵性能指標(biāo)。Hypervisor 的實時性是整個系統(tǒng)實時性的基礎(chǔ)，如果 Hypervisor 無法及時調(diào)度到客戶機操作系統(tǒng)運行，客戶機操作系統(tǒng)也不能取得較好的實時性指標(biāo)。衡量 Hypervisor 實時性主要指標(biāo)包括中斷延遲和調(diào)度延遲。中斷延遲以硬件發(fā)生中斷時刻為起始時間，以虛擬機收到 Hypervisor 注入的中斷時刻為截止時間，在各種壓力情況下最長延時時間即為中斷延時。調(diào)度延遲是指以高優(yōu)先級的虛擬機進程就緒為起始時刻，以該高優(yōu)先的虛擬機進程得到調(diào)度運行為截止時刻，在系統(tǒng)各種壓力情況下最長的延時時間即為調(diào)度延遲。

中斷虛擬化后，當(dāng)外界中斷產(chǎn)生時，Hypervisor 收到并以最快的速度注入到虛擬機，使得 Hypervi- sor 對虛擬機中斷處理時間足夠少。Hypervisor 優(yōu)化虛擬機的切換時間，盡量減少 Hypervisor 上關(guān)中斷和關(guān)搶占的時間，盡量少使用內(nèi)核鎖，當(dāng)高優(yōu)先級的虛擬機需要切換運行時，能最快速度切換至高優(yōu)先級虛擬機上運行。

4.  安全和可靠性技術(shù)

功能安全、信息安全和可靠性是車控操作系統(tǒng)產(chǎn)品可靠安全運行的必要組成部分。Hypervisor 為智能汽車域控制器提供基礎(chǔ)運行環(huán)境，其安全性和可靠性是保證整個系統(tǒng)功能安全和可靠的基礎(chǔ)和核心。Hy- pervisor 需按照汽車功能安全 ISO26262  ASIL-D 最高標(biāo)準進行設(shè)計，開發(fā)和測試，其功能安全需求由域控制器產(chǎn)品的安全需求分解產(chǎn)生。

Hypervisor 上運行了多個虛擬機，一個虛擬機的異常不能傳遞至其他虛擬機。Hypervisor 能獲取到當(dāng)前系統(tǒng)整體健康狀態(tài)，當(dāng)虛擬機發(fā)生異常時，Hypervisor 應(yīng)實時監(jiān)控系統(tǒng)健康狀態(tài)，有效地隔離故障， 并在最小波及范圍內(nèi)修復(fù)異常，保障系統(tǒng)持續(xù)可用。

Hypervisor 加入汽車軟件棧，會導(dǎo)致縱向上軟件棧層次增加，橫向上業(yè)務(wù)軟件復(fù)雜度增加，而汽車的安全可靠要求強于既有的云側(cè)虛擬化、邊緣虛擬化，因此虛擬化安全性正日益得到行業(yè)的關(guān)注。這些安全性包括：

·  虛擬機管理器和虛擬機之間的信任鏈問題。利用虛擬化技術(shù)在一個可信物理平臺上創(chuàng)建出多個虛擬機，并將從硬件可信根開始構(gòu)建的信任鏈傳遞到每一個虛擬機，從而在一個可信物理平臺上構(gòu)建多個虛擬的可信計算平臺，有些解決方案缺乏虛擬機管理器到虛擬機之間的信任鏈驗證；

·  虛擬機間的攻擊：惡意入侵者可以通過利用虛擬機管理程序中的漏洞，通過同一物理主機上存在的另一個虛擬機來獲得對虛擬機的控制，從而破壞目標(biāo)虛擬機；

·  虛擬機逃逸：利用虛擬機軟件或者虛擬機中運行的軟件的漏洞進行攻擊，以達到攻擊或控制虛擬機宿主操作系統(tǒng)的目的。

為了提高 Hypervisor 的安全性，建立相應(yīng)的安全性目標(biāo)很重要，表 2.4-1 簡要列出相關(guān)要求：

表2.4-1 安全性目標(biāo)

Hypervisor 的安全性能力可以從三個維度進行提升。

(1) 需要建立安全邊界

如圖 2.4-7 所示，這個邊界由 Hypervisor 嚴格定義并且實施。Hypervisor 安全邊界的保密性、完整性和可用性需要得到保證。邊界能防御一系列攻擊，包括側(cè)向通道信息泄漏、拒絕服務(wù)和特權(quán)提升。虛擬機監(jiān)控程序安全邊界還提供網(wǎng)絡(luò)流量、虛擬設(shè)備、存儲、計算資源和所有其他虛擬機資源的隔離能力。

圖2.4-7 安全邊界

整體虛擬化安全架構(gòu)如圖 2.4-8 所示。安全邊界的保密性可以通過傳統(tǒng)的密碼學(xué)方法來實施。完整性通過可信度量機制來保障，可信報告機制實現(xiàn)不同虛擬環(huán)境的可信互通，監(jiān)控機制動態(tài)度量實體的行為， 發(fā)現(xiàn)和排除非預(yù)期的互相干擾。虛擬技術(shù)提供的隔離機制將實體運行空間分開。

圖2.4-8 整體虛擬化安全架構(gòu)

安全邊界的隔離通過Hypervisor 的vCPU 調(diào)度隔離安全、內(nèi)存隔離、網(wǎng)絡(luò)隔離和存儲隔離技術(shù)來支持， 實現(xiàn)了同一物理機上 Hypervisor 和虛擬機、虛擬機之間的隔離。

(2) 需要建立深度防御漏洞的緩解機制

對于安全邊界存在的潛在漏洞，Hypervisor 需要有一定的技術(shù)手段進行主動防御，這些技術(shù)手段包括地址空間布局隨機化（ASLR）、數(shù)據(jù)執(zhí)行保護（DEP）、任意代碼保護、控制流保護和數(shù)據(jù)損壞保護等。

(3) 建立強大的安全保障流程

與 Hypervisor 相關(guān)的攻擊面包括虛擬網(wǎng)絡(luò)、虛擬設(shè)備和所有跨虛擬機表面，所有虛擬機攻擊面都建議實施威脅建模、代碼審核、模糊（fuzzed）測試，通過建立自動化構(gòu)建及環(huán)境，觸發(fā)定期安全檢查。

虛擬化技術(shù)作為云計算場景的重要技術(shù)，在 10 多年的生產(chǎn)實踐中已經(jīng)積累了很多安全范式，這些經(jīng)驗也可被汽車場景借鑒。但是與云場景相比，汽車場景的虛擬化技術(shù)也有其特殊性，如虛擬機不需要動態(tài)遷移 / 創(chuàng)建，Hypervisor 有功能安全等級的要求等等，其安全性手段需要在實踐中不斷豐富和完善。

2.4.4  典型應(yīng)用案例

在汽車智能化發(fā)展歷程中，虛擬化主要應(yīng)用于智能座艙、智能駕駛、智能網(wǎng)關(guān)等融合場景。智能駕駛受技術(shù)成熟度、政策法規(guī)所限，基本處于預(yù)研、方案原型階段。智能網(wǎng)關(guān)業(yè)務(wù)功能相對同構(gòu)，并且有可能進一步融合到其他場景方案中。因此，目前主要的應(yīng)用案例集中在智能座艙中。

智能座艙域融合也是在近幾年啟動，正在不斷迭代演進中。受芯片算力、虛擬化技術(shù)成熟度、生態(tài)鏈對于虛擬化解決方案的掌控能力等因素影響，有些廠商同時采用了硬隔離方案來實現(xiàn)域融合，一方面最大程度地沿用既有技術(shù)能力，有確定性保障，但是缺少了軟件定義的靈活性，智能化程度有限，是域融 合的一種可選方案。在嵌入式虛擬化技術(shù)方面，國外的 QNX、OpenSynergy、PikeOS  等有先發(fā)優(yōu)勢，尤其在汽車領(lǐng)域已耕耘多年，因此在這兩年涌現(xiàn)了較多的應(yīng)用案例。在智能本土化發(fā)展的趨勢帶動下，國內(nèi)這幾年也出現(xiàn)了不少芯片廠商、獨立軟件廠商研發(fā)嵌入式虛擬化技術(shù)、產(chǎn)品、解決方案，如中瓴智行的 RAITE Hypervisor(RHOS)、中興 GoldenOS、斑馬智行的 AliOS Hypervisor、中汽創(chuàng)智 CAIC Hypervi-sor 等。

1.  智能座艙域控制器產(chǎn)品

某廠家智能座艙域控制器產(chǎn)品，如圖 2.4-9 和圖 2.4-10 所示，基于高通 8155、瑞薩 R-Car H3 處理器，采用 QNX Hypervisor，搭載QNX Host、Android P/R/S Guest OS, 可配置輸出最多 6 塊高清大屏獨立顯示，集成了娛樂系統(tǒng)、液晶儀表、車身控制、DMS、APA   等功能，支持獨立四音區(qū)、多屏互動和音視頻分享，集成度高，在長城、長安、宇通客車等多款車型上適配量產(chǎn)。

另外，國產(chǎn)化方案芯馳 X9HP+ 平臺，采用硬分區(qū)、Hypervisor 兩種方案靈活配置實現(xiàn)中低端智能座艙域控制器產(chǎn)品。

圖 2.4-9智能座艙域控制器

圖2.4-10國產(chǎn)化方案智能座艙域控制器

2.  RHOS 智能座艙域控制器平臺

(1) NXP I.MX8QM 座艙域控制器

某廠家基于自研的 Type-1 型虛擬化軟件 RHOS(Raite Hypervisor OS)，適配支持了 NXP I.MX8QM， 提供一個輕量、靈活的汽車智能座艙虛擬化解決方案，已在東風(fēng)車型量產(chǎn)上市。其系統(tǒng)架構(gòu)如圖 2.4-11 所示：

圖 2.4-11 NXP I.MX8智能座艙系統(tǒng)架構(gòu)

在 SoC 上運行 Hypervisor 后可支持同時運行多個操作系統(tǒng)，比如 Linux 系統(tǒng)可以運行實時性和安全性較高的業(yè)務(wù)，如全液晶儀表等，可以擴展運行 DMS、HUD 等業(yè)務(wù)。另外一個虛擬機運行 Android 操作系統(tǒng)，上面部署信息娛樂等安全性和實時性要求較低的業(yè)務(wù)。為保證系統(tǒng)具備良好的市場競爭力，域控制器兼容 TBOX 功能需求，系統(tǒng)能夠支持休眠喚醒和快速啟動。

Linux 和 Android 虛擬機可按需進行資源的配置，包括內(nèi)存、CPU、存儲空間、外設(shè)等。該架構(gòu)支持系統(tǒng)升級，包括對虛擬機和 Hypervisor 的升級，支持異常日志記錄，包括虛擬機內(nèi)核和 Hypervisor 日志。

多屏交互是智能座艙重要的應(yīng)用場景，Android 的 APP 應(yīng)用程序可以通過 Hypervisor 推送到 Linux 儀表進行顯示。

圖2.4-12 虛擬機多屏交互架構(gòu)

Android 和 Linux 儀表交互的方案如圖 2.4-12 所示。NXP I.MX8QM 芯片有兩個以上顯示接口，每個顯示接口可以接 2 個顯示屏，當(dāng) Android 系統(tǒng)需要投射信息到儀表屏幕時，儀表顯示屏的 Overlay 圖層可以進行投屏內(nèi)容的顯示。系統(tǒng)交互零延遲、零拷貝，多系統(tǒng)交互不額外占用 CPU 和 GPU 資源。通過Hypervisor 虛擬化技術(shù)實現(xiàn)跨系統(tǒng)多屏交互，有效提高了行車安全性，并降低智能座艙的硬件成本。

（2） MT8675 座艙域控制器

RHOS 通過適配支持MT8675，形成一個功能豐富、性價比高的一機多屏智能座艙域控制器解決方案，已獲得多個車廠量產(chǎn)項目。

其總體系統(tǒng)架構(gòu)如圖 2.4-13 所示：

圖2.4-13 MT8675智能座艙系統(tǒng)架構(gòu)

MT8675 只提供了一個 GPU，座艙域需要在儀表和中控上共享使用 GPU 資源。RHOS 實現(xiàn)了 GPU 虛擬化共享，并通過性能優(yōu)化，達到業(yè)界領(lǐng)先的虛擬化效果（損耗 < 6%）。RHOS 支持 Suspend to RAM 功能，MT8675 A 核完全下電，滿足智能座艙待機靜態(tài)功耗小于 4mA 要求。

3.  KCS 3.0 智能座艙虛擬化平臺

某廠家基于 Renesas H3/M3 + QNX Hypervisor2.x 開發(fā)了支持 “一芯多屏” 的 KSC3.0 智能座艙虛擬化平臺 , 可實現(xiàn)在一顆 SOC 上同時運行 QNX 儀表、Android 中控及副駕等多個系統(tǒng)，并支持以下特性：

• 4 個屏幕同時輸出

• 多系統(tǒng)實時 3D 渲染

• 多屏共享

• 儀表和 IVI 間音樂、地圖應(yīng)用的多屏互動，

• 快速啟動：<2s

• 人臉及情緒識別等

  
  

平臺展示如圖 2.4-14 所示

圖2.4-14 KCS 3.0智能座艙虛擬化平臺

此外，該廠家還基于 X86+KVM+QEMU 開發(fā)了數(shù)字孿生平臺，通過虛擬化技術(shù)來模擬硬件開發(fā)平臺， 包括支持多路 Camera、多路顯示輸出、多系統(tǒng)音頻混音，屏幕共享以及多路 CAN 信號等，能夠很好地解決 SOA 平臺開發(fā)過程中開發(fā)人員對于真實硬件平臺的依賴。

識別二維碼或點擊閱讀原文下載：
《中國汽車基礎(chǔ)軟件發(fā)展白皮書》