在電子電氣系統(tǒng)架構(gòu)從分布式向域集中式演進(jìn)的大背景下，各種功能模塊都集中到少數(shù)幾個(gè)域控制器中，以前需要N個(gè)ECU（Electronic Control Unit，電子控制單元）實(shí)現(xiàn)各種功能，現(xiàn)在只需要一個(gè)DCU（Domain Control Unit，域控制器），節(jié)省了大量的線束和接插件，減輕了車身整體重量。

但是，在汽車電子電氣系統(tǒng)中，不同的ECU提供不同的服務(wù)，具有不同的優(yōu)先級，對底層操作系統(tǒng)的要求也不一樣。例如，根據(jù)ISO 26262標(biāo)準(zhǔn)，汽車儀表系統(tǒng)與娛樂信息系統(tǒng)屬于不同的安全等級，具有不同的處理優(yōu)先級。汽車儀表系統(tǒng)與動(dòng)力系統(tǒng)密切相關(guān)，要求具有高實(shí)時(shí)性、高可靠性和強(qiáng)安全性，以QNX操作系統(tǒng)為主，而信息娛樂系統(tǒng)主要為車內(nèi)人機(jī)交互提供控制平臺(tái)，追求多樣化的應(yīng)用與服務(wù)，以Linux和Android為主。

要使不同類型的操作系統(tǒng)運(yùn)行在同一個(gè)計(jì)算平臺(tái)，最直接的技術(shù)路徑就是虛擬化。虛擬化作為一項(xiàng)底層IT核心技術(shù)一直被廣泛應(yīng)用于云計(jì)算領(lǐng)域，它的作用是通過Hypervisor軟件模擬出一個(gè)具有完整硬件系統(tǒng)功能、運(yùn)行在一個(gè)完全隔離環(huán)境中的計(jì)算機(jī)系統(tǒng)。

虛擬化的概念被引入到車載操作系統(tǒng)之后，供應(yīng)商不再需要設(shè)計(jì)多個(gè)硬件來實(shí)現(xiàn)不同的功能需求，而只需要在車載主芯片上進(jìn)行虛擬化的軟件配置，形成多個(gè)虛擬機(jī)，在每個(gè)虛擬機(jī)上運(yùn)行相應(yīng)的軟件即可滿足需求。

虛擬化（Hypervisor）解決方案提供了在同一硬件平臺(tái)上承載異構(gòu)操作系統(tǒng)的靈活性，同時(shí)實(shí)現(xiàn)了良好的高可靠性和故障控制機(jī)制, 以保證關(guān)鍵任務(wù)、硬實(shí)時(shí)應(yīng)用程序和一般用途、不受信任的應(yīng)用程序之間的安全隔離，實(shí)現(xiàn)了車載計(jì)算單元整合與算力共享。

云虛擬化 vs 物虛擬化

如果說“云“虛擬化是過去20年的技術(shù)風(fēng)口，那么”物“虛擬化將會(huì)是下一個(gè)20年不容錯(cuò)過的技術(shù)風(fēng)口。雖然兩種技術(shù)同根同源，但是，基于嵌入式的物虛擬化與傳統(tǒng)的云計(jì)算虛擬化還是有其不同的地方。

1. **定位目標(biāo)不同：**云虛擬化關(guān)注虛擬機(jī)的熱遷移、資源彈性按需分配、靈活管理，而嵌入式虛擬化關(guān)注實(shí)時(shí)性、可確定性、功能安全（Functional Safety) 及小身材（Footprint）等。

2. **可用的資源多寡不同：**云服務(wù)器的計(jì)算能力和內(nèi)存資源遠(yuǎn)多于嵌入式系統(tǒng)，后者對資源的使用幾乎達(dá)到“斤斤計(jì)較”的地步。

3. 軟件發(fā)布模式不同。云虛擬化軟件是同一套二進(jìn)制代碼部署在所有服務(wù)器上運(yùn)行，而嵌入式虛擬化軟件和嵌入式硬件往往是綁定的，大多數(shù)情況下是一物一系統(tǒng)。

