【原】Hypervisor，艙駕融合路上的“務虛公子”

十一號組織 2023-02-14 發(fā)布于上海

展開全文

喊出一句架構升級的口號，給新架構取個響亮的名字，隔三差五在媒體面前吹噓一番，似乎是近幾年主機廠樂此不疲的事情。具不具備自動駕駛能力，外界可以通過對產(chǎn)品360°路測進行一個直觀的評價。但架構升級成果如何，更像是大家族兄弟姐妹間爭奪家產(chǎn)的私家事，表面上一片祥和，背地里暗流涌動。外人也只能從家丁、護院、婢女的口中聽聞些許八卦。

筆者剛好也從坊間聽聞了這樣一則八卦，熱衷于架構升級的某主機廠，花了幾十億，歷經(jīng)四五年，從分布式架構升級到域架構。熬到首臺車量產(chǎn)時，一位多事的員工細數(shù)域架構內(nèi)的ECU數(shù)量，驚訝的發(fā)現(xiàn)原來ECU員工編制一個沒少，反而多出了幾個域控制器領導編制。說好了的融合，新增的域控制器領導也僅是承擔了替代ECU的職責以及整車新增的部分需求。這與分布式架構下，新增需求升級/新增ECU似乎并無兩異。

踩坑的先行者們，開始逐漸清醒，BOSCH學院派的架構演進路線上的域架構作為一種過渡狀態(tài)，似乎并不是那么美麗，有點類似自動駕駛領域的SAE L3自動駕駛，看起來容易做起來難。于是乎，這部分先行者又著急地喊出了一步到位中央集中式架構的口號，像極了前兩年自動駕駛公司集體放棄SAE L3，進攻SAE L4的景象。

從幾家宣傳的中央集中式架構方案中，智能座艙和自動駕駛相關功能將集中到一個高性能計算單元上，并跑在在一顆SOC上，主動安全及功能降級策略放在另外一顆安全MCU上執(zhí)行。上海嘉定創(chuàng)新港內(nèi)喊出的“銀河全棧3.0”中央集中式方案便是由兩個高性能計算單元（HPC1和HPC2）和四個區(qū)域控制器構成（Zone1~4）。其中HPC1便負責智能座艙、自動駕駛的功能，HPC2部分職責是承擔自動駕駛備份控制作用。

在這種中央集中式架構下，意味著一個SOC上將同時運行智能座艙和自動駕駛等功能。而智能座艙和自動駕駛功能不論是在功能安全、信息安全、實時性還是算力需求層面都有不小的差異，且這些功能目前都是用不同的操作系統(tǒng)（Linux、QNX、Android、RTOS等）去實現(xiàn)。如果汽車行業(yè)統(tǒng)一的操作系統(tǒng)不能盡快誕生（目測也不會誕生），那么一顆SOC上如何部署多個不同的操作系統(tǒng)，成為中央集中式架構必須直面的問題。

還好這個問題，互聯(lián)網(wǎng)領域曾經(jīng)遇到過，并且已經(jīng)成熟應用，可以說是超級奶爸一般的存在。汽車領域僅在智能座艙域得到過成功應用，妥妥的新上門女婿。自動駕駛圈黑話第二十期，作者就和大家一起討論下這位在汽車行業(yè)嶄露頭角，并有希望解決艙駕融合過程痛點的虛擬化關鍵技術—Hypervisor。

什么是Hypervisor

要回答“什么是Hypervisor”,我們不得不扒一扒其在互聯(lián)網(wǎng)領域成名的黑歷史。

早些年，如果某家公司想搭建郵件系統(tǒng)和文檔管理兩個應用，則需要購買兩臺服務器，每臺服務器運行一個應用。這個時候每個服務器性能剛好夠每個應用揮霍，應用在物理上又完全隔離，互不干擾，一派祥和。但在摩爾定律的見證下，服務器性能基本上每兩年翻一番，單位計算能力的成本卻在不斷下降。在某個時間點，便出現(xiàn)了這樣一個甜蜜的煩惱，我在市面上能買到的最低配置的服務器性能也夠我的兩個應用同時使用。

如果兩個應用裝在一臺服務器上，不但資源調用可能發(fā)生沖突，維護起來也很麻煩。但是如果我買兩臺服務器的話，性能浪費上像極了大炮打蚊子，金錢浪費上像極了地主家的傻兒子。如何解決一臺服務器運行多個相互隔離的不同操作系統(tǒng)應用的問題，成為了擺在互聯(lián)網(wǎng)發(fā)展道路上的巨大障礙。

但在互聯(lián)網(wǎng)領域前輩前赴后繼的努力下，終于找到了克服障礙的方案：虛擬化技術。通過虛擬化技術，可以在一臺物理服務器上模擬出多個具有完整硬件配置并運行在完全隔離環(huán)境中的計算機系統(tǒng)。這個模擬的計算機系統(tǒng)也就是我們平時親切稱呼的虛擬機（VM，Virtual Machine）。

