目录
1.中断虚拟化的困惑
在车控类控制器里,中断对于我们来说是非常宝贵的资源,可大幅提高系统实时性。
这些中断基本都属于实际物理硬中断(软中断另说),例如对一个按键按下的中断响应,对于CAN报文的接收中断响应,这些都已经玩的比较熟练了。
但当我发现MCU也能开始谈虚拟化的时候,中断开始变得有趣起来,我们以Type 1类Hypervisor为例,它结构如下图示:
假设现在系统出现一个物理中断,这个物理中断实际上是至少应该要分配给VM0-VM4中一个进行处理,由于VM是分时复用,问题就来了:
- 中断应该由谁来进行分配?
- 假设被分配到的VM此时还没有运行怎么办?
- 假设被分配到的VM此时正在处理中断怎么办?
带着这些问题,我们来畅想一下关于虚拟化的中断处理,不一定准确,但先记录思考过程。
2.从R52入手
ARM Cortex-R52是Armv8-R架构,目前很多大厂用它来做MCU,目标区域控制器,原因除了高实时性之外,还有就是支持虚拟化。
该内核包含了三个异常等级EL0-EL2,其中EL2具有完整资源访问权限,主要运行Hypervisor;EL1除了不能访问Hypervisor相关寄存器其余均可访问,EL0权限有限;同时新增了两级MPU,为虚拟化奠定基础,其推荐用法如下:
关于中断R52使用GIC进行路由,概念如下:
- SPI(Shared Peripheral Interrupts):由外设产生的中断,需路由给目标核
- PPI(Private Peripheral Interrupts):内核内部产生的中断,如Timer;
- SGI(Software Generated Interrupts):软件触发的中断,可以路由给不同Cluster的内核
那么当一个实际物理中断触发后,它应该给谁呢?
逻辑上讲,按照以前跑无虚拟化的AUTOSAR OS的方案,我们应该把直接把中断传给目标VM,如下图:
但是如果此时VM2没有运行,那这个中断如何处理?如果要从其他VM切换过来那意味着还得有个帮手来帮忙存储当前运行VM的上下文。如果一个物理中断是多个VM复用,这种方式就显得不合理了。
故我们可以在Hypervisor层级捕获物理中断,然后生成虚拟中断给到目标VM,如下图:
这样一看就比较合理了,事实上在R52里,可以看到针对中断虚拟化也是上述两种实现方式,与中断虚拟化相关的组件包括系统寄存器HCR(Hyp Configuration Register)、GIC(Generic Interrupt Controller)。
当我们设置HCR.IMO、HCR.FMO为1时,表示IRQ\FIQ将会在EL2等级下进行处理,
而EL2一般用于运行Hypervisor,故需要在Hypervisor里对IRQ\FIQ进行处理,即使此时VM还处于运行,也会立即跳转至EL2的异常向量中。
假设该物理IRQ需要路由给VM1,此时该怎么办呢?需要Hypervisor配置GIC CPU interface关于虚拟中断内容,如下图:
总结下来,中断虚拟化的流程基本如下:
- 设置HCR.IMO\FMO等;
- 物理中断产生被路由到Hypervisor
- Hypervisor 配置GIC ICV()相关寄存器,产生虚拟中断;
- 返回EL1 OS,OS从虚拟GIC相关寄存器读取中断信息,处理中断
3.小结
其实不管内核怎么变,针对中断虚拟化无非就是上面两种,要么透传给VM,要么由Hypervisor统一分发。
那么,作为车规MCU龙头的英飞凌在TC4xx是如何考虑中断虚拟化的呢?