说明:
本文不考虑EL2,默认NS-EL2、S-EL2都是disabled的
本文以Armv9-aarch64、Armv8-aarch64为基准,不讨论aarch32的情况
中断控制器以gicv3/gicv4为例,不讨论其它中断控制器和gicv2。
前置条件
我们先补充几个概念:
- 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向量进行处理。
-
SCR
+关注
关注
2文章
150浏览量
44182 -
ARM处理器
+关注
关注
6文章
360浏览量
41718 -
中断处理
+关注
关注
0文章
94浏览量
10967 -
LINUX内核
+关注
关注
1文章
316浏览量
21644 -
中断控制器
+关注
关注
0文章
59浏览量
9452
发布评论请先 登录
相关推荐
评论