AURIX? TC4x虛擬化技術(shù)詳解

引言

在之前的《AURIX? TC4x虛擬化技術(shù)助力下一代汽車(chē)EE架構設計》一文中，我們已經(jīng)介紹了嵌入式虛擬化的發(fā)展歷史，基本概念，使用案例，它的優(yōu)勢以及當前面臨的挑戰。接下來(lái)，我們將深入探討TC4x對虛擬化技術(shù)的硬件支持，軟件開(kāi)發(fā)流程以及現有的軟件Demo。

1. AURIX? TC4x虛擬化硬件架構

AURIX? TC4x在硬件上全面支持虛擬化技術(shù)，包括CPU虛擬化，內存虛擬化，中斷虛擬化，外設虛擬化以及虛擬機之間的IPC通信（如圖1所示）

圖1  AURIX? TC4x虛擬化架構

2. CPU虛擬化

2.1 CPU虛擬化的硬件支持

我們知道，CPU的軟件運行狀態(tài)通過(guò)一套硬件資源簇來(lái)管理，圖2是AURIX? TC3x 1.6.2內核的硬件資源簇。

圖2  AURIX? TC3x內核硬件資源簇

TC4x 內核架構從1.6.2升級到1.8，一個(gè)重要的改變就是增加了對虛擬化的支持。為此，TC4x采用了三套硬件資源簇（HRA，HRB和HRHV）來(lái)管理CPU的運行（圖3）。

圖3  TC4x硬件資源簇

TC4x最多支持6個(gè)CPU，每一個(gè)CPU最多支持8個(gè)虛擬機。其中，VM0用作Hypervisor，負責調度上層的7個(gè)虛擬機（Guest VM），并由硬件資源簇HRHV來(lái)管控；VM1是一個(gè)實(shí)時(shí)虛擬機，獨享硬件資源簇HRA；另外6個(gè)虛擬機VM2-VM7，共享硬件資源簇HRB，可通過(guò)輪詢(xún)調度的方式去占用HRB。如圖4所示：

圖4  TC4x硬件資源簇與虛擬機的對應關(guān)系

內核復位后，虛擬化功能默認是打開(kāi)的。通過(guò)修改VCON0的EN位，用戶(hù)可以去使能或禁用某一個(gè)CPU的虛擬化功能。需要注意的是VCON0.EN位具有“write once”的屬性，即在系統的一個(gè)上電周期內只能修改一次，二次修改該值無(wú)效。

每個(gè)CPU同一時(shí)刻只能有一個(gè)虛擬機運行，用戶(hù)可以通過(guò)讀取VCON1的CVMN位獲取當前運行的虛擬機的Number。而下一個(gè)需要運行的目標虛擬機，則可以通過(guò)VCON2的VMN位進(jìn)行設置。此外，為了支持虛擬機之前的切換，TriCore1.8內核引入了兩個(gè)新的指令，RFH（Return from Hypervisor）和HVCALL：

• RFH：用于Hypervisor到上層Guest VM的切換?？蛻?hù)在Hypervisor軟件中調用RFH指令，則可以實(shí)現從Hypervisor到其他目標虛擬機的切換。

• HVCALL：類(lèi)似之前TriCore1.6的SYSCALL，用于上層Guest VM到Hypervisor的切換。因為上層VM之間不能直接切換，需要Hypervisor來(lái)統一調度，所以上層虛擬機執行完成之后，需要調用HVCALL回到Hypervisor軟件中去。

2.2 虛擬機在CPU中的部署

CPU在復位之后都會(huì )先進(jìn)入VM0（也就是Hypervisor軟件），在Hypervisor中完成硬件資源的初始化后，則開(kāi)始進(jìn)行虛擬機的調度，虛擬機在CPU中的部署有如下幾種：

• Hypervisor上層只有一個(gè)虛擬機VM1運行（圖5.a）：類(lèi)似傳統的CPU，用戶(hù)進(jìn)入VM0之后可以直接切換到VM1，VM1獨享CPU的硬件資源和周期性任務(wù)。

• Hypervisor上層有兩個(gè)虛擬機VM1和VM2運行（圖5.b）：用戶(hù)需要分別為VM1和VM2分配硬件資源，Hypervisor需要根據客戶(hù)的需求調度VM1和VM2。

• Hypervisor上層有兩個(gè)以上VM運行（圖5.c）：由于VM2-VM7是共享一套資源簇HRB，所以每次切換到HRB進(jìn)行操作時(shí)，需要特別指定是哪一個(gè)VM進(jìn)行操作，一般客戶(hù)可以通過(guò)輪詢(xún)的方式去調度HRB里面的虛擬機。

圖5 虛擬機在CPU中的部署

