說明：
本文不考慮EL2，默認NS-EL2、S-EL2都是disabled的
本文以Armv9-aarch64、Armv8-aarch64為基準，不討論aarch32的情況
中斷控制器以gicv3/gicv4為例，不討論其它中斷控制器和gicv2。

前置條件

我們先補充幾個概念：

（1）CPU有三種執行環境(Runtime)：

• CPU執行在ATF
• CPU執行在REE
• CPU執行在TEE

（2）而對于中斷，有3種分類：

• NS-Group 1 ：想給REE處理的中斷
• S-Group 1 ：想給TEE處理的中斷
• Group 0：想給ATF處理的中斷

所以呢，就出現9種情況：

• （1）CPU執行在REE時，來了一個NS-Group 1中斷，想給REE處理的中斷
• （2）CPU執行在ATF時，來了一個NS-Group 1中斷，想給REE處理的中斷
• （3）CPU執行在TEE時，來了一個NS-Group 1中斷，想給REE處理的中斷
• （4）CPU執行在TEE時，來了一個S-Group 1中斷，想給TEE處理的中斷
• （5）CPU執行在ATF時，來了一個S-Group 1中斷，想給TEE處理的中斷
• （6）CPU執行在REE時，來了一個S-Group 1中斷，想給TEE處理的中斷
• （7）CPU執行在ATF時，來了一個Group 0中斷，想給ATF處理的中斷
• （8）CPU執行在TEE時，來了一個Group 0中斷，想給ATF處理的中斷
• （9）CPU執行在REE時，來了一個Group 0中斷，想給ATF處理的中斷

那么接下來，我們就開始分析，這9種情況，在整個多系統的軟硬件架構中，是如何設計、如何處理的。

1、CPU執行在REE時，來了一個NS-Group 1中斷

CPU執行在REE時，來了一個NS-Group 1中斷，想給REE處理的中斷。

在REE執行過程中，當發生一個來自NS-Group 1的中斷時，旨在傳遞給REE處理。鑒于當前CPU處于非安全狀態且中斷類型為NS-Group 1，因此該中斷被標記為IRQ。此時，由于SCR_EL3.IRQ的值為0，所以此IRQ將會被路由至EL1。這一路由機制十分簡潔明了，直接將IRQ傳遞，使得CPU會進入Linux Kernel的異常向量表中的irq向量，從而進行處理。

2、CPU執行在ATF時，來了一個NS-Group 1中斷

CPU執行在ATF時，來了一個NS-Group 1中斷，想給REE處理的中斷。

透過事物看本質，我們可以理解這是一種想給REE處理的中斷，因此最終目標是將CPU重新路由回REE，使其能夠正確處理此中斷。

接下來，我們將探討軟硬件設計問題。當CPU處于ATF執行狀態時，PSTATE.I和PSTATE.F都被屏蔽（MASK），因此，此時CPU不會響應任何中斷，所有產生的中斷都將保持在待處理狀態。只有在CPU從EL3切換回EL3以下狀態時，且PSTATE.F/I解除屏蔽（unmasked）時，待處理的中斷才會被taken。

考慮到CPU從EL3切換到EL3以下狀態有兩種路徑，因此，我們需要對此進行分組討論：

• 當CPU從EL3返回到REE端時，情況等同于“CPU處于REE執行狀態，此時發生一個NS-Group 1中斷”，這會直接觸發將中斷傳遞到Linux內核中的IRQ，使Linux內核能夠繼續處理此中斷。
• 當CPU從EL3返回到TEE端時，情況等同于“CPU處于TEE執行狀態，此時發生一個NS-Group 1中斷”，這時將會重復執行第3小節所述的中斷路由步驟。

3、CPU執行在TEE時，來了一個NS-Group 1中斷

CPU執行在TEE時，來了一個NS-Group 1中斷，想給REE處理的中斷。

透過事物看本質，我們可以理解這是一種想給REE處理的中斷。因此，你的軟硬件協同設計的最終目標是將CPU拉回到REE，讓REE處理這個中斷。

我們接著關注軟硬件的設計。由于當前CPU運行在安全狀態，中斷類型為NS-Group 1，因此中斷被標記為FIQ。然而，考慮到此刻的SCR_EL3.IRQ=0，所以這個FIQ將會被路由至EL1。CPU進入TEE OS的異常向量的FIQ向量，在fiq_handler的實現中，未讀取中斷IAR就調用了smc。這采用了一種主動的軟件調用方式，將CPU切回了ATF。ATF察覺到這是一個中斷轉換過來的情況，因此繼續將CPU切換回REE。在此過程中，該中斷一直保持為掛起狀態。

