最近在研究ARM体系结构。目前而言，最新的体系规范为第八版，即armv8。armv8中，最吸引人的特性就是引入了64位支持，包括相关指令的扩充和支持、新的地址转换模式的引入等。在这里，我着重关注vmsa，即virtual memory space architecture部分。vmsav8中，最大可支持的物理内存宽度达到了49位。事实上，在armv7时代，如果开启了lpae，即large-physical-address-extension的话，arm本身是能够支持足够大的内存的。在armv8时代，lpae已经成为vmsav8-a的一部分了。
之前在看vmsa的spec 的时候，关于其中提到的EL的概念一直不是很理解。事实上，vmsav8-a中有三种mmu模式，分别是
- vmsav8-32sd，即旧的地址转换模式
- vmsav8-32ld，使用了lpae的地址转换模式，兼容armv7-a中的lpae
- vmsav8-64，使用vmsav8-32ld扩展的地址转换模式
而需要理解这些复杂的地址转换模式之前，如果不了解ARM体系中经常提到的EL/PL，就会看spec看的不知所云。我在看VMSA文档的时候，刚开始不理解什么叫做EL/PL，看的是一头雾水，有时候根本不知道为什么要设计这么复杂的地址映射模式。后来去翻了一下V6和V7的文档，对于ARM中的一些基本概念进行了恶补，这才有种与我心有戚戚焉的感觉。故而才有这篇文章，愿意与大家一同探讨。
EL/PL的全称是Exception Level/Privilege Level，即软件执行环境中，本身所处于低特权级别。如果我们自己设计特权模式，除非是饱经考验，否则最出彩的设计也不过是两个模式，用户一个，系统一个。这事实上也是arm最开始的概念，两个特权模式，一个用户态，称之为unprivilege level，另一个与之对应，自然就是系统态了，privilege level。用户态的软件执行环境用于常用的软件运行，而设计到系统调用等部分，则都归于系统态。这个模式看起来还是合情合理简单粗暴的。
当然，arm刚开始不可能只分这么两种，毕竟看起来太low，不够高大上。最初的时候，arm的软件执行环境有7种之多，分别命名为usr, fiq, irq, svc, abt, und, sys。其中，除了usr位于unprivilege level下之外，其它的六个都位于privilege level下。这七种的详细信息如下：
- usr, user mode
- fiq, 处理FIQ中断模式
- irq, 处理IRQ中断模式
- svc, supervisor mode
- abt, abort mode
- und, undefined mode
- sys, system mode
现在看来虽然有7种之多，然而细细算起来，不过只有PL0和PL1两个而已。如图所示：
然而，考虑到armv7-a中，可选的3个扩展，事情就不是那么简单了，这三个可选的扩展分别是：
- security扩展，为支持建立可信赖的执行环境（trust execution environment, TEE）而引入等扩展。
- 虚拟化扩展，这是arm体系志在进军高阶服务器市场而产生的一个扩展
- lpae，这个相比而言就没有前两者那么清楚，事实上与其说lpae影响到了EL/PL，不如说EL/PL影响到了lpae更加合适。
接下来，我们就看看这些扩展是如何一步步将原本简单的两层，转变成armv8-a中的如此复杂的局面的。
首先，引入了security扩展之后，PL0和PL1就分别有了对应的security和non-security版本。这么做其实也是考虑到无论是security还是non-security的环境下，可能都需要os+software的支持。此外，在security和non-security之间，还应该有一个bridge的地方，因此，引入了monitor mode。这个monitor mode显然应该处于security状态，因为这种模式下需要操纵一些security状态下才能够动的资源，并且显然应当处于特权模式，即位于PL1。引入security扩展的结构就是，PL0和PL1各自在security和non-security世界有一份对应的模式，外加上PL1中引入一个新的monitor模式，负责security和non-security切换的事宜。
接下来，虚拟化扩展。虚拟化扩展最大的好处是，可以在一个物理硬件平台上，虚拟出多个虚拟的硬件平台。这就好比你只有一台笔记本，但是同时跑着windows和linux不同的操作系统。对于终端用户，虚拟化扩展的用处不大，然而在服务器市场，没有虚拟化简直就是不堪入目，更要人老命的是，别人有虚拟化而你没有。
让我们仔细考虑一下虚拟化对于模式的影响。首先可以肯定的一点是，security世界是万万不需要虚拟化的（至少目前而言）。security本身是非常依赖于硬件的，如果这个硬件是在物理硬件上虚拟出来的，那还了得？故而security不能支持虚拟化。那么现在看来，只能在non-security世界实现虚拟化了。
那么为了支持虚拟化，需要做哪些模式的改变呢？现在，在non-security世界，我们有PL0运行usr模式的代码，有PL1运行系统的代码。显然，这是一个硬件系统应当有的基本的特权分层。如果需要支持虚拟化，最简单的方法就是加一个PL2，其特权级别还高于PL1。这也是arm的做法，并且特意在这里，给这种实现虚拟化支持的模式起了一个hyp的名称，hypervisor的缩写。
来让我们看看现在的PL级别：
看起来已经很复杂了，不过别急，这个距离armv8中的模型还有一段距离。前面提到过，armv8最大的变化就是加入了64位支持。在PL上，armv8提出了新的EL的概念。在纯64位环境下，这个EL相对于我们上图其实变化不是很大，主要是将PL0对应EL0，PL2对应EL2，除了security下monitor之外的PL1对应EL1，而将security下的monitor模式单独抽取出来，放到一个EL3上。至此，我们有了EL0到EL3，并且由于EL2是虚拟化引入到，所以只能存在于non-security世界，而EL3是由security引入到，故而只能存在于security世界。现在看来，我们的EL模型大概如下：
图来自于arm官方文档，版权归arm所有
然而，引入64位支持后，还有一个需要额外考量的地方：平台的32位/64位属性。我们都知道，64位系统是可以运行32位软件的，反之则不行。在这里同样，如果高特权的EL实现为64位模式，则其下的特权模式可以选择实现为32位或者64位。然而，如果高特权模式的EL实现为32位，则其下的特权模式只能实现为32位。