本文探讨了ARM处理器在异常级别切换时执行状态的转变规则，特别是从高异常级别到低异常级别，以及从低异常级别到高异常级别的状态保持与转换。ARM设计允许执行状态在AArch64和AArch32之间切换，这取决于异常级别的变化。当从EL1到EL0（例如Linux内核到应用）时，EL1的状态（aarch64或aarch32）决定了EL0可能的状态；反之，从EL0到EL1时，EL0的状态不影响EL1的执行状态选择。这种设计确保了系统寄存器的修改在不同执行状态间的一致性和兼容性。
快速链接:
.
👉👉👉 个人博客笔记导读目录(全部) 👈👈👈
在ARM文档中,可以找到如下两句话：
- When the processor moves from a higher to a lower Exception level, the Execution state can stay the same, or it can switch from AArch64 to AArch32.
- When moving from a lower to a higher Exception level, the Execution state can stay the same or switch from AArch32 to AArch64
翻译之后就是: - 如果从高的异常级别切换到低的异常级别，执行状态可以保持不变，也可以从aarch64切换到aarch32；
例如从linux kernel切换到app，如果linux kernel是aarch64，那么app可以是aarch64或aarch32，如果linux kernel是aarch32，那么app只能是aarch32； - 如果从低的异常级别切换到高的异常级别，执行状态可以保持不变，也可以从aarch32切换到aarch64；
例如从app切换到linux kernel，如果app是aarch64，那么linux kernel可以是aarch64或aarch32，如果app是aarch32，那么linux kernel可以是aarch64或aarch32；
其实也可以这样总结：高的异常级别的执行状态，一定要大于等于低的异常级别的执行状态; 即EL1的执行状态要大于等于EL0的执行状态…
那么ARM为什么会有这种设计或约束呢？
我们以linux kernel和app(EL1 <—> EL0)为例来看：
如果linux kernel是aarch64的，那么在linux kernel启动和运行时修改的ARM系统寄存器(如SCTLR\TTBLRx等)，都是以aarch64修改的，这些寄存器的修改当然也会map到aarch32上。
在系统切换app之后，linux kernel中修改的这些寄存器的属性对aarch32/aarch64依然都生效。 故如果EL1是aarch64，那么EL0可以是aarch64或aarch32；
如果linux kernel是aarch32的，那么在linux kernel启动和运行时修改的ARM系统寄存器(如SCTLR\TTBLRx等)，都是以aarch32修改的，这些寄存器的修改不会map到aarch64上。
在系统切换app之后，linux kernel中修改的这些寄存器的属性仅对aarch32生效。 故如果EL1是aarch32，那么EL0只能是aarch32；
扫一扫
4009
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
