本文主要分析了Hypervisor的主要概念、可靠程度以及在智能座艙中的應用。

第一次接觸Hypervisor大約是2003年左右，在Linux上通過VMware運行Windows；2007年在聯想花了一個月研究Xen/KVM在服務端的應用，再往后幾年放棄了Linux桌面。

離開了研發團隊就再也沒有了同時運行多個系統的需求，虛擬化技術被拋到腦后，看到Hypervisor在終端設備上的應用，我第一反應是虛擬化還可以這么玩！

為了便于大家理解這個概念，我再舉個不準確的例子。

一個計算機假設有10億個計算單元，每次執行任務時只能只有1億個被用到，這時我們可以假設這個1計算機是10個計算機。這10個計算機可以同時做不同的事，比如一臺運行財務用、一臺運行開發用，但兩用戶互不影響。這種利用空閑資源的各種辦法就叫虛擬化（Hypervisor）。

用于互聯網用戶而言，現在我們每時每刻都在使用基于Hypervisor的互聯網云服務。云服務使用虛擬化技術的核心目的是可以動態分配資源，可以有效利用空閑資源。相當于自行車的分時租賃，每個人都交了押金，但自行車依然閑置，上下班的時候根據使用情況再調度。先簡單的理解為有隔離計算能力的分時復用吧。

與云平臺商業化運作的不同，車輛中虛擬化產品面對的不是動態的用戶，而是各種相對固定的計算任務。算力分配在產品出廠前就已經固定，算力即不會過度閑置，也不會過度緊張，也不會動態調配，更不存在利用閑置資源進行商業變現的機會。

在汽車電子電氣系統中，不同的功能單元需要不同的服務、有不同的優先級、有不同的計算安全冗余而存在。特別是需要將各種計算單元進行整合、算力共享，最終通過Hypervisor來完成降低成本。相當于以前我買五六個大件ECU，現在只需要一個，省去了大量的線束、接插件、多次生產、多次研發、多次測試的成本，減輕了車身整體重量。

未來域樂域控制器、自動駕駛域控制器、中央計算機里面都可能會使用Hypervisor技術。汽車行業對于有逼格的東西一向抱有著警惕的眼神的，Hypervisor這個很少會被翻譯成中文的名稱，背后就隱藏著滿滿的逼格，比Superman還要高一個檔次。

幸好汽車行業對能省錢的東西還是喜歡的緊（考慮到自己有很長一段時間沒有上手具體技術，我盡量對與技術相關的內容作價值分析，但實在看不懂相關技術，請直接跳到最后點打賞或在看）。

一、Hypervisor的主要概念

虛擬機（Hypervisor/Virtual Machine）是在同一硬件機器上，允許運行多個相互隔離的不同系統的軟件技術。

虛擬化對隱藏了真實的計算機硬件，可以自已模擬成為另一種計算平臺（為了更直觀，大家看一下在Mac OS上運行Windows，來自parallels官網）。

1. 虛擬化的分類

1. 應用程序的虛擬化：比如JAVA VM，其本質是對二進制的轉換；
2. 操作系統的虛擬化：比如容器/Docker技術，其本質利用對特定進程可用的算力、存儲、IO資源的管理，幾乎沒有額外系統開銷，在云服務中使用較多；
3. 硬件虛擬化：比如Xen，KVM，對算力及IO的影響小，額外開銷成本少。KVM是目前云計算虛擬化的主力。

虛擬化的TYPE-1與TYPE-2

• TYPE1類型的虛擬機，直接運行的硬件基礎上，比如XEN。
• TYPE2類型的虛擬機，是在完整的OS上進行上進行，比如KVM。

對于最新的Hypervisor技術。無論TYPE1類型還是TYPE2類型，都可以采用硬件輔助加速功能。在汽車領域，由于算力限制、實時性要求高，多數據情況會使用硬件虛擬化技術，即TYPE1。

2. 硬件虛擬化的思路與方案

• 全虛擬化（Full-Virtualized）：依賴硬件虛擬化技術，不需要修改被虛擬系統的內核。
• 半虛擬化（Para-Virtualized)：不依賴硬件虛擬化技術，需要修改被虛擬系統的內核。
• 透傳（Pass Through）:直接使用物理設備，不經過虛擬監管程序。

PV和FV都是用來描述設備被虛擬/模擬的程度，PT是直接使用物理設備，未進行虛擬化。

為什么我們使用虛擬化支持？是因為大多數的設備不支持并發性的訪問。

為了并發訪問設備，全虛擬化的設備將被完全仿真（所有功能），所有操作系統都不能直接訪問該物理設備，所有的操作都要通過虛化監管程序協助執行，效率明顯較低。

PV通過抽象理想的物理設備，采用分離設備驅動模型的方式，該模型將設備驅動分為前端驅動，后端驅動，其中前端驅動運行在guest os中，而后端驅動運行在hypervisor中，前端通過共享內存的方式交換數據，來提高效率。

通常半虛擬化性能通常高于全虛擬化，其性能非常接近設備的物理性能。常用用于PV的框架有VirtIO，來標準化半虛擬設備。