車載虛擬化的技術(shù)要求

車載虛擬化操作系統(tǒng)首先是一個(gè)穩(wěn)定可靠、性能良好、具備實(shí)時(shí)響應(yīng)能力的微內(nèi)核，承載在虛擬機(jī)上的應(yīng)用程序按照預(yù)先設(shè)定的優(yōu)先級運(yùn)行，確保在高優(yōu)先級虛擬機(jī)中運(yùn)行的實(shí)時(shí)進(jìn)程能夠及時(shí)獲得對計(jì)算資源的必要訪問，無論低優(yōu)先級虛擬機(jī)執(zhí)行的繁忙程度如何，同時(shí)，強(qiáng)制性地將關(guān)鍵應(yīng)用程序和實(shí)時(shí)操作系統(tǒng)與非關(guān)鍵應(yīng)用程序和普通操作系統(tǒng)安全隔離。

小知識(shí)

所謂微內(nèi)核（Microkernel），是指內(nèi)核進(jìn)程僅提供最基本的服務(wù)，例如進(jìn)程調(diào)度、進(jìn)程間通信、信號、時(shí)鐘、中斷等，而其它的服務(wù)（例如文件系統(tǒng)、內(nèi)存管理、設(shè)備驅(qū)動(dòng)、網(wǎng)絡(luò)協(xié)議棧等）都獨(dú)立于內(nèi)核以單獨(dú)的進(jìn)程運(yùn)行，它們與內(nèi)核進(jìn)程和其它進(jìn)程之間通過內(nèi)核提供的消息傳遞機(jī)制進(jìn)行通信。

微內(nèi)核是相對于宏內(nèi)核而言的，Linux是典型的宏內(nèi)核，除了時(shí)鐘、中斷、進(jìn)程調(diào)度、進(jìn)程間通信外，文件系統(tǒng)、內(nèi)存管理、設(shè)備驅(qū)動(dòng)管理等都由內(nèi)核完成。

一般而言，車載虛擬化操作系統(tǒng)要求具備三點(diǎn)技術(shù)要求：

1. 使用資源分區(qū)技術(shù)嚴(yán)格隔離和分配資源。

2. 靈活高效的實(shí)時(shí)和非實(shí)時(shí)任務(wù)調(diào)度機(jī)制。

3. 進(jìn)程間通信，實(shí)現(xiàn)消息在虛擬機(jī)之間通信。

1、資源分區(qū)

微內(nèi)核將全局內(nèi)存空間劃分為靜態(tài)可配置的資源池，虛擬機(jī)啟動(dòng)時(shí)，將相應(yīng)的內(nèi)存頁地址空間分配給它，虛擬機(jī)中的任務(wù)線程總是連接到這部分地址空間，并且它只能訪問和管理這部分地址空間，此機(jī)制確保了虛擬機(jī)之間的嚴(yán)格隔離。當(dāng)一個(gè)虛擬機(jī)中的應(yīng)用程序出現(xiàn)故障時(shí)，只會(huì)影響分配給它的內(nèi)存，而不會(huì)影響其它虛擬機(jī)的內(nèi)存池。這是一個(gè)簡單的解決方案，因?yàn)樗S護(hù)了一個(gè)最小的受信任的代碼庫，唯一的挑戰(zhàn)是開發(fā)人員應(yīng)該預(yù)先預(yù)測Guest OS的內(nèi)存需求。

2、任務(wù)調(diào)度機(jī)制

常見的操作系統(tǒng)任務(wù)調(diào)度機(jī)制有兩種：

• 基于優(yōu)先級：一旦內(nèi)核把資源分配給某進(jìn)程，該進(jìn)程便會(huì)一直執(zhí)行下去，直到該進(jìn)程結(jié)束或發(fā)生某事件被阻塞（例如主動(dòng)調(diào)用延時(shí)），才把資源分配給其它進(jìn)程。在這種情況下，如果某個(gè)高優(yōu)先級的任務(wù)運(yùn)行時(shí)間過長，最好有阻塞機(jī)制，讓出CPU使其它低優(yōu)先級的任務(wù)也有機(jī)會(huì)運(yùn)行。