當CPU被重新引導回REE后，由于此時CPU運行在非安全狀態，中斷類型仍為NS-Group 1，所以該中斷被重新標記為IRQ。隨之而來的是重新觸發中斷，該中斷被target至EL1，與下圖中的步驟4對應。在中斷處理完成后，依次將CPU拉回TEE，使其回到被打斷的位置。

4、CPU執行在TEE時，來了一個S-Group 1中斷

CPU執行在TEE時，來了一個S-Group 1中斷，想給TEE處理的中斷。

由于當前CPU運行在Secure Security State、中斷類型為S-Group 1中斷，所以該中斷被標記為IRQ，由于此時SCR_EL3.IRQ=0，所以該中斷被標記為IRQ，并被target到EL1。所以這種路由很干脆直接，將直接產生IRQ，讓CPU進入TEE OS的異常向量表的irq向量去處理。

5、CPU執行在ATF時，來了一個S-Group 1中斷

CPU執行在ATF時，來了一個S-Group 1中斷，想給TEE處理的中斷。

我們透過事物看本質，這是想給TEE處理的中斷，所以最終的結果，一定是要把CPU拉回到TEE，讓TEE去處理這個中斷。

接下來我們討論軟硬件設計，CPU執行在ATF的時候，此時PSTATE.I和PSTATE.F都是MASK的，所以此時不會taken任何中斷，一切產生的中斷將處于pending狀態。當CPU從EL3切回EL3以下的時候，PSTATE.F/I unmasked的時候，此時pending的中斷才會被taken。由于CPU從EL3切換EL3以下有兩條路徑，所以我們需要分組討論一下：

• 當CPU從EL3往REE側返回后，此時條件等同于“CPU執行在REE時，來了一個S-Group 1中斷”，此時會將第6小節的中斷路由步驟全部再走一遍。
• 當CPU從EL3往TEE側返回后，此時條件等同于“CPU執行在TEE時，來了一個S-Group 1中斷”，也就是將直接產生target到TEE O中的irq，讓TEE繼續處理這個中斷。

6、CPU執行在REE時，來了一個S-Group 1中斷

CPU執行在REE時，來了一個S-Group 1中斷，想給TEE處理的中斷.

我們透過事物看本質，這是想給TEE處理的中斷，所以最終的結果，你的軟硬件協同的設計，一定是要把CPU拉回到TEE，讓TEE去處理這個中斷。

我們再來看軟硬件的設計，由于當前CPU運行在Non Secure Security State、中斷類型為S-Group 1中斷，所以該中斷被標記為FIQ，由于此時SCR_EL3.IRQ=1，所以該FIQ將被target到EL3。CPU 進入 ATF的異常向量的FIQ向量，在ATF的fiq_handler實現中，它會繼續進行中斷轉發，轉發到TEE OS中特定的入口（這里與TEE OS廠商的設計相關，不同廠商有不同的實現），進入TEE OS后，真正處理這個中斷，處理完畢后，再依次返回。

7、CPU執行在ATF時，來了一個Group 0中斷

CPU執行在ATF時，來了一個Group 0中斷，想給ATF處理的中斷。

CPU執行在ATF的時候，此時PSTATE.I和PSTATE.F都是MASK的，所以此時不會taken任何中斷，一切產生的中斷將處于pending狀態。當cpu從EL3切回EL3以下的時候，PSTATE.F/I unmasked的時候，此時pending的中斷才會被take。由于CPU從EL3切換EL3以下有兩條路徑，所以我們需要分組討論一下：

• 當CPU從EL3往REE側返回后，此時條件等同于“CPU執行在REE時，來了一個Group 0中斷”，此時會將第9小節的中斷路由步驟全部再走一遍。
• 當CPU從EL3往TEE側返回后，此時條件等同于“CPU執行在TEE時，來了一個Group 0中斷”，此時會將第8小節的中斷路由步驟全部再走一遍。

8、CPU執行在TEE時，來了一個Group 0中斷

CPU執行在TEE時，來了一個Group 0中斷，想給ATF處理的中斷.

此時根據中斷類型為Group 0，該中斷將被標記為FIQ，根據SCR_EL3.FIQ=0，該fiq將直接被target到EL1，在tee中的fiq_handler中，將采取軟件主動方式將CPU切回ATF，進入ATF后，該中斷仍不會被taken，因為此時PSTATE.I/R都是masked的。直至CPU再返回REE端的時候，將重新產生target到EL3的FIQ，那時中斷才會被處理。

9、CPU執行在REE時，來了一個Group 0中斷

CPU執行在REE時，來了一個Group 0中斷，想給ATF處理的中斷。

由于是Group0中斷，中斷將被標記為FIQ，又由于SCR_EL3.FIQ=1，FIQ將被直接target到EL3，進入ATF的異常向量表的fiq向量進行處理。