汽車領域開發(fā)工程師對虛擬化技術多少都有過接觸。如果你是一名車聯(lián)網(wǎng)JAVA開發(fā)工程師，那么你肯定用過JAVA VM，這是一種應用程序虛擬化技術；如果你是一名自動駕駛集成開發(fā)工程師，那么你應該會和Docker相愛相殺過，這是一種操作系統(tǒng)虛擬化技術；如果你是一名大數(shù)據(jù)平臺開發(fā)工程師，那么KVM似乎是你繞不過去的坎，這是一種硬件虛擬化技術。

但是誰去負責虛擬機的虛擬資源和物理硬件之間的轉換工作，誰去負責虛擬機的創(chuàng)建、刪除、配置呢，這便是本文主角Hypervisor的職責,中文直譯就是“超級監(jiān)督者”，一類具有此類職責軟件的總稱。

Hypervisor將全面接管物理服務器的CPU、內(nèi)存、硬盤、網(wǎng)卡等硬件資源，并把他們抽象成邏輯資源池，并按需分配給每個虛擬機。通過Hypervisor的這一番神奇操作，每個虛擬機都能獨立使用自己的虛擬CPU，內(nèi)存，硬盤，網(wǎng)卡等硬件資源。

互聯(lián)網(wǎng)領域常用的Hypervisor類型主要有兩種，Type 1（裸機類型）和Type 2（寄居類型），如下圖所示。

在Type 1中，Hypervisor直接運行在物理硬件之上，向下直接管理所有硬件資源，向上通過Hypervisor創(chuàng)建多個虛擬機，在虛擬機上安裝操作系統(tǒng)及部署應用；

在Type 2中，物理硬件上先安裝一層操作系統(tǒng)，利用操作系統(tǒng)管理所有硬件資源，操作系統(tǒng)上再安裝Hypervisor，后面操作同Type 1。（如果你有過在Windows電腦安裝虛擬機，然后在虛擬機上安裝Linux操作系統(tǒng)經(jīng)歷的話，那么你對Type 2的印象肯定刻骨銘心。）

Type 1類型的Hypervisor直接運行在物理硬件之上，直接訪問物理硬件并管理所有硬件資源，在延時、安全性和效率上更勝一籌。但此類型Hypervisor需要硬件支持，移植難度大，開發(fā)成本也較高，在互聯(lián)網(wǎng)領域常用于數(shù)據(jù)計算中心。

Type 2類型的Hypervisor運行在某個操作系統(tǒng)之上，利用操作系統(tǒng)訪問物理硬件，因此在延時方面具有不可避免的劣勢。且底層操作系統(tǒng)的任何Bug都將危及其上的虛擬機，因此安全性方面相對較弱。但是移植難度小，開發(fā)成本低。在互聯(lián)網(wǎng)領域常用于客戶端系統(tǒng)。

在汽車領域，由于變態(tài)的實時性及安全性要求，目前主流選擇Type 1方案。Hypervisor除了上文提到的硬件資源分配功能，還具有如下功能。

（1）設備模擬。Hypervisor可以創(chuàng)建客戶操作系統(tǒng)可以訪問的一些虛擬硬件組件，是否需要取決于客戶操作系統(tǒng)上運行的應用程序；

（2）內(nèi)存管理。Hypervisor負責為自身和客戶操作系統(tǒng)管理和分配硬件內(nèi)存資源；

（3）設備分配和訪問。Hypervisor通?？梢詫⒂布M件分配給客戶操作系統(tǒng)，并控制客戶操作系統(tǒng)實際可以訪問哪些硬件組件；

（4）上下文切換。當Hypervisor需要在內(nèi)核上安排新的客戶操作系統(tǒng)時，Hypervisor必須通過將在該處理器內(nèi)核上運行的現(xiàn)有客戶操作系統(tǒng)的“上下文”（即操作條件）保存到內(nèi)存中來“切換上下文”。然后進行加載新的客戶操作系統(tǒng)時，可以從內(nèi)存中訪問新的客戶操作系統(tǒng)，而不會中斷執(zhí)行環(huán)境；

（5）捕獲指令?？蛻舨僮飨到y(tǒng)可能會根據(jù)其訪問權限級別執(zhí)行技術上不應執(zhí)行的指令。Hypervisor可以分析客戶操作系統(tǒng)嘗試發(fā)送到硬件的指令，并模擬硬件對客戶操作系統(tǒng)指令的響應；

（6）異常處理。發(fā)生異常（即異常行為）時，可以將某些異常路由到Hypervisor進行處理；