以上是單核的情況，在多核場(chǎng)景下，每一個(gè)核都可以靈活地使用不同的虛擬機分配機制來(lái)實(shí)現整個(gè)系統的調度，如圖6所示：

圖6 TC4x多核虛擬化

圖7是虛擬機在不同CPU內部署的示例，假設我們有兩個(gè)應用APP1和APP2，它們分別占用CPU0/1/2/3/4的VM1和CPU3/4/5的VM2?？梢钥吹?，不同CPU里面Hypervisor的調度是不同的，有可能存在一個(gè)VM獨享CPU的情況（CPU0/1/2/5），也有可能需要Hypervisor去調度多個(gè)虛擬機（CPU3/4），具體如何使用可以根據客戶(hù)的需求靈活配置。

圖7 虛擬化部署示例

3. 內存虛擬化

在TC2x/TC3x的內核架構中，內存保護都是任務(wù)層級的。操作系統通過(guò)MPU模塊，對不同任務(wù)設置Memory的訪(fǎng)問(wèn)權限。這一功能在TC4x的內核架構中依然沿用，并且我們將任務(wù)層級的MPU保護稱(chēng)作Level 1 MPU。而當我們使能了虛擬化功能后，對于不同虛擬機之間的訪(fǎng)問(wèn)保護，則需要額外的MPU保護，我們將不同Guest VM（VM1-VM7）之間的MPU保護稱(chēng)作Level 2 MPU。如圖8所示：

圖8 TC4x L1/L2 MPU

3.1 Level 1 MPU保護

L1的MPU保護是通過(guò)HRx_CORECON.PROTEN寄存器的PROTEN位來(lái)使能。HRHV，HRA和HRB均可以獨立設置是否使能L1的MPU保護。TC4x支持多達24個(gè)數據段和16個(gè)代碼段的訪(fǎng)問(wèn)權限設置?？蛻?hù)可以在每一個(gè)VM的RTOS中，通過(guò)配置CPXEy，DPWEy以及DPREy寄存器來(lái)選擇自身VM運行訪(fǎng)問(wèn)的數據段和代碼段，并通過(guò)配置CPUx_HRx_PSW寄存器的PRS2和PRS位來(lái)切換不同任務(wù)需要保護的數據和代碼段，TC4x最多支持8個(gè)保護寄存器簇（PRS0-PRS7）。圖9是L1 MPU保護所涉及到的寄存器示意圖。

圖9 L1 MPU保護寄存器

3.2 Level 2 MPU保護

在使能了虛擬化功能之后，L2的MPU保護默認是開(kāi)啟的，用戶(hù)可以根據自身需求，在Hypervisor軟件中配置不同虛擬機的訪(fǎng)問(wèn)權限。HRHV_CPXE_x，HRHV_DPRE_x以及HRHV_DPWE_x中的x由VCON2.L2_PRS位來(lái)確定，其他的配置部分與L1 MPU相同。圖10是L1 MPU保護所涉及到的寄存器示意圖。

圖10 L2 MPU保護寄存器

需要注意的是，如果系統出現L1 MPU的訪(fǎng)問(wèn)越界，則會(huì )觸發(fā)硬件資源的Trap，如果出現L2 MPU訪(fǎng)問(wèn)的訪(fǎng)問(wèn)越界，則會(huì )觸發(fā)Hypervisor的Trap。如果同時(shí)違背的L1 MPU和L2 MPU，則會(huì )按照L1 MPU的訪(fǎng)問(wèn)越界響應。

4. 中斷虛擬化

4.1 中斷虛擬化的硬件支持

如下圖所示，是TC3x和TC4x的服務(wù)請求控制寄存器（SRC），可以看到對于TC4x的SRC寄存器，除了我們熟悉的優(yōu)先級配置SRPN，服務(wù)請求使能位SRE，以及服務(wù)控制類(lèi)型TOS以外，還額外增加了VM的位域。這表明，對于每一個(gè)中斷服務(wù)請求節點(diǎn)，用戶(hù)可以設置VM0-VM7的選項，從而將中斷的處理映射到某一個(gè)CPU的某一個(gè)VM中去。

圖11 TC3x/TC4x SRC寄存器對比

4.2 虛擬機的中斷仲裁和響應機制

中斷控制單元ICU會(huì )對不同硬件資源簇內部的虛擬機中斷服務(wù)請求進(jìn)行仲裁，虛擬機是否參與仲裁由寄存器VMEMz.VMy的配置決定。仲裁采用輪詢(xún)機制，VM0-VM1-VMz依次輪詢(xún)，其中VMz表示的是HRB里面的虛擬機，HRB內部也按照輪詢(xún)機制進(jìn)行二級仲裁。當某一個(gè)虛擬機參與仲裁之后，其產(chǎn)生的最高優(yōu)先級的中斷服務(wù)請求會(huì )更新到VMxn_ICR的PIPN位等待ICU的仲裁。如下圖（圖12）所示：

