在中断流程举例的章节中，有小伙伴仔细读了该篇文章，并产生一些列问题。其中一个问题，一下子把我问到了：“在TEE侧时产生了FIQ，回到REE后为啥又产生了IRQ？”
我们是知道，流程肯定是这么滴的，但具体的硬件原理呢？
在深入研读GICV3文档后，终于找到了答案。
首先我们了解下中断优先级，在CPU interfaces (ICC_*_ELn)寄存器的描述中：
• Provide general control and configuration to enable interrupt handling
• Acknowledge an interrupt
• Perform a priority drop and deactivation of interrupts
• Set an interrupt priority mask for the PE
• Define the preemption policy for the PE
• Determine the highest priority pending interrupt for the PE
也就是cpu interface掌管着中断优先级和将IRQ/FIQ发送给ARM Core.
我们以Level sensitive interrupts的中断为例，先不考虑active and pending的情况：CPU interface发送给Core后，中断状态变为pending，当Core感知到中断后(PE跳转到中断向量表)中断状态变为active，当中断退出后，Cpu interface会再次将优先级最高的中断发送给Core，Core处理下一个中断。
我们再看下中断的退出流程( End of interrupt), 中断的退出有两种方式：
• Priority drop 将中断优先级降到中断产生之前的值
• Deactivation 将中断从active变成inactive
重点来了，在中断退出的时候，软件中一般会有Priority drop和Deactivation，既要么将中断优先级降低，要么将中断变为inactive，那么中断退出之后，cpu interface感知到的优先级最高的中断，就可能不会是此中断了，一切运行正常，符合业务…
那么我们再看下上述的中断流程举例，在TEE中，cpu interface发了一个FIQ给Core，跳转到optee的FIQ向量表，在FIQ的处理流程中，软件几乎什么都没干，没有Priority drop和Deactivation， 那么当SMC切换到了EL3之后,又退回REE后，Cpu interface感知到上一个中断处理完成，会再次发送下一个优先级最高的中断，由于之前的中断号的优先级没变，此时基本上依然是最高的优先级。此时CPU interface会再次发送该中断给Core，由于SCR.NS发生了变化，此时Cpu interface发送给Core的就变成了IRQ…