• 基于時(shí)間片：所有任務(wù)的執(zhí)行優(yōu)先級相同，當(dāng)內(nèi)核分配給該進(jìn)程的時(shí)間片結(jié)束，內(nèi)核會(huì)立即停止執(zhí)行該進(jìn)程，將時(shí)間片分配給其它進(jìn)程執(zhí)行，即便這個(gè)任務(wù)還沒有執(zhí)行完。

車載虛擬化系統(tǒng)同時(shí)承載實(shí)時(shí)車控系統(tǒng)和非實(shí)時(shí)娛樂系統(tǒng)，這兩種系統(tǒng)對于任務(wù)的時(shí)間響應(yīng)要求有著本質(zhì)的不同：

• 實(shí)時(shí)系統(tǒng)：一般要求基于優(yōu)先級的調(diào)度方式，對于不同優(yōu)先級的任務(wù)，完全基于優(yōu)先權(quán)原則來運(yùn)行，一旦高優(yōu)先級的任務(wù)就緒，它可以無條件地?fù)屨既魏握趫?zhí)行的、低于自己優(yōu)先級的進(jìn)程，無論正在運(yùn)行的進(jìn)程是否已經(jīng)進(jìn)入內(nèi)核調(diào)度階段。在一些實(shí)時(shí)操作系統(tǒng)的實(shí)現(xiàn)中，同時(shí)支持基于時(shí)間片的調(diào)度方式，當(dāng)幾個(gè)任務(wù)的優(yōu)先級相同時(shí)，會(huì)按照時(shí)間片來管理，在優(yōu)先級相同的任務(wù)間切換運(yùn)行。

• 非實(shí)時(shí)系統(tǒng)：一般情況下沒有任務(wù)優(yōu)先級的概念，所有任務(wù)默認(rèn)優(yōu)先級相同，任務(wù)調(diào)度采用時(shí)間片調(diào)度方式。

車載虛擬化內(nèi)核應(yīng)該具備靈活的時(shí)間調(diào)度機(jī)制，既支持基于優(yōu)先級的任務(wù)調(diào)度方式，又支持基于時(shí)間片的任務(wù)調(diào)度方式。

3、進(jìn)程間通信

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

• 同步消息傳遞：采用客戶端/服務(wù)器（Client/Server）模式，它實(shí)現(xiàn)了兩個(gè)進(jìn)程之間的點(diǎn)對點(diǎn)通信。

• 共享內(nèi)存：一種相對高效的進(jìn)程間通信方式，對于效率要求較高、數(shù)據(jù)量較大的場景，通常采用這種方式。共享內(nèi)存段被視為共享文件系統(tǒng)，為每個(gè)虛擬機(jī)進(jìn)程配置對共享內(nèi)存的讀寫訪問。

在車載虛擬化領(lǐng)域，主流的虛擬機(jī)技術(shù)提供商包括BlackBerry QNX Hypervisor（閉源）及Intel與Linux基金會(huì)主導(dǎo)的ACRN（開源）。但截至目前，只有QNX Hypervisor應(yīng)用到量產(chǎn)車型，它也是目前市場上唯一被認(rèn)可功能安全等級達(dá)到ASIL D級的虛擬化操作系統(tǒng)。

BlackBerry：QNX Hypervisor

QNX是由加拿大QSSL公司（QNX Software System Ltd.）開發(fā)的實(shí)時(shí)操作系統(tǒng)，既能運(yùn)行于以Intel x86、Pentium等CPU為核心的硬件環(huán)境，也能運(yùn)行于以PowerPC、MIPS等CPU為核心的硬件環(huán)境。

小知識(shí)

2004年，全球領(lǐng)先的音響產(chǎn)品制造商哈曼國際工業(yè)集團(tuán)（Harman International Industries）收購QNX，2010年4月，BlackBerry母公司RIM以2億美元從哈曼國際手中收購QNX。