圖12 虛擬機的中斷仲裁

此外，虛擬機的中斷還支持搶占功能，用戶(hù)可以對每一個(gè)虛擬機的中斷設置搶占閾值，只有高于該閾值的優(yōu)先級中斷才可以搶占當前的虛擬機中斷。該功能可通過(guò)配置VMn_PETHRESH寄存器的的PE_THRESH位域實(shí)現。

整個(gè)虛擬機的中斷處理流程如下（圖13）：

• 當產(chǎn)生中斷的響應虛擬機為當前正在運行的虛擬機時(shí)，則不需要做任何的虛擬機切換，只需要確認當前VM的中斷使能位VMn_ICR.IE置1，且其PIPN號大于正在運行的虛擬機的中斷優(yōu)先級號，則直接處理新的中斷，否則新的中斷將處于Pending狀態(tài)。該機制適用于VM0，VM1以及VM2-7。

  
  

• 當產(chǎn)生中斷的響應虛擬機是Hypervisor，而當前正運行在VM1或者VM2-7時(shí)，則需要判斷新中斷的PIPN號是否大于Hypervisor的搶占閾值，如果大于搶占閾值且大于當前的CCPN號，則可以直接切到Hypervisor中執行新的中斷，否則新的中斷將處于Pending狀態(tài)。

  
  

• 當產(chǎn)生中斷的響應虛擬機是VM1，而當前正運行在VM2-7，或者反過(guò)來(lái)的情形，則需要判斷新中斷的PIPN號是否大于正在運行的虛擬機的搶占閾值，如果大于搶占閾值且大于當前的CCPN號，此時(shí)會(huì )產(chǎn)生一個(gè)Hypervisor的Trap，然后在該Trap中做好虛擬機的配置工作，再切到新的虛擬機之后進(jìn)行中斷處理，否則新的中斷將處于Pending狀態(tài)。

  
  

• 當產(chǎn)生的中斷響應虛擬機時(shí)VM2-7，而當前正運行在VM2-7不同于之前虛擬機之中，則需要判斷新中斷的PIPN號是否大于正在運行的虛擬機的搶占閾值，如果大于搶占閾值且大于當前的CCPN號，此時(shí)會(huì )產(chǎn)生一個(gè)的Trap，然后在該Trap中進(jìn)行虛擬機的Swap操作，再切到新的虛擬機之后進(jìn)行中斷處理，否則新的中斷將處于Pending狀態(tài)。

圖13 虛擬機的中斷處理流程

5. 外設虛擬化

外設的訪(fǎng)問(wèn)權限是通過(guò)ACCEN寄存器來(lái)實(shí)現的，只有被ACCEN選中的Master才運行訪(fǎng)問(wèn)該外設的資源。TC3x中Master用6個(gè)bit的Tag ID表示。在TC4x中，我們對Master的定義做了額外的擴展，除了依據TAG ID以外，還額外增加了VM ID和PRS ID，客戶(hù)可以設置任意CPU的任意VM對外設的訪(fǎng)問(wèn)權限。如下圖所示：

圖14 TC3x/TC4x外設寄存器保護

此外，TC4x針對原有的和SafetyEndinit 機制也做了修改，新的PROT和PROTE寄存器保護機制會(huì )兼顧不同虛擬機的寄存器權限設置，將寄存器修改的權限下發(fā)到VM層級。如下圖所示：

圖15 寄存器修改權限

6. IPC通信

區別于之前的核間通信，引入虛擬機之后，還會(huì )涉及到虛擬機之間的通信（圖16）。虛擬機直接按的通信一般可采用Share memory的方式。利用之前章節介紹的內存虛擬化機制，給不同虛擬機開(kāi)辟一塊共享內存用于信息交互。

圖16 虛擬機的IPC通信

7. 虛擬化軟件開(kāi)發(fā)流程和例程

7.1 虛擬化軟件開(kāi)發(fā)流程

一般來(lái)講，虛擬化軟件的開(kāi)發(fā)可以分為四個(gè)步驟（圖17）：

1. 需求定義

首先，客戶(hù)需要根據項目的實(shí)際需求，做系統級的資源分配。將不同的軟件分配到不同的CPU，以及CPU內部不同的VM中去。

2. Hypervisor軟件配置

有了最基本的硬件資源分配之后，客戶(hù)需要開(kāi)發(fā)一個(gè)統一的Hypervisor軟件去管理和調度不同的虛擬機。

• 配置：包括對外設資源的分配，內存保護的設置以及中斷資源的分配等

• 調度：根據客戶(hù)的需求，設置不同的調度策略，如基于時(shí)間觸發(fā)的調度或者基于事件響應的調度策略。

