目录

1.中断虚拟化的困惑

2.从R52入手

3.小结

---

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是如何考虑中断虚拟化的呢？