QNX操作系統(tǒng)的應(yīng)用范圍極廣，包括控制保時(shí)捷跑車的音樂和媒體功能、核電站、美國陸軍無人駕駛坦克的控制系統(tǒng)、BlackBerry PlayBook平板電腦等。

2021年2月，BlackBerry正式發(fā)布QNX Hypervisor 2.2版本，該版本基于QNX Neutrino實(shí)時(shí)操作系統(tǒng)（RTOS）7.1。

QNX Hypervisor是基于Type-1（直接運(yùn)行于裸機(jī)）、實(shí)時(shí)優(yōu)先級的微內(nèi)核管理程序，符合IEC 61508 SIL-3（用于工業(yè)安全），IEC 62304（用于醫(yī)療設(shè)備軟件）和ISO 26262 ASIL-D（用于汽車安全）等標(biāo)準(zhǔn)。

整個(gè)QNX操作系統(tǒng)是由微內(nèi)核調(diào)度管理的一組進(jìn)程的集合，與硬件總線結(jié)構(gòu)非常相似，稱之為“軟件總線”。

QNX是一個(gè)基于優(yōu)先級搶占的操作系統(tǒng)，線程優(yōu)先級用0\~255的數(shù)字表示，數(shù)字越大，優(yōu)先級越高。優(yōu)先級0是內(nèi)核中的IDLE線程。同時(shí)，優(yōu)先級64是一個(gè)分界嶺，優(yōu)先級1\~63是非特權(quán)優(yōu)先級，一般用戶都可以用，而64\~255必須是有Root權(quán)限的線程才可以設(shè)置。調(diào)度程序在選擇下一個(gè)運(yùn)行的線程時(shí)，將檢查每個(gè)處于就緒狀態(tài)的線程的優(yōu)先級，具有高優(yōu)先級的線程將被優(yōu)先執(zhí)行。

QNX基本的任務(wù)調(diào)度算法使用的是按優(yōu)先級搶占的調(diào)度方法。這種方法保證在任何時(shí)刻都是優(yōu)先級最高的任務(wù)占用CPU時(shí)間。優(yōu)先級最高的任務(wù)可以中斷當(dāng)前運(yùn)行的任務(wù)。這種方法適用于工業(yè)實(shí)時(shí)性要求較高的場合。

在基本調(diào)度算法的基礎(chǔ)上，當(dāng)兩個(gè)或更多具有相同優(yōu)先級的線程同時(shí)處于就緒狀態(tài)，并且都是當(dāng)前就緒隊(duì)列中最高優(yōu)先級的任務(wù)時(shí)，QNX提供了四種調(diào)度方法來解決問題：

• 先進(jìn)先出（First In First Out，F(xiàn)IFO）：先進(jìn)入任務(wù)隊(duì)列的線程被選擇執(zhí)行，直到它自動(dòng)放棄，或者被一個(gè)級別更高的線程打斷運(yùn)行。

• 輪詢（Round Robin）：先進(jìn)入任務(wù)隊(duì)列的線程被選擇執(zhí)行，直到它自動(dòng)放棄，或者被一個(gè)級別更高的線程打斷運(yùn)行，或者它消耗完了自己的時(shí)間片（時(shí)間片為50ms，是系統(tǒng)分配給每個(gè)線程用于運(yùn)行的時(shí)間單位）。

• 自適應(yīng)調(diào)度（Adaptive Scheduling）：如果一個(gè)線程消耗完自己的時(shí)間片時(shí)仍未被阻塞，線程優(yōu)先級將被減1，稱為優(yōu)先級衰減。一個(gè)線程只能降低一次優(yōu)先級。如果該線程被阻塞，則將立即恢復(fù)為原來的優(yōu)先級。這種算法不適用于實(shí)時(shí)控制系統(tǒng)，主要應(yīng)用于后臺(tái)有計(jì)算密集的任務(wù)，且同時(shí)需要響應(yīng)用戶的交互信息，此時(shí)，計(jì)算線程可以擁有足夠的CPU資源，同時(shí)對用戶請求又有很快的響應(yīng)。