3. 虛擬機開(kāi)發(fā)

Hypervisor軟件開(kāi)發(fā)完成之后，不同的虛擬機開(kāi)發(fā)團隊基于Hypervisor的配置，獨立開(kāi)發(fā)各自的應用，彼此之前沒(méi)有任何外設，內存，中斷的相互干擾。開(kāi)發(fā)完成后，需要基于Hypervisor的調度策略做虛擬機層級的集成測試，以驗證虛擬機應用的基本功能和可靠性。

4. 系統集成測試

不同虛擬機開(kāi)發(fā)團隊將各自的虛擬機集成到ECU中去，基于Hypervisor做系統級的集成測試，以驗證整體功能的完整性和可靠性。

圖17 虛擬機軟件開(kāi)發(fā)流程

7.2 虛擬化軟件例程

7.2.1 Demo工程介紹

英飛凌將多個(gè)TC4x虛擬化的例程放在A(yíng)DS Limited開(kāi)發(fā)環(huán)境中，客戶(hù)可通過(guò)ADS Limited搜索“Hypervisor”或者“Virtualized”等關(guān)鍵詞找到相關(guān)例程。

本文以iLLD_TC4D9_ADS_Virtualization_Hypervisor_StandAlone這個(gè)Demo。該Demo支持All-in-one模式，即Hypervisor和虛擬機軟件在同一個(gè)工程里面。此外，該Demo同時(shí)支持Standalone模式，即上述工程只提供Hypervisor的初始化配置和調度功能，虛擬機軟件需要額外的軟件支持，額外的軟件包含iLLD_TC4D9_ADS_Blinky_LDE_Virtualized和iLLD_TC4D9_ADS_CAN_Loop_Back_Mode_Virtualized兩個(gè)工程。兩個(gè)工程的切換需要通過(guò)Ifx_Cfg.h里面的IFX_CFG_HYPERVISOR_STANDALONE完成。如圖18所示：

圖18 ADS中Hypervisor Demo介紹

7.2.2 Demo工程的啟動(dòng)流程

以All-in-one工程為例，下面是其啟動(dòng)流程（圖19）：

1. 上電之后首先會(huì )運行芯片內部的boot，之后跳轉的VM0的Start函數跑SSW軟件，SSW軟件和TC3x的啟動(dòng)流程類(lèi)似，包括BIST測試，PLL的初始化，CSA的配置，Trap和中斷向量表的配置等待

   
   

2. 之后就正式開(kāi)始Hypervisor軟件的執行，主要包括對每一個(gè)core的初始化配置，L2的MPU保護，各個(gè)虛擬機的中斷配置，調度策略的初始化等等。之后就確定下一個(gè)需要運行的目標虛擬機VM1，調用RFH指令切到VM1虛擬機

   
   

3. 開(kāi)始執行VM1里面的任務(wù)，在完成任務(wù)之后重新切回到Hypervisor里面進(jìn)行下一次虛擬機的調度

圖19 Hypervisor軟件啟動(dòng)流程

7.2.3 Hypervisor的調度策略

該Demo支持兩種調度策略（圖20）：

• Counter Based：基于counter計數（事件觸發(fā)）的調度策略，當Guest VM中的代碼運行到某個(gè)counter值的時(shí)候，通過(guò)調用HVCALL切回Hypervisor，從而完成本次虛擬機的調度

  
  

• Timer-interrupt based：基于STM定時(shí)器中斷（時(shí)間觸發(fā)）的調度策略，STM的中斷響應配置為Hypervisor，當在Guest VM里面運行到某一個(gè)時(shí)刻，STM觸發(fā)中斷，此時(shí)non running VM的中斷會(huì )觸發(fā)Hypervisor Trap進(jìn)入到Hypervisor，Hypervisor Trap的地址對應著(zhù)調度表的地址，從而進(jìn)行下一次調度。

圖20 Hypervisor調度策略

該Demo可以實(shí)現多個(gè)虛擬機的輪詢(xún)調度，客戶(hù)可以根據自身的需求靈活地配置Hypervisor，實(shí)現適合自己項目開(kāi)發(fā)的虛擬機配置和軟件調度策略。

總結

本文首先介紹了TC4x的硬件對虛擬化的全面支持，包括對CPU，Memory，中斷，外設的虛擬化，以及虛擬機之間的IPC通信。其次，從實(shí)際項目開(kāi)發(fā)的角度，介紹了嵌入式虛擬化的開(kāi)發(fā)流程以及Hypervisor的兩種調度策略。嵌入式虛擬化的引入，可以幫助可以更好地實(shí)現資源分配和安全隔離，幫助客戶(hù)節省更多開(kāi)發(fā)和集成的成本。