一、中斷示例展示（不含虛擬化部分）

環境配置:在linux/optee雙系統環境下, linux系統的SCR.IRQ=0、SCR.FIQ=1, optee系統的SCR.IRQ=0、SCR.FIQ=0

說明:group1是非安全中斷、secure group1是安全中斷

1、當cpu處于REE，來了一個非安全中斷

當cpu處于normal側時，來了一個非安全中斷，根據SCR.NS=1/中斷在group1組，cpu interface將會給cpu一個IRQ，(由于SCR.IRQ=0，IRQ將被routing到EL1)，cpu跳轉至linux的irq中斷異常向量表， 處理完畢后再返回到normal(linux)側.

2、當cpu處于TEE，來了一個安全中斷

當cpu處于secure側時，來了一個安全中斷，根據SCR.NS=0/中斷在secure group1組，cpu interface將會給cpu一個IRQ，(由于SCR.IRQ=0，IRQ將被routing到EL1)，cpu跳轉至optee的irq中斷異常向量表， 處理完畢后再返回到secure(optee)側.

3、當cpu處于TEE，來了一個非安全中斷

當cpu處于secure側時，來了一個非安全中斷，根據SCR.NS=0/中斷在group1組，cpu interface將會給cpu一個FIQ，(由于SCR.FIQ=0，FIQ將被routing到EL1),跳轉至optee的fiq中斷異常向量表,再optee的fiq處理函數中，直接調用了smc跳轉到ATF， ATF再切換至normal EL1(linux)， 此時SCR.NS的狀態發生變化，根據SCR.NS=1/中斷在group1組，cpu interface會再給cpu發送一個IRQ異常，cpu跳轉至linux的irq中斷異常向量表，處理完畢后，再依次返回到ATF---返回到optee

4、當cpu處于REE，來了一個安全中斷

當cpu處于normal側時，來了一個安全中斷，根據SCR.NS=0/中斷在group1組，cpu interface將會給cpu一個FIQ，(由于SCR.FIQ=1，FIQ將被routing到EL3),在EL3(ATF)中，判斷該中斷是需要optee來處理的，會切換到optee。此時SCR.NS的狀態發生變化，根據SCR.NS=0/中斷在secure group1組，cpu interface會再給cpu發送一個IRQ異常,cpu跳轉至optee的irq中斷異常向量表， 處理完畢后再依次返回到ATF---返回到linux

5、當cpu處于ATF時，來了一個安全中斷或非安全中斷(G1NS、G1S)

當cpu處于EL3時，來得任何target到EL3的中斷，都將被標記位FIQ

當cpu處于EL3時，配置SCR.XXX（XXX=EA或IRQ或FIQ）為0的中斷不會被taken，配置SCR.XXX為1的中斷將會直接target到EL3。

所以在 linux系統的SCR.IRQ=0、SCR.FIQ=1, optee系統的SCR.IRQ=0、SCR.FIQ=0的場景下，總結如下，當cpu運行在EL3時：

• SCR_EL3為optee的cpu context時，來了一個G1S，中斷將不會被taken

• SCR_EL3為optee的cpu context時，來了一個G1NS，中斷將不會被taken

• SCR_EL3為linux的cpu context時，來了一個G1S，中斷將會直接target到EL3

• SCR_EL3為linux的cpu context時，來了一個G1NS，中斷將不會被taken

6、當cpu處于EL3/EL2/EL1/EL0時，來了一個ATF(group0)中斷(G0)

當cpu處于EL3/EL2/EL1/EL0時，來了一個G0中斷，中斷將被標記位FIQ

在 linux系統的SCR.IRQ=0、SCR.FIQ=1, optee系統的SCR.IRQ=0、SCR.FIQ=0的場景下，總結如下：

• 當cpu正在Non-secure EL0/1/2運行時，來了G0中斷，中斷被標記為FIQ，直接target到EL3