• 零星調(diào)度（Sporadic Scheduling）：引入Initial Budget、Replenishment Period、Max Number of Pending Replenishments三個(gè)參數(shù)，使一個(gè)線程可動(dòng)態(tài)執(zhí)行于Normal Priority和Low Priority兩個(gè)優(yōu)先級。

• Initial Budget（C）：線程在Normal Priority下允許執(zhí)行的時(shí)間。

• Low Priority：由于某種原因，線程不再以Normal Priority運(yùn)行，就將該線程的優(yōu)先級降至此優(yōu)先級。

• Replenishment Period（T）：只有在這個(gè)時(shí)間段內(nèi)，線程才被允許消耗完它的Initial Budget。

• Max Number of Pending Replenishments：限制Replenishment Period的發(fā)生次數(shù)。

當(dāng)線程的優(yōu)先級降低到Low Priority時(shí)，它可能會(huì)被執(zhí)行，也可能不被執(zhí)行，取決于系統(tǒng)當(dāng)時(shí)其它線程的優(yōu)先級。一旦一個(gè)Replenishment Period（T）到來，該線程的優(yōu)先級立即升至Normal Priority，這樣，只要適當(dāng)配置系統(tǒng)中各線程的C和T，就可以使每個(gè)線程都可以在每個(gè)T內(nèi)被執(zhí)行C時(shí)間值。

零星調(diào)度將一個(gè)線程需要執(zhí)行的時(shí)間分拆成若干段進(jìn)行執(zhí)行（這也是“零星調(diào)度”名稱的由來），這種算法適用于一個(gè)周期內(nèi)具有執(zhí)行時(shí)間上限的線程，可以使一個(gè)線程對非周期事件進(jìn)行服務(wù)，而不用擔(dān)心影響其它硬實(shí)時(shí)線程的執(zhí)行期限。

Intel & Linux基金會(huì)：ACRN

ACRN由Linux基金會(huì)于2018年3月在“Linux嵌入式大會(huì)”上發(fā)布，是一款靈活、開源的（BSD-3-Clause License）、輕量級Hypervisor參考軟件。Intel開源技術(shù)中心為ACRN項(xiàng)目的發(fā)布貢獻(xiàn)了源代碼，早期支持者包括Intel、ADLink（凌華科技）、Aptiv、LG和東軟等。

2020年6月，ACRN v2.0正式發(fā)布，采用**“Partition Mode”+“Sharing Mode”的“**Hybrid Mode”架構(gòu)設(shè)計(jì)。

• Partition Mode（左側(cè)）的VM獨(dú)享CPU、內(nèi)存、I/O外設(shè)等資源，在運(yùn)行時(shí)沒有ACRN Hypervisor的性能開銷，可以達(dá)到最大****的隔離性和更高的實(shí)時(shí)性。這個(gè)VM既可以作為Safety VM監(jiān)控整個(gè)物理平臺(tái)的健康狀態(tài)，在系統(tǒng)發(fā)生嚴(yán)重故障時(shí)采取緊急措施，又可以作為實(shí)時(shí)VM獲得更好的實(shí)時(shí)性。

• Sharing Mode（右側(cè)）有一個(gè)Service VM，它的作用類似于Xen虛擬化架構(gòu)中的Dom0，通過Device Model模塊在User VM（類似于Xen虛擬化架構(gòu)中的DomU）之間共享外設(shè)，同時(shí)管理各個(gè)VM的生命周期，并調(diào)用Libvirt接口對外提供遠(yuǎn)程調(diào)用和編排的標(biāo)準(zhǔn)接口。需要特別說明的是，為了使RTVM（右側(cè)黃色VM）能夠運(yùn)行硬實(shí)時(shí)OS（例如VxWorks、Zephyr、Xenomai等），ACRN進(jìn)行了特別的設(shè)計(jì)與代碼優(yōu)化，例如Local APIC直通等，使RTVM達(dá)到接近裸金屬的實(shí)時(shí)性能。