（7）虛擬機管理。如前所述，Hypervisor最終負責啟動和停止客戶操作系統(tǒng)在其上運行的虛擬機。

汽車領域為什么會擁抱Hypervisor

在汽車電子電氣架構處于分布式的時代，每個ECU負責一個功能，可以說各司其職，涇渭分明，路不拾遺。但是自從BOSCH公開了其電子電氣架構演進的內(nèi)功心法后，江湖便掀起了內(nèi)卷潮，各自閉門修煉，以期早日取Bosch而代之。

這個心法口訣的核心就是：分久必合。而在這個時間點，正是域融合稱王，分布式退位的階段。暫不表文章開頭隱喻的升級域架構的辛酸苦楚，只提在融合中涌現(xiàn)出來的一位優(yōu)秀代表—座艙域，這也是Hypervisor目前為止在汽車領域攻下的第一城和唯一一城。

在矛盾的重點轉移到滿足人民群眾日益增長的精神需求之后，座艙內(nèi)便熱鬧了起來。中控大屏、液晶儀表、抬頭顯示、行車記錄儀，流媒體后視鏡，后排娛樂系統(tǒng)等悉數(shù)登場，整個座艙內(nèi)儼然成為屏幕家族狂歡的舞臺。如果按照分布式電子電氣架構的思路，每新增一個大的功能新增一個零件，別說主機廠成本上能不能接受，狹隘的空間內(nèi)如何布置這些控制器問題都夠主機廠布置工程師喝幾壺。

在域融合心法的指引下，既然大家都是初來乍到，又沒有把柄被巨頭Tier1抓住，那么座艙內(nèi)各種大屏走向聯(lián)合是合乎發(fā)展規(guī)律的事情。并在聯(lián)盟中挑選出一位德才兼?zhèn)涞拿酥鳌悄茏撚蚩刂破?，負責?lián)盟內(nèi)外事務。

盟主剛上位，就面對一個棘手的問題。液晶儀表/抬頭顯示負責的部分功能與動力系統(tǒng)、輔助駕駛系統(tǒng)強關聯(lián)，具有較高的實時性、安全性要求，因此多以安全實時的操作系統(tǒng)QNX為主。而中控大屏/行車記錄儀/后排娛樂系統(tǒng)主要提供娛樂、導航、車輛控制等多樣化功能，對豐富的生態(tài)資源和信息安全有較高的要求，因此多以生態(tài)豐富的Android和Linux操作系統(tǒng)為主。

盟主想到了兩種方案，一種方案自己修煉影分身之術，也就是在一個座艙域控制器中放置兩顆MCU芯片。一顆芯片裝QNX操作系統(tǒng)跑儀表相關功能，一顆芯片裝Android或Linux操作系統(tǒng)跑大屏相關功能。兩顆芯片通過外圍串行接口相連并進行通信。這是一種形態(tài)上的融合，各單元依然獨立地完成各自任務，因此功能邊界非常清晰。但是每個芯片都需要一個最小系統(tǒng)，不僅浪費硬件資源，還沒法實現(xiàn)硬件資源拓展。且信號在多個芯片之間進出帶來的延遲而導致的性能局限，都將是此種方式揮之不去的噩夢。

此種融合方案的帶頭大哥便是Tesla，其區(qū)域架構方案也一直是各家模仿的對象。整個架構包括一個中央計算單元和三個區(qū)域控制器，中央計算單元負責ADAS/ADS功能、信息娛樂功能和網(wǎng)絡通信功能。Tesla將實現(xiàn)ADAS/AD功能的FSD芯片，實現(xiàn)信息娛樂功能的MCU芯片，實現(xiàn)網(wǎng)絡通信功能的模組集成在一個電路板上，并采用一套液冷系統(tǒng)。每個芯片獨立運行各自的操作系統(tǒng)并獨立完成各自的任務，外界一般稱其為“準中央集中式架構”。但筆者特別想說，沒有Tesla的命，別去模仿Tesla。

另外一種方案是盟主雇個專業(yè)的經(jīng)理人，幫自己打點底下的小兄弟，也就是業(yè)界比較認可的終極融合方案“一芯多屏”，即是一顆芯片，跑多個操作系統(tǒng)，從而支持儀表、抬頭顯示和各種大屏的功能，同時滿足各個應用對實時性、可靠性、安全性等的不同要求。這時上文提到的互聯(lián)網(wǎng)領域成熟應用的虛擬化和Hypervisor技術便自然而然的吸引了汽車大佬們的目光，并成功上演了一段跨界姻緣。

虛擬化和Hypervisor在座艙域的成功應用，給了電子電氣架構不斷融合下去的勇氣和信心。尤其是到了中央集中式架構階段，整車可能就剩下一臺高性能中央計算單元。而這臺高性能中央計算單元，既要實現(xiàn)智能座艙功能，又要實現(xiàn)自動駕駛功能。而這些功能的差異更加明顯，所需支持的操作系統(tǒng)類型也更加豐富。

