书接上一篇文章，这次主要是厘清在ARM体系结构下，EL／PL究竟是个什么东西。这次还是以v8为例，其一是这是目前唯一一个同时包含了32位和64位的体系规范，其二，这也是最新的规范。

首先是PL。PL的概念是从ARM体系规范之前的版本一路升级上来的，并且仍然存在于V8体系的AARCH32，即32位状态下。PL首先是一个权限级别的限制，里边实现了各种各样的mode。这个mode的概念也是32位所特有的，在一个同时实现了安全扩展和虚拟扩展的v7-a的ARM中，各个PE可以使用的mode有usr，只在PL0中使用，可以是安全或者非安全的，一般情况下，用户软件处于非安全态的usr下，而secure的应用程序则处于安全的usr下

sys, und, fiq, irq, svc, abt，只在PL1中，可以是安全或者非安全的，一般情况下，非安全的os或者虚拟扩展下的guest os位于非安全的mode下，而secure os位于安全的mode下

hyp, 只能在非安全态的PL2中，一般情况下，虚拟扩展的hypervisor实现在这个模式

mon，只能在安全态的PL1中，一般情况下，这个mode用于在安全态和非安全态之间切换

这9中mode不仅存在于spec的描述中，同时在结构的设计上，也有其对应的位置。32位状态下的current program status register, CPSR中，有一个位域M编码当前的处理器的状态。此外，一些应用程序可见的通用寄存器，例如LR和SP在一些模式下是banked的，这意味着在不同模式下，存在着不同的LR和SP实体，从体系结构角度讲，在context switch的时候，就无需保存和恢复这些寄存器了。

32位模式下，通用寄存器的bank情况如下：

摘自ARM文档，版权归ARM所有

从上图可以看出，在32位状态下，mode有着其不可替代的作用。此时PL只是一个虚拟的概念，没有地方明确表示当前处于何种PL级别，我们只能够根据当前的mode，以及当前PE的安全状态(存放在另一个系统寄存器SCR.NS中)，来推测出现在是哪个PL。可以说，在32位状态下，mode比PL更重要。

然而，在v8体系中，引入的64位支持下，不再保留mode的概念，并且提出了新的EL概念。在v8中，PE的状态保存在一个叫做叫做PSTATE的结构上。当CPU切到一个EL的时候，之前的状态保存在一个叫做Saved Program Status Register，即SPSR上。SPSR在各个EL之间是banked的，这意味着我们有SPSR_EL1, SPSR_EL2, SPSR_EL3. 因为EL0是用户态，无法处理exception，所以没有SPSR_EL0这个寄存器。

不过话又说回来，当前的cpu状态存放在哪里呢？64位的规范并没有定义一个类似于32位下的CPSR的寄存器保存当前状态，而只是说明当前CPU的状态应该保存有PSTATE这个结构的内容。具体是由什么寄存器实现的，则无规定。我们继续关于CPU状态的讨论，在PSTATE中，有一个一位的nRW，这可不是Read/Write的缩写，而是Register Width的缩写。区分32位和64位最重要的区别，实际上就是通用寄存器的宽度。32位下，通用寄存器都是32位，64位下，通用寄存器都是64位。注意，即使是64位下，指令的长度仍然是32位(而且只能是32位)。当nRW位0的时候，表示当前PE处于64位状态，1则表示为32位状态。PSTATE的定义如下：

摘自ARM文档，版权归ARM所有

在64位状态下，还有两个有趣的部分，EL决定当前处于哪一个Exception Level，而SP则选择当前使用哪个Stack Pointer寄存器。所以，在64位系统下，SP是banked的，而且，除了EL0之外，所有其他的EL层都可以选择，要么是用当前状态特定的SP_ELx，要么是用SP_EL0，前者叫做handler，后者则叫做thread。这两个术语是从V7-R中引入的，所以，可用的PE状态又可以分别叫做ELh和ELt，前者是用自己的SP，后者是用EL0的SP。

摘自ARM文档，版权归ARM所有

然后，让我们回到64位下的SPSR的定义中，如上图所示。我们知道，32位状态产生的exception可以由64位处理，64位产生的exception也可以由64位处理。所以SPSR这个寄存器就需要考虑到在64位状态下，处理的exception究竟来自于哪个状态。在SPSR的定义中，有一个5位的部分M，来标示这一点。M的最高位，M[4]，表示出来的是32位还是64位。如果是64位，则M[3:2]表示excpetion来源的EL级别，而M[1:0]表示其使用的是哪个SP，自己的，还是EL0的。如果M[4]表示当前处于32位状态，则M[3:0]编码32位状态的mode，可选的有usr, fiq, irq, svc, abt, und和sys。注意，这里没有编码hyp和mon两个32位可用的mode。没有mon，这个比较容易理解，因为mon对应64位中security的EL3，故而不会有32位的mon的exception需要64位的EL3处理。然而，如果一个32位，non-sec的EL2，产生一个SMC，需要64位的Secure Monitor处理的时候，SPSR_EL3.M究竟是如何编码的？这个问题目前在Spec中还没有找到答案。

因此，64位系统中EL，从某种程度上，更像是从32位系统中的mode简化而来，而并非由PL扩展而来的。这个就看各人的不同理解了。

V8体系中，统一使用EL来进行权限描述，这不仅包括64位体系AARCH64，还包括32位体系AARCH32。对于64位而言，现在就只有EL了，毕竟64位是新加入的体系。然而对于32位体系而言，同时存在mode，PL和EL，由于向下兼容，32位体系结构变得很是复杂。不过，总的来说，还是有规律可循的mode的概念只存在于32位体系中，如果实现的是64位体系，则只用EL描述，不存在mode的概念

32位体系之上不可能跑64位的程序，即，一个AARCH64产生的exception，不可能由AARCH32来处理

首先，我们考虑一下，假如EL3是由64位实现，而不是32位实现的，系统的组织可能是什么样子？对于非安全的世界，一切与纯32位系统一样，但是对于安全的世界，有个很重要的mode，mon，需要额外处理。现在EL3已经使用64位实现，也就是说在安全世界和非安全世界之间进行切换有了方法，那么就不再需要支持mon mode了。这不仅仅是设计的概念，如果一个chip设计的时候决定EL3支持64位，那么就可以不用为32位系统预留后缀_mon的那些banked的寄存器了。这个时候，大概可能的情况如下：

摘自ARM文档，版权归ARM所有

注意，如果支持虚拟化的话，这个时候non-security的EL2是可选使用32位还是64位的。

另一种情况下，假如我们决定EL3由32位实现呢？这个时候，第一，我们需要在EL3上支持mon mode。第二，想一下我们是否需要再设计一个security的EL1来放置哪些sys/irq/fiq/spv/abt/und呢？这些mode实际上和mon有着相同的访问权限，所以理论上是没必要的，所以，大概的可能如下：

摘自ARM文档，版权归ARM所有

注意，这个时候如果支持虚拟化的话，EL2只能是32位。如果EL2实现为64位，那么由EL2产生的SMC就不可能由EL3处理了。

这就是32位的时候EL与mode之间的对应关系。32位的时候mode和PL之间实际上有这清晰的对应关系，所以EL与PL之间的对应关系这里就不再多说了。