Hybrid Mode架構(gòu)具有兩個(gè)特點(diǎn)：

1. 利用Partition Mode的VM運(yùn)行Safety VM監(jiān)控物理平臺(tái)狀態(tài)，同時(shí)利用Sharing Mode中的RTVM運(yùn)行RTOS實(shí)現(xiàn)實(shí)時(shí)控制，滿足復(fù)雜工業(yè)場景的需求。

2. 通過ACRN Hypervisor實(shí)現(xiàn)了異構(gòu)負(fù)載的整合，例如，實(shí)時(shí)和非實(shí)時(shí)負(fù)載、安全功能和非安全功能的隔離等。

為了保持ACRN Hypervisor代碼庫盡可能精簡且高效，大部分設(shè)備模塊的實(shí)現(xiàn)都駐留在Service VM，Service VM可以運(yùn)行Clear Linux（Intel基于GPL協(xié)議的開源項(xiàng)目），也支持其它Linux發(fā)行版或者專有RTOS作為Service OS。如果沒有Partition Mode中的Pre-launched VM，Service VM是ACRN Hypervisor創(chuàng)建的第一個(gè)虛擬環(huán)境，以系統(tǒng)最高優(yōu)先級的虛擬機(jī)形式存在，通過Device Model模塊向Guest OS提供I/O模擬操作。

ACRN Hypervisor基于Intel IA-32處理器的硬件輔助虛擬化技術(shù)（Intel VT-x）。

Intel VT-x引入了一種新的CPU操作，稱為VMX（Virtual Machine eXtensions），以及兩種新的CPU工作模式和10條新的虛擬專用指令（VMPTRLD、VMPTRST、VMCLEAR、VMREAD、VMWRITE、VMCALL、VMLAUNCH、VMRESUME、VMXOFF和VMXON）。兩種工作模式分別為VMX root operation（根虛擬化操作）和VMX non-root operation（非根虛擬化操作），其中，VMX root operation被設(shè)計(jì)用于給Hypervisor使用，VMX non-root operation則由Guest OS使用。兩種工作模式都支持Ring 0～Ring 3，因此，Hypervisor和Guest OS可以自由選擇它們所期望的運(yùn)行級別。

硬件輔助虛擬化技術(shù)就是通過在VMX root operation和VMX non-root operation兩種工作模式之間相互切換實(shí)現(xiàn)的。

運(yùn)行在VMX root operation模式下的Hypervisor通過顯式調(diào)用VMLAUNCH或VMRESUME指令切換到VMX non-root operation模式，硬件自動(dòng)加載Guest OS的上下文，于是Guest OS獲得運(yùn)行，這種轉(zhuǎn)換稱為VM entry。Guest OS運(yùn)行過程中遇到需要Hypervisor處理的事件，例如外部中斷或缺頁異常，或者主動(dòng)調(diào)用VMCALL指令請求Hypervisor的服務(wù)的時(shí)候（與系統(tǒng)調(diào)用類似），硬件自動(dòng)掛起Guest OS，切換到VMX root operation模式，恢復(fù)Hypervisor的運(yùn)行，這種轉(zhuǎn)換稱為VM exit。VMX root operation模式下，軟件的行為與在沒有VT-x技術(shù)的處理器上的行為基本一致；而VMX non-root operation模式則有很大不同，最主要的區(qū)別是此時(shí)運(yùn)行某些指令或遇到某些事件時(shí)，發(fā)生VM exit。

ACRN Device Model是一個(gè)類似QEMU的硬件設(shè)備模擬軟件，依賴以下三個(gè)子系統(tǒng)協(xié)同工作：

1、設(shè)備仿真（Device Emulation）

