ARM CPU modes和Exception Level
文章目录
ARM CPU Mode
目标：
- 搞清楚ARM PL/EL的区别和联系
ARM32 CPU Mode
PL(Privilege Level)
ARMv8的PL继承自前身版本，分为PL0代表用户态和PL1代表系统态；此外，ARM将PL又划分为7种详细的Mode，其中1种（usr）属于PL0，另外6种属于PL1分别为：
- usr：用户模式
- fiq：处理FIQ快速中断模式
- irq：处理IRQ中断模式
- svc：Supervisor Mode 监视模式
- abt：Abort Mode 所有同内存保护相关的异常均在这种模式下执行
- und：处理无效指令的异常
- sys：系统模式
在ARMv7-A种引入了security扩展和虚拟化扩展
security扩展：支持可信赖的执行环境（trust execution environment, TEE）而引入。security扩展将ARM运行环境分成Secure World和Non-Secure(或Normal) World。
为了实现这两个World的切换，在原PL基础上增加了Monitor Mode。Mon应属于Secure World的PL1
虚拟化扩展：可以在一个物理硬件平台虚拟出多个虚拟化硬件平台供不同的用户使用。ARM为了支持虚拟化扩展，新增了一个PL等级PL2，并新增了Hypervisor Mode，Hyp仅存在于Non-Secure World
ARM32 CPU Mode
在ARM32种，mode有着十分重要的作用。PL只是一个虚拟出来的概念，在体系结构中并没有明确的结果表明为何种PL级别，而是通过不同的mode来标识级别。
ARM64 CPU Mode
EL(Exception Level)
ARMv8体系结构中，统一使用EL来进行权限描述，不仅包括AArch64，还包括32位体系结构AArch32。而对于纯64位体系结构，只有EL；对于32位体系结构因为要被64位兼容，则继续保留了mode、PL和EL。
- 如果实现的是64位体系结构，则只用EL描述，不存在mode概念
- 32位体系结构不能跑64位程序，一个AArch64产生的Exception不可能由AArch32来处理
EL和PL的基础上变化，主要体现在：
- PL0对应EL0
- PL2对应EL2
- 除了Secure下的Monitor外的PL1对应EL1
- 将Secure的Monitor单独抽取谁来，对应EL3
由于EL2的Hypervisor是虚拟扩展引入的，只存在于Non-Secure，所以得出EL模型如下：
EL只会在以下情况之一发生的时候才会发生Level Change
- 发生异常
- 从一个异常返回
- 处理器重启
- 从Debug状态返回
- 在Debug中，执行了DCPSx指令
- 在Debug中，执行了DRPS指令
ARM将PL和EL这两个架构统称为PE
EL、AArch32 modes 和 execution privilege 映射
Exception Level有四个等级：EL0, EL1, EL2, EL3
AArch32 modes有：User, Monitor, System, Supervisor, Abort, Undefined, IRQ和FIQ
在Secure状态：
- Monitor只在EL3执行，并且只有在EL3运行AArch32指令集时才能获得
- System, Supervisor, Abort, Undefined, IRQ, FIQ在：
- 当EL3运行AArch64时在EL1执行
- 当EL3运行AArch32时在EL3运行
总结来说：
- 当EL3在运行AArch64时：
- 不支持Monitor
- 当EL1运行AArch32，那么System, Supervisor, Abort, Undefined, IRQ和FIQ运行在Secure的EL1
- 当EL3在运行AArch32时：
- Monitor运行在Secure的EL3
- System, Supervisor, Abort, Undefined, IRQ和FIQ运行在Secure的EL3
- 不支持Secure下的EL1
在Non-secure状态：
- PL1 modes：System, Supervisor, Abort, Undefined, IRQ和FIQ总是运行在EL1
- User mode总是运行在EL0
- Hyp mode总是运行在Non-secure的EL2
得出下图所示（copy自ARM手册）