• 當cpu正在secure EL0/1/2運行時，來了G0中斷，中斷被標記為FIQ，中斷target到了EL0/1/2，在該程序的fiq_offset會調用smc將cpu切回到EL3，到了EL3之后，中斷不會被taken, 會繼續返回到Non-secure EL0/1/2，然后cpu interface重新給core發送FIQ，接著又是直接target到EL3，EL3處理該中斷。

• 當cpu正在EL3時，來了一個G0中斷，中斷會被標記為FIQ，中斷target到EL3。

7、思考-中斷流程舉例:在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 acknowledge中斷后(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...

8、思考-G1NS G1S G0都有可能產生target到EL3的FIQ，如何區分？

其實在我們的linux系統的SCR.IRQ=0、SCR.FIQ=1, optee系統的SCR.IRQ=0、SCR.FIQ=0的場景下，不考慮aarch32的情況，有兩種情況會產生target到EL3的FIQ：

• （1）cpu在EL0/1/2運行時，來了一個G0中斷，最終CPU將會進入到EL3的向量表中的第三組向量表。

• （2）ccpu在EL3運行時，來了一個G0中斷，最終CPU將會進入到EL3的向量表中的第二組向量表 不過很遺憾，ATF中的向量表中未實現第二組向量表。那么為什么不需要實現呢？在ATF/docs/firmware-design.md中找到了答案, 原來是在進入ATF之前，disable了所有的exception，ATF又沒有修改PSTATE.DAIF，所有在ATF Runtime時 irq/fiq/serror/svnc都是disabled。所以異常向量表的第二行，也就用不著了。

Required CPU state when calling bl31_entrypoint() during cold boot
This function must only be called by the primary CPU.
On entry to this function the calling primary CPU must be executing in AArch64EL3, little-endian data access, and all interrupt sources masked:

• PSTATE.EL = 3

• PSTATE.RW = 1

• PSTATE.DAIF = 0xf

• SCTLR_EL3.EE = 0

• （3）cpu在normal EL0/1/2/3運行時(Linux側的SCR_EL3.FIQ=1的情況下)，來了一個G1S中斷，CPU將會target到EL3的向量表中的第三組向量表。

那么在ATF中第三組向量表中的fiqoffset中，是如何區分上述(1)(3)中的場景呢，即如何區分該中斷是給EL3 handler處理的，還是給optee的handler處理的？此時1020-1023號中斷發生了作用。

我們應該會用到1020，那么用在哪里的呢？請看上述匯編代碼bl platicgetpendinginterrupttype的具體實現:

1. uint32_t plat_ic_get_pending_interrupt_type(void)

2. {

3. unsignedint irqnr;

5. assert(IS_IN_EL3());

6. irqnr = gicv3_get_pending_interrupt_type();

8. switch(irqnr) {

9. case PENDING_G1S_INTID:

10. return INTR_TYPE_S_EL1;

11. case PENDING_G1NS_INTID:

12. return INTR_TYPE_NS;

13. case GIC_SPURIOUS_INTERRUPT:

14. return INTR_TYPE_INVAL;

15. default:

16. return INTR_TYPE_EL3;

17. }

18. }

其實就是在讀取pending的中斷號，看看有沒有1020或1021，從而獲得此次的中斷是從secure或non-secure過來的，還是在EL3產生的。然后走相應的邏輯。

二、中斷示例展示（虛擬化部分）

影響中斷routing的相關控制位主要是 HCR_EL2.IMO/FMO/AMO（本文只探討irq/virq，所以我們只看 IMO比特位），除此之外還有 HCR_EL2.TGE比特位影響Application是做為Host還是Guest.

以下是這些比特位的路由規則的總結：

我們學習了其原理之后，我們再看4個示例：(1)、HCREL2.IMO=1 , HCREL2.TGE=1 --routing到EL2，Application做為Guest

(2)、HCREL2.IMO=1 , HCREL2.TGE=0 --routing到EL2，Application做為Host

(3)、HCREL2.IMO=0 , HCREL2.TGE=1 --routing到EL1，Application做為Guest

(4)、HCREL2.IMO=0 , HCREL2.TGE=0 --routing到EL1，Application做為host

審核編輯 ：李倩