Device Model為User VM中的設(shè)備驅(qū)動(dòng)提供設(shè)備仿真例程（Routines），用來模擬各種不同種類的硬件設(shè)備，這些設(shè)備仿真例程將各自的I/O處理程序注冊到I/O調(diào)度器（Dispatcher）。當(dāng)User VM產(chǎn)生I/O設(shè)備訪問請求時(shí)，I/O調(diào)度器將這些請求分發(fā)到相應(yīng)的設(shè)備仿真例程，實(shí)現(xiàn)硬件模擬。

2、VHM（Virtio and Hypervisor Service Module）

以Service OS的內(nèi)核模塊形式存在，作為ACRN Hypervisor與Device Model之間的橋梁，為設(shè)備模擬提供必要的服務(wù)，具體的服務(wù)流程如下：

• ACRN Hypervisor通過中斷通知VHM新的IOREQ到來。

• VHM將IOREQ標(biāo)記為“正在處理”，同時(shí)將其發(fā)送給設(shè)備模擬、GVT-g（Intel開源的GPU虛擬化解決方案）、VBS-K（Virtio Backend Service Kernel-land）等做進(jìn)一步處理。之后，VHM可以處理新的IOREQ。

• 一旦IOREQ被處理完成，VHM將被通知（內(nèi)核態(tài)通過函數(shù)調(diào)用方式通知，用戶態(tài)通過IOCTL的方式通知），之后，VHM通過Hypercall方式進(jìn)一步通知ACRN Hypervisor該IOREQ處理完成。

3、I/O請求（I/O Path）

下圖展示了ACRN中訪問一個(gè)虛擬I/O的流程。

• 當(dāng)Guest OS執(zhí)行I/O指令時(shí)，VM exit發(fā)生，ACRN Hypervisor獲得CPU控制權(quán)，首先判斷VM執(zhí)行退出的原因，例如PIO或MMIO等。

• ACRN Hypervisor對產(chǎn)生VM exit的指令進(jìn)行譯碼，將譯碼得到的信息（包括PIO訪問、訪問字節(jié)數(shù)、讀/寫方式、目標(biāo)寄存器等）放到與ACRN VHM、ACRN Device Model共享的物理頁面中，然后以中斷的方式通知Service OS中的VHM做進(jìn)一步處理。

• Service OS中的VHM接收到中斷后，查詢與該IOREQ相關(guān)的所有信息。

• VHM首先會(huì)檢查是否應(yīng)該由內(nèi)核態(tài)的Device Model來處理該IOREQ。如果是，相應(yīng)的內(nèi)核模塊之前注冊的Callback函數(shù)會(huì)被VHM調(diào)用；否則，如果沒有內(nèi)核態(tài)的Device Model來處理IOREQ，VHM則會(huì)將該IOREQ保留在共享頁面中，并喚醒ACRN Device Model對該IOREQ進(jìn)行處理。

• ACRN Device Model采用與VHM相同的機(jī)制對IOREQ進(jìn)行處理。Device Model的I/O執(zhí)行線程會(huì)首先查詢IOREQ具體的信息，同時(shí)檢查是否有設(shè)備仿真模塊實(shí)現(xiàn)了該IOREQ對應(yīng)的邏輯。如果有相應(yīng)的模塊，那么該模塊對應(yīng)的Callback函數(shù)將會(huì)被調(diào)用。

• ACRN Device Model完成設(shè)備模擬仿真后，將結(jié)果保存到共享頁面。

• 完成IOREQ的模擬和仿真后，ACRN Device Model通過VHM的API將控制權(quán)返回給ACRN Hypervisor。

• ACRN Hypervisor得知IOREQ處理完成，將結(jié)果保存到vCPU的相應(yīng)寄存器中。

• ACRN Hypervisor更新完vCPU寄存器后，進(jìn)一步更新IP地址寄存器指向下一條Guest OS指令，同時(shí)恢復(fù)Guest OS的執(zhí)行。

VirtIO標(biāo)準(zhǔn)

