引言
在之前的《AURIX™ TC4x虚拟化技术助力下一代汽车EE架构设计》一文中，我们已经介绍了嵌入式虚拟化的发展历史，基本概念，使用案例，它的优势以及当前面临的挑战。接下来，我们将深入探讨TC4x对虚拟化技术的硬件支持，软件开发流程以及现有的软件Demo。
1. AURIX™ TC4x虚拟化硬件架构
AURIX™ TC4x在硬件上全面支持虚拟化技术，包括CPU虚拟化，内存虚拟化，中断虚拟化，外设虚拟化以及虚拟机之间的IPC通信（如图1所示）
图1 AURIX™ TC4x虚拟化架构
2. CPU虚拟化
2.1 CPU虚拟化的硬件支持
我们知道，CPU的软件运行状态通过一套硬件资源簇来管理，图2是AURIX™ TC3x 1.6.2内核的硬件资源簇。
图2 AURIX™ TC3x内核硬件资源簇
TC4x 内核架构从1.6.2升级到1.8，一个重要的改变就是增加了对虚拟化的支持。为此，TC4x采用了三套硬件资源簇（HRA，HRB和HRHV）来管理CPU的运行（图3）。
图3 TC4x硬件资源簇
TC4x最多支持6个CPU，每一个CPU最多支持8个虚拟机。其中，VM0用作Hypervisor，负责调度上层的7个虚拟机（Guest VM），并由硬件资源簇HRHV来管控；VM1是一个实时虚拟机，独享硬件资源簇HRA；另外6个虚拟机VM2-VM7，共享硬件资源簇HRB，可通过轮询调度的方式去占用HRB。如图4所示：
图4 TC4x硬件资源簇与虚拟机的对应关系
内核复位后，虚拟化功能默认是打开的。通过修改VCON0的EN位，用户可以去使能或禁用某一个CPU的虚拟化功能。需要注意的是VCON0.EN位具有“write once”的属性，即在系统的一个上电周期内只能修改一次，二次修改该值无效。
每个CPU同一时刻只能有一个虚拟机运行，用户可以通过读取VCON1的CVMN位获取当前运行的虚拟机的Number。而下一个需要运行的目标虚拟机，则可以通过VCON2的VMN位进行设置。此外，为了支持虚拟机之前的切换，TriCore1.8内核引入了两个新的指令，RFH（Return from Hypervisor）和HVCALL：
RFH：用于Hypervisor到上层Guest VM的切换。客户在Hypervisor软件中调用RFH指令，则可以实现从Hypervisor到其他目标虚拟机的切换。
HVCALL：类似之前TriCore1.6的SYSCALL，用于上层Guest VM到Hypervisor的切换。因为上层VM之间不能直接切换，需要Hypervisor来统一调度，所以上层虚拟机执行完成之后，需要调用HVCALL回到Hypervisor软件中去。
2.2 虚拟机在CPU中的部署
CPU在复位之后都会先进入VM0（也就是Hypervisor软件），在Hypervisor中完成硬件资源的初始化后，则开始进行虚拟机的调度，虚拟机在CPU中的部署有如下几种：
Hypervisor上层只有一个虚拟机VM1运行（图5.a）：类似传统的CPU，用户进入VM0之后可以直接切换到VM1，VM1独享CPU的硬件资源和周期性任务。
Hypervisor上层有两个虚拟机VM1和VM2运行（图5.b）：用户需要分别为VM1和VM2分配硬件资源，Hypervisor需要根据客户的需求调度VM1和VM2。
Hypervisor上层有两个以上VM运行（图5.c）：由于VM2-VM7是共享一套资源簇HRB，所以每次切换到HRB进行操作时，需要特别指定是哪一个VM进行操作，一般客户可以通过轮询的方式去调度HRB里面的虚拟机。
图5 虚拟机在CPU中的部署
以上是单核的情况，在多核场景下，每一个核都可以灵活地使用不同的虚拟机分配机制来实现整个系统的调度，如图6所示：
图6 TC4x多核虚拟化
图7是虚拟机在不同CPU内部署的示例，假设我们有两个应用APP1和APP2，它们分别占用CPU0/1/2/3/4的VM1和CPU3/4/5的VM2。可以看到，不同CPU里面Hypervisor的调度是不同的，有可能存在一个VM独享CPU的情况（CPU0/1/2/5），也有可能需要Hypervisor去调度多个虚拟机（CPU3/4），具体如何使用可以根据客户的需求灵活配置。
图7 虚拟化部署示例
3. 内存虚拟化
在TC2x/TC3x的内核架构中，内存保护都是任务层级的。操作系统通过MPU模块，对不同任务设置Memory的访问权限。这一功能在TC4x的内核架构中依然沿用，并且我们将任务层级的MPU保护称作Level 1 MPU。而当我们使能了虚拟化功能后，对于不同虚拟机之间的访问保护，则需要额外的MPU保护，我们将不同Guest VM（VM1-VM7）之间的MPU保护称作Level 2 MPU。如图8所示：
图8 TC4x L1/L2 MPU
3.1 Level 1 MPU保护
L1的MPU保护是通过HRx_CORECON.PROTEN寄存器的PROTEN位来使能。HRHV，HRA和HRB均可以独立设置是否使能L1的MPU保护。TC4x支持多达24个数据段和16个代码段的访问权限设置。客户可以在每一个VM的RTOS中，通过配置CPXEy，DPWEy以及DPREy寄存器来选择自身VM运行访问的数据段和代码段，并通过配置CPUx_HRx_PSW寄存器的PRS2和PRS位来切换不同任务需要保护的数据和代码段，TC4x最多支持8个保护寄存器簇（PRS0-PRS7）。图9是L1 MPU保护所涉及到的寄存器示意图。
图9 L1 MPU保护寄存器
3.2 Level 2 MPU保护
在使能了虚拟化功能之后，L2的MPU保护默认是开启的，用户可以根据自身需求，在Hypervisor软件中配置不同虚拟机的访问权限。HRHV_CPXE_x，HRHV_DPRE_x以及HRHV_DPWE_x中的x由VCON2.L2_PRS位来确定，其他的配置部分与L1 MPU相同。图10是L1 MPU保护所涉及到的寄存器示意图。
图10 L2 MPU保护寄存器
需要注意的是，如果系统出现L1 MPU的访问越界，则会触发硬件资源的Trap，如果出现L2 MPU访问的访问越界，则会触发Hypervisor的Trap。如果同时违背的L1 MPU和L2 MPU，则会按照L1 MPU的访问越界响应。
4. 中断虚拟化
4.1 中断虚拟化的硬件支持
如下图所示，是TC3x和TC4x的服务请求控制寄存器（SRC），可以看到对于TC4x的SRC寄存器，除了我们熟悉的优先级配置SRPN，服务请求使能位SRE，以及服务控制类型TOS以外，还额外增加了VM的位域。这表明，对于每一个中断服务请求节点，用户可以设置VM0-VM7的选项，从而将中断的处理映射到某一个CPU的某一个VM中去。
图11 TC3x/TC4x SRC寄存器对比
4.2 虚拟机的中断仲裁和响应机制
中断控制单元ICU会对不同硬件资源簇内部的虚拟机中断服务请求进行仲裁，虚拟机是否参与仲裁由寄存器VMEMz.VMy的配置决定。仲裁采用轮询机制，VM0-VM1-VMz依次轮询，其中VMz表示的是HRB里面的虚拟机，HRB内部也按照轮询机制进行二级仲裁。当某一个虚拟机参与仲裁之后，其产生的最高优先级的中断服务请求会更新到VMxn_ICR的PIPN位等待ICU的仲裁。如下图（图12）所示：
图12 虚拟机的中断仲裁
此外，虚拟机的中断还支持抢占功能，用户可以对每一个虚拟机的中断设置抢占阈值，只有高于该阈值的优先级中断才可以抢占当前的虚拟机中断。该功能可通过配置VMn_PETHRESH寄存器的的PE_THRESH位域实现。
整个虚拟机的中断处理流程如下（图13）：
当产生中断的响应虚拟机为当前正在运行的虚拟机时，则不需要做任何的虚拟机切换，只需要确认当前VM的中断使能位VMn_ICR.IE置1，且其PIPN号大于正在运行的虚拟机的中断优先级号，则直接处理新的中断，否则新的中断将处于Pending状态。该机制适用于VM0，VM1以及VM2-7。
当产生中断的响应虚拟机是Hypervisor，而当前正运行在VM1或者VM2-7时，则需要判断新中断的PIPN号是否大于Hypervisor的抢占阈值，如果大于抢占阈值且大于当前的CCPN号，则可以直接切到Hypervisor中执行新的中断，否则新的中断将处于Pending状态。
当产生中断的响应虚拟机是VM1，而当前正运行在VM2-7，或者反过来的情形，则需要判断新中断的PIPN号是否大于正在运行的虚拟机的抢占阈值，如果大于抢占阈值且大于当前的CCPN号，此时会产生一个Hypervisor的Trap，然后在该Trap中做好虚拟机的配置工作，再切到新的虚拟机之后进行中断处理，否则新的中断将处于Pending状态。
当产生的中断响应虚拟机时VM2-7，而当前正运行在VM2-7不同于之前虚拟机之中，则需要判断新中断的PIPN号是否大于正在运行的虚拟机的抢占阈值，如果大于抢占阈值且大于当前的CCPN号，此时会产生一个的Trap，然后在该Trap中进行虚拟机的Swap操作，再切到新的虚拟机之后进行中断处理，否则新的中断将处于Pending状态。
图13 虚拟机的中断处理流程
5. 外设虚拟化
外设的访问权限是通过ACCEN寄存器来实现的，只有被ACCEN选中的Master才运行访问该外设的资源。TC3x中Master用6个bit的Tag ID表示。在TC4x中，我们对Master的定义做了额外的扩展，除了依据TAG ID以外，还额外增加了VM ID和PRS ID，客户可以设置任意CPU的任意VM对外设的访问权限。如下图所示：
图14 TC3x/TC4x外设寄存器保护
此外，TC4x针对原有的和SafetyEndinit 机制也做了修改，新的PROT和PROTE寄存器保护机制会兼顾不同虚拟机的寄存器权限设置，将寄存器修改的权限下发到VM层级。如下图所示：
图15 寄存器修改权限
6. IPC通信
区别于之前的核间通信，引入虚拟机之后，还会涉及到虚拟机之间的通信（图16）。虚拟机直接按的通信一般可采用Share memory的方式。利用之前章节介绍的内存虚拟化机制，给不同虚拟机开辟一块共享内存用于信息交互。
图16 虚拟机的IPC通信
7. 虚拟化软件开发流程和例程
7.1 虚拟化软件开发流程
一般来讲，虚拟化软件的开发可以分为四个步骤（图17）：
1. 需求定义
首先，客户需要根据项目的实际需求，做系统级的资源分配。将不同的软件分配到不同的CPU，以及CPU内部不同的VM中去。
2. Hypervisor软件配置
有了最基本的硬件资源分配之后，客户需要开发一个统一的Hypervisor软件去管理和调度不同的虚拟机。
配置：包括对外设资源的分配，内存保护的设置以及中断资源的分配等
调度：根据客户的需求，设置不同的调度策略，如基于时间触发的调度或者基于事件响应的调度策略。
3. 虚拟机开发
Hypervisor软件开发完成之后，不同的虚拟机开发团队基于Hypervisor的配置，独立开发各自的应用，彼此之前没有任何外设，内存，中断的相互干扰。开发完成后，需要基于Hypervisor的调度策略做虚拟机层级的集成测试，以验证虚拟机应用的基本功能和可靠性。
4. 系统集成测试
不同虚拟机开发团队将各自的虚拟机集成到ECU中去，基于Hypervisor做系统级的集成测试，以验证整体功能的完整性和可靠性。
图17 虚拟机软件开发流程
7.2 虚拟化软件例程
7.2.1 Demo工程介绍
英飞凌将多个TC4x虚拟化的例程放在ADS Limited开发环境中，客户可通过ADS Limited搜索“Hypervisor”或者“Virtualized”等关键词找到相关例程。
本文以iLLD_TC4D9_ADS_Virtualization_Hypervisor_StandAlone这个Demo。该Demo支持All-in-one模式，即Hypervisor和虚拟机软件在同一个工程里面。此外，该Demo同时支持Standalone模式，即上述工程只提供Hypervisor的初始化配置和调度功能，虚拟机软件需要额外的软件支持，额外的软件包含iLLD_TC4D9_ADS_Blinky_LDE_Virtualized和iLLD_TC4D9_ADS_CAN_Loop_Back_Mode_Virtualized两个工程。两个工程的切换需要通过Ifx_Cfg.h里面的IFX_CFG_HYPERVISOR_STANDALONE完成。如图18所示：
图18 ADS中Hypervisor Demo介绍
7.2.2 Demo工程的启动流程
以All-in-one工程为例，下面是其启动流程（图19）：
上电之后首先会运行芯片内部的boot，之后跳转的VM0的Start函数跑SSW软件，SSW软件和TC3x的启动流程类似，包括BIST测试，PLL的初始化，CSA的配置，Trap和中断向量表的配置等待
之后就正式开始Hypervisor软件的执行，主要包括对每一个core的初始化配置，L2的MPU保护，各个虚拟机的中断配置，调度策略的初始化等等。之后就确定下一个需要运行的目标虚拟机VM1，调用RFH指令切到VM1虚拟机
开始执行VM1里面的任务，在完成任务之后重新切回到Hypervisor里面进行下一次虚拟机的调度
图19 Hypervisor软件启动流程
7.2.3 Hypervisor的调度策略
该Demo支持两种调度策略（图20）：
Counter Based：基于counter计数（事件触发）的调度策略，当Guest VM中的代码运行到某个counter值的时候，通过调用HVCALL切回Hypervisor，从而完成本次虚拟机的调度
Timer-interrupt based：基于STM定时器中断（时间触发）的调度策略，STM的中断响应配置为Hypervisor，当在Guest VM里面运行到某一个时刻，STM触发中断，此时non running VM的中断会触发Hypervisor Trap进入到Hypervisor，Hypervisor Trap的地址对应着调度表的地址，从而进行下一次调度。
图20 Hypervisor调度策略
该Demo可以实现多个虚拟机的轮询调度，客户可以根据自身的需求灵活地配置Hypervisor，实现适合自己项目开发的虚拟机配置和软件调度策略。
总结
本文首先介绍了TC4x的硬件对虚拟化的全面支持，包括对CPU，Memory，中断，外设的虚拟化，以及虚拟机之间的IPC通信。其次，从实际项目开发的角度，介绍了嵌入式虚拟化的开发流程以及Hypervisor的两种调度策略。嵌入式虚拟化的引入，可以帮助可以更好地实现资源分配和安全隔离，帮助客户节省更多开发和集成的成本。
来源：英飞凌汽车电子生态圈
免责声明：本文为转载文章，转载此文目的在于传递更多信息，版权归原作者所有。本文所用视频、图片、文字如涉及作品版权问题，请联系小编进行处理（联系邮箱：cathy@eetrend.com）。