考慮到傳統虛擬化技術中共享物理平臺的I/O效率低下，在有足夠I/O硬件可用的情況下，通過將I/O物理設備直接分配給虛擬機，虛擬機監視器不再干涉其訪問獨占的I/O物理設備，我們將這種方式稱之為Pass Through(PT)。

PT模式，可以利用使用最新的驅動，充分發揮新硬件的功能；PV、FV面向新設備時，除了額外開銷，都存在驅動更新問題。

同時如果硬件本身支持并發訪問的話，XEN可借助件硬輔助虛擬化進一步減少虛擬化負責，增強虛擬化性能。

3. 支持硬件虛擬化的CPU

硬件虛擬化技術依賴于CPU與GPU等硬件設備的支持。X86架構世界的虛擬化在Intel與AMD的配合下高度一下，選擇多樣。

但是根據《智能座艙選擇怎么樣的SOC算力？》我們知道：汽車領域SOC都是ARM架構，ARM對虛擬化支持如何？

在2011年開始ARM v7-A和ARM v8-A體系結構包括可選的虛擬化擴展。

4. 汽車界虛擬化的軟件

針對ARM架構，Xen是一款即支持半虛擬化，又支持全虛擬化的虛擬化軟件。

可以使用ARM 硬件虛擬化擴展，支持全虛擬化方式運行，操作系統可以使用真實的設備驅動與真實的虛擬硬件直接通信，盡可能減少使用Hypervisor接口調用中仿真操作帶來的開銷。

除了Xen之外，還有Opensynergy、ACRN Hypervisor、Global Hypervisor、Mentor Hypervisor、QNXHypervisor、Redbend Hyeprvisor。

但目前真正有量產車型的虛擬機好象只有QNX的Hypervisor，它是目前市場上唯一被認可功能安全等級達到ASIL D級。

5. 支持GPU的虛擬化

進行虛擬化為是了串行硬件設備的復用，并行處理。與CPU的串行模型完全不同，GPU是并行編程模型。為了使用GPU的能力，我們通常使用OPEN GL、OpenCL或者GPU自身支持API來進行圖形應用的開發。

GPU虛擬化方案常有以下三種模式（類似于CPU）：

PowerVR的GPU虛擬化是完整的硬件虛擬化解決方案，其中每個Guest OS都有完整的驅動程序堆棧，并可以直接向GPU提交任務硬件。該解決方案不需要用于任務提交的管理程序干預，導致最大的利用率可用的GPU資源。 PowerVR GPU最多可以支持八個虛擬機，每個操作系統可以是獨立并行運行。

（Mail和Adreno的虛擬化資料我沒有怎么查，不了解情況。）

二、Hypervisor靠譜嗎

聽到虛擬機大家可能首先想到的是被人多有詬病的JAVA虛擬機，因為執行過程中存在二進制解釋過程，速度慢是其帶自帶屬性。

車載硬件算力受限，大家也沒有見過哪個手機運行過虛擬機，Hypervisor速度是不是會對計算機的性能帶來很大的影響？對于新技術應該認真思考是不是靠譜，即不自大也不盲從。

車載硬件算力受限，類似大家也沒有見過手機運行過虛擬機，Hypervisor速度是不是會對計算機的性能帶來很大的影響？

答：不會的。

汽車產品的虛擬化一般指的是硬件虛化化技術，開銷較小，通過CPU負載不超過2%，DDR小于20MB，EMMC小于50MB。大數的Hypervisor技術代碼量在3萬行以內，Xen的代量較大在30萬量級。

既然在云服務中虛擬化技術已經被廣泛的使用，那是不是說在終端產品的中使用很成熟？

答：不是的。

首先，云服務和終端產品采用Hypervisor技術的需求與目的完全不同；其次，ARM的指令集、異構運算、能耗管理不同；再次汽車功能安全要求標準不同；最后虛擬化技術在汽車領域還沒有進行過大規模的量產應用。

虛擬化技術可以省多少成本？

答：理論上來講可以降本。

從產品設計的角度來說，能降多少成本的關鍵在于能將多少個分布式ECU整合到域控制器中。需要進行綜合衡量。

但是由于目前主要主要使用的是QNX Hypervisor + QNX儀表+ Kanzi的組合，從入門費、席位費、服務費、授權費到其他開發成本，以及有效的技術支持，從短期來看單臺成本降低可能沒有想的那么大，但綜合來看還是值得的。

三、Hypervisor在智能座艙中的應用

Hypervisor的復雜性與影響因子很多，為什么還要在智能座艙中使用Hypervisor技術。

因為降本需求，在單個SOC上運行多個不同安全級別的操作系統最便宜（當然不是因為車內屏幕數量的增加）。

在智能座艙的想象中，假定我們運行四個系統，儀表是安全ASIL B，信息娛樂系統是ASIL QM，L0-L2級的ADAS屬于ASILB或C、以及HUD系統。

這意味著我們可能需要運行三個或者四個不同的系統（儀表和HUD可能會共用一個系統，該系統支持分屏幕輸出）。

作者：updatedb；公眾號：強哥的面包屑? /??MyCrumbs。

本文由 @updatedb 原創發布于人人都是產品經理。未經許可，禁止轉載

題圖來自Unsplash，基于CC0協議