Hypervisor介乎于底層DCU硬件和上層OS軟件之間，與標(biāo)準(zhǔn)化服務(wù)器（x86）+標(biāo)準(zhǔn)化OS（Windows和Linux）的云虛擬化應(yīng)用場景不同，汽車嵌入式環(huán)境中的虛擬化技術(shù)面臨的挑戰(zhàn)是Hypervisor往往需要定制適配底層DCU硬件和上層OS軟件，這一點(diǎn)對于Hypervisor的大規(guī)模商用與普及是一個(gè)非常大的技術(shù)障礙。

2016年3月，OASIS（Organization for the Advancement of Structured Information Standards，結(jié)構(gòu)化信息標(biāo)準(zhǔn)促進(jìn)組織）正式標(biāo)準(zhǔn)化VirtIO項(xiàng)目，旨在提供一種通用的框架和標(biāo)準(zhǔn)接口，減少Hypervisor對底層不同硬件和上層不同軟件的適配開發(fā)工作量。

目前，VirtIO標(biāo)準(zhǔn)得到了眾多科技巨頭的支持，包括Apple、Google、ARM、Intel、Red Hat、華為等。Google也計(jì)劃在Android Automotive OS中集成對VirtIO的支持。

VirtIO是一套易維護(hù)和易擴(kuò)展的通用設(shè)備仿真接口，由前端驅(qū)動(dòng)程序（Front-End Driver）、后端驅(qū)動(dòng)程序（Back-End Driver）和VirtIO虛擬隊(duì)列（Virtual Queue）構(gòu)成。

前端驅(qū)動(dòng)程序由Guest OS實(shí)現(xiàn)，后端驅(qū)動(dòng)程序由Hypervisor實(shí)現(xiàn)，虛擬隊(duì)列通常使用環(huán)形緩沖，在Hypervisor和Guest OS之間傳輸數(shù)據(jù)，每個(gè)驅(qū)動(dòng)可以有0個(gè)或多個(gè)隊(duì)列，取決于實(shí)際需要。例如，網(wǎng)絡(luò)驅(qū)動(dòng)（virtio-net）可能使用了兩個(gè)虛擬隊(duì)列（分別用于接收和發(fā)送），而塊存儲(chǔ)驅(qū)動(dòng)（virtio-blk）可能只需要一個(gè)。

除了網(wǎng)卡、PCI、塊存儲(chǔ)、控制臺(tái)、輸入等常用設(shè)備之外，傳感器、CAN網(wǎng)絡(luò)、媒體編解碼設(shè)備等汽車領(lǐng)域的一些特殊類型硬件，可能是未來VirtIO標(biāo)準(zhǔn)完善的方向。

結(jié)束語

汽車電子電氣架構(gòu)從分布式向域集中式發(fā)展的趨勢已成定局，越來越多的功能被整合到少數(shù)幾個(gè)域控制器中，從而出現(xiàn)了多種不同的功能復(fù)用同一個(gè)硬件平臺(tái)的需求。

Hypervisor虛擬化為同一個(gè)硬件平臺(tái)承載多種不同類型的操作系統(tǒng)、不同時(shí)間響應(yīng)要求的業(yè)務(wù)應(yīng)用提供了關(guān)鍵的技術(shù)支撐。借助Hypervisor虛擬化技術(shù)，既消除了硬件冗余，簡化了總體設(shè)計(jì)，降低了整車重量，又滿足了資源復(fù)用、算力共享、安全隔離的需求。

當(dāng)前，大多數(shù)的Hypervisor都需要與指定的底層硬件和上層Guest OS配合使用，隨著越來越多的Hypervisor提供商和Guest OS供應(yīng)商遵循VirtIO標(biāo)準(zhǔn)，以及VirtIO標(biāo)準(zhǔn)對特定汽車硬件的虛擬化支持，Hypervisor將進(jìn)一步解耦車載軟硬件，車載系統(tǒng)供應(yīng)商將更容易在不同的DCU硬件平臺(tái)上支撐不同的Guest OS和應(yīng)用程序，從而真正實(shí)現(xiàn)軟件定義汽車。

作者：歐珊瑚
來源：https://mp.weixin.qq.com/s/Ilv9nn0Fy5o6p3p2\_oiacw