而Hypervisor的到來，物理硬件層面，可以根據(jù)功能需求自由分配每個操作系統(tǒng)所需的資源，充分而又靈活地利用高性能的SOC的高超運算能力。功能實現(xiàn)層面，還可按照不同主機廠的需求靈活搭載各種不同的操作系統(tǒng)組合，并運行具有不同算力要求、不同功能安全等級，不同信息安全等級、不同實時性要求的軟件。

車載Hypervisor的技術要求

Hypervisor雖在互聯(lián)網(wǎng)領域大放異彩，但汽車領域的特殊性，決定了不可能完全照搬互聯(lián)網(wǎng)的成熟經(jīng)驗。Hypervisor在汽車領域適配的過程中，必須正視和尊重以下和互聯(lián)網(wǎng)領域的差別：

（1）物理硬件層面?；ヂ?lián)網(wǎng)的集群服務器模式，可以讓其擁有靈活可擴展的高計算能力和大存儲能力，Hypervisor完全不用操心自己需要消耗多少計算和存儲資源的問題。而在成本極其敏感的汽車領域，不管是當下的域控制器還是后面的高性能中央計算單元中的主芯片，其計算能力和存儲能力就顯得捉襟見肘。降低CPU占用、AI算力消耗和存儲需求將會是貫穿整車項目開發(fā)始終的工作。Hypervisor自身的輕量化能力，成為衡量其能否在汽車領域大規(guī)模應用的一個關鍵指標；

（2）安全冗余層面?；ヂ?lián)網(wǎng)領域面對的是動態(tài)的用戶任務，互聯(lián)網(wǎng)大佬期望Hypervisor可以動態(tài)分配物理硬件資源，有效利用閑置資源，從而實現(xiàn)降本增效的作用；汽車領域面對的是相對固定的用戶計算任務，任務所需硬件資源在出廠前已由工程師設計分配好。汽車大佬們期望Hypervisor在實時性、可靠性、安全性等方面可以更加出眾；

（3）適配開發(fā)層面。在汽車領域，MCU/MPU/SOC類型豐富的你無法想象，操作系統(tǒng)多的也讓你數(shù)不勝數(shù)，如何減少Hypervisor在適配底層不同硬件和上層不同操作系統(tǒng)的工作量，是橫亙在Hypervisor面前的另外一座高山。

汽車領域和互聯(lián)網(wǎng)領域的差別，決定了Hypervisor要想在汽車領域繼續(xù)攻城拔寨，必須繼續(xù)修煉直至擁有如下能力：

（1）安全冗余層面。Hypervisor必須具備通過資源分區(qū)技術嚴格隔離和分配資源的能力。當一個虛擬機中的應用程序出現(xiàn)故障時，只可以影響分配給它的內(nèi)存，而不會影響其它虛擬機的內(nèi)存池。當然前提是開發(fā)人員提前規(guī)劃好應用的內(nèi)存需求。

（2）通用開發(fā)框架層面。汽車領域需要一種權威的Hypervisor通用框架和標準接口，以減少適配底層不同硬件和上層不同操作系統(tǒng)時的開發(fā)工作量。目前VirtIO標準已得到汽車行業(yè)一眾巨頭的支持，未來有希望脫穎而出，實現(xiàn)大一統(tǒng)；

（3）任務調度機制。汽車領域存在大量實時任務和非實時任務，而這兩種系統(tǒng)對于任務的時間響應要求有著本質的不同。Hypervisor應該具備靈活的時間調度機制，既能支持基于優(yōu)先級的任務調度方式，又能支持基于時間片的任務調度方式；

（4）進程間通信機制。Hypervisor在對虛擬機進行嚴格安全隔離的同時，也需要支持不同虛擬機進程之間以受控方式進行相互通信。而最基本的進程間通信包括同步消息傳遞和共享內(nèi)存兩種方式。

車載主流Hypervisor產(chǎn)品介紹

近幾年涌入車載Hypervisor領域的玩家非常多，也以巨頭為主，包括Xen Hypervisor，OpenSynergy、ACRN Hypervisor、Global Hypervisor、Mentor Hypervisor、QNX Hypervisor、Redbend Hyeprvisor等。但非常遺憾的是，QNX Hypervisor是目前唯一應用到量產(chǎn)車型的Hypervisor，它也是目前市場上唯一一個功能安全等級達到ASIL D級的虛擬化操作系統(tǒng)。由此也可見Hypervisor的開發(fā)難度。

下面挑選三款比較有代表性的Hypervisor產(chǎn)品進行簡單對比。