蜗窝科技
蜗窝科技

ARMv8-a架构简介

wowo · · ARMv8A Arch · 阅读 94857 · 2015年7月存档

1. 前言

ARMv8（当前只有A系列，即ARMv8-A）架构，是ARM公司为满足新需求而重新设计的一个架构，是近20年来，ARM架构变动最大的一次。它引入的Execution State、Exception Level、Security State等新特性，已经和我们对旧的ARM架构的认知，有很大差距了。

因此，本文从ARMv8-A产生的背景开始，对它进行一个简单的介绍，使大家从整体上，对ARMv8有一个简单的了解。

2. 背景

本节参考自“http://www.arm.com/zh/files/downloads/ARMv8_white_paper_v5.pdf”，感兴趣的同学可以自行阅读。

有一点是可以确定的，ARM诞生时，对Intel主导的PC市场，没有（也不敢有）一点点的非分之想。最初的ARMv4（ARM7系列），到最近的ARMv7（Cortex-A,-M,-R系列），都是针对功耗比较敏感的移动设备的，就性能而言，基于ARM处理器的设备，始终无法和PC相提并论。

但从ARMv7开始，情况开始有些转变，ARM的市场开始扩展到移动设备之外的其它领域，这也是ARMv7划分为A（Application）、R（Real-time）和M（Microcontroller）三个系列的原因，其实质就是三个细分市场，其中的A系列，就是针对性能要求较高的应用。

特别是在Cortex-A9之后，ARM的处理性能有很大的提高，渐渐的吸引了一些PC用户。因此基于ARM的类PC产品，如平板电脑，开始大量涌现。此时，ARM的处理能力，已经有机会应用于其它领域了，如企业设备、服务器等，当然，其优势依然是低功耗。

与此同时，新的趋势正在酝酿，主要包括大内存（Large Memory）、虚拟化（Virtualization）和安全（Security）。Virtualization在ARMv7上已经有简单的硬件实现，Security也有可能基于当前架构扩展，唯有Large memory的需求，有点棘手。

由于处理器性能越来越强，运行于其上的软件也来越复杂，复杂到单一应用对内存的需求可能超出32-bit架构所能支持的最大内存（4G），这就是Large memory需求的起因。不过，后来的Cortex-A15（ARMv7架构）通过Large Physical Address Extensions (LPAE) 技术，可以支持高达40bits的物理地址空间。但受限于32-bit的指令集，虚拟地址空间依旧只有32bits（4G），如果有应用需要更大的虚拟内存，怎么办？只能定义一个新的架构，使用64-bit的指令集（也即我们常说的ARM64）。

毫无疑问，在现阶段，需要超过4G虚拟内存的应用场景，是非常少的。但ARM还是定义了一个新的架构–ARMv8，为什么呢？下面是ARM的解释（只有伟大的公司才有伟大的理念！）：

Trends. That’s really what ARM has to look at when defining a new architecture. That is the nature of our business, we need to look a long way forward, and plan.

当然，ARMv8并不仅仅是为了解决虚拟地址的问题，它也要解决现有架构的一些问题。不过，新的问题又来了：一个新的架构？用户为什么要使用新的架构？因此，ARMv8的定义，必须先满足如下前提条件：

1）对上兼容。

2）能解决现存架构的已知问题。

3）相比现存架构，必须具备优势明显的新特性，哪怕软件从来不使用这些新特性。

以上就是ARMv8-a产生的背景，也是ARMv8-a架构之所以是“这个”样子的直接原因。那么到底是什么样子呢？我们继续介绍。

3. ARMv8-a架构简介

基于上面的前提条件，ARMv8-a架构的主要特性包括：

1）新增一套64-bit的指令集，称作A64。

2）由于需要向前兼容ARMv7，所以同时支持现存的32-bit指令集，称作A32和T32（也即我们熟悉的ARM和Thumb指令集）。

3）定义AArch64和AArch32两套运行环境（称作Execution state），分别执行64-bit和32-bit指令集。软件可以在需要的时候，切换Execution state。

4）AArch64最大的改动，使用新的概念（exception level），重新解释了processor mode、privilege level等概念，具体可参考第4章的介绍。

5）在ARMv7 security extension的基础上，新增security model，支持安全相关的应用需求。

6）在ARMv7 virtualization extension的基础上，提供完整的virtualization框架，从硬件上支持虚拟化。

4. AArch64 Exception level

Exception level，是ARMv8-a引入的一个新概念，用于整合之前架构中processor mode和privilege level相关的功能。

4.1 ARMv7之前的实现

我们知道，以前的ARM架构，处理器可以工作在多种模式（称作processor mode）下，包括User、FIQ、IRQ、Abort、Undefined、System等，之所以存在不同的模式，主要有2个方面的考虑：

1）不同的处理器模式，有不同的硬件访问权限，称作privilege level。

主要有2个level，privilege和non-privilege。其中只有User模式属于non-privilege level，其它均是privilege level。

安全起见，大多数时候，软件都运行在User mode。一旦需要其它操作，则需要切换到相应的privilege模式下。这是最原始、最朴素的安全思想，当然，只防君子，不防小人。

2）这些处理器模式，除User模式外，其它模式基本上和各类异常一一对应。而不同的模式，都有一些自己独有的寄存器，例如R13(SP)、R14(LR)等等，可以使模式切换过程（也是异常处理过程）更为高效、便利。

4.2 ARMv7-a的实现

ARMv7-a基本保留了之前的设计，不同之处，将privilege level命名了，称作PL0和PL1（也许您猜到了，后来出现了PL2，用于虚拟化扩展（Virtualization Extension）。

另外，增加了两个模式：Monitor和Supervisor，分别用于security扩展和virtualization扩展。

4.3 ARMv8-a的实现

可能ARMv8-a的设计者觉得之前的设计有些啰嗦，就把processor mode的概念去掉（或者说淡化）了，取而代之的是4个固定的Exception level，简称EL0-EL3。同时，也淡化了privilege level的概念。Exception level本身就已经包好了privilege的信息，即ELn的privilege随着n的增大而增大。类似地，可以将EL0归属于non-privilege level，EL1/2/3属于privilege level。

这些Exception level的现实意义是（如下图，先忽略Secure model有关的内容）：

aarch32_exception_levels

ARMv8-a Exception level有关的说明如下：

1）首先需要注意的是，AArch64中，已经没有User、SVC、ABT等处理器模式的概念，但ARMv8需要向前兼容，在AArch32中，就把这些处理器模式map到了4个Exception level。

2）Application位于特权等级最低的EL0，Guest OS（Linux kernel、window等）位于EL1，提供虚拟化支持的Hypervisor位于EL2（可以不实现），提供Security支持的Seurity Monitor位于EL3（可以不实现）。

3）只有在异常发生时（或者异常处理返回时），才能切换Exception level（这也是Exception level的命名原因，为了处理异常）。当异常发生时，有两种选择，停留在当前的EL，或者跳转到更高的EL，EL不能降级。同样，异常处理返回时，也有两种选择，停留在当前EL，或者调到更低的EL。

注1：有关ARMv8-a异常处理的具体细节，会在其它文章中描述。

5. security model

ARMv8-a的security模型基本沿用了ARMv7 security extension的思路，主要目的保护一些安全应用的数据，例如支付等。它不同于privilege level等软件逻辑上的保护，而是一种物理上的区隔，即不同security状态下，可以访问的物理内存是不同的。

ARMv8-a架构有两个security state（参考上面图片），Security和non-Security。主要的功效是物理地址的区隔，以及一些system control寄存器的访问控制：

在Security状态下，处理器可以访问所有的Secure physical address space以及Non-secure physical address space；

在Non-security状态下，只能访问Non-secure physical address space，且不能访问Secure system control resources。

6. virtualization

硬件虚拟化包括指令集虚拟化、异常处理虚拟化、MMU虚拟化、IO虚拟化等多个议题，比较复杂，这里先不描述了。

7. 总结

本文简单介绍了ARMv8-a中的一些概念，后续文章将会重点关注异常处理模型、security模型、virtualization模型。

原创文章，转发请注明出处。蜗窝科技，www.wowotech.net。

标签：arm64armv8-aexception_level;security;virtualization

继续讨论

新讨论请用 GitHub 账号在下方发言——评论会保存在本仓库的 Discussions 里，与站点同寿； 再下方的「历史评论」是原站的只读存档。

评论（37 条，只读存档）

以下为原站的历史评论（只读存档）；继续讨论请用上方的评论区。

  • skd2278

    加油，辛苦了，期待更多关于ARMv8的文章。

    • wowo

      @skd2278：多谢~~我是在写其它文章时，需要用到ARMv8架构相关的知识的时候，才在这里总结一下，所以可能会比较慢。

  • passerby

    赞，最近公司用高通ARM64的。跟着学习

  • passerby

    有个小问题，如果在EL0时要进行系统调用或者发生了中断。我在汇编的异常向量表里看到有el0_sync el0_iqr和el1_sync和el1_irq，那SOC到底是升级进入EL1处理还是在EL0处理呢？

    • wowo

      @passerby：EL0是不能处理异常的，因此，高通的代码（el0_sync el0_iqr），要么是更改了ARM的架构，要么只是为了整齐，顺便加上的，不会使用。

      • passerby

        @wowo：那系统调用的时候，也要发生异常处理吧？我在el0_sync中看到了el0_svc会对系统调用处理，但是在el1_sync中却没有看到。ARM64对系统调用是怎么进行处理的呢，是我没有看到，还是有其他的办法？

        • wowo

          @passerby：抱歉，之前我没有看代码。这是Linux kernel起的名字有点迷惑人，不过仔细想想，也合理： 这里的el0_sync，指的是EL0下产生的sync中断，当然，这个中断是在EL1中被处理的。你看它操作的寄存器，都是EL1的。所以我们看到的，是已经升级后的。

          • passerby

            @wowo：哦，原来是这样。被名字误导了。。。

      • 风痕

        @wowo：你说得有问题吧，高等级可以使用低等级的寄存器，但是低等级不能使用高等级的寄存器。可以看看DEN0024A_v8_architecture_PG.pdf的表4.5

        • wowo

          @风痕：上面我和passerby的讨论，可能你理解错了。我没有这样的表述。

  • SleepDeXiang

    大神可以讲讲BL31路由这块

    • wowo

      @SleepDeXiang：大家不要再大婶大婶的叫了，其实我们也是在学习，只是把学习的心得分享出来了而已。后续有时间会涉及到EL3上的Security的内容的，但不会很快，毕竟时间有限。

      • schedule

        @wowo：很想静下来搞搞研究，平时天天除了交付就是交付，回家就想睡觉休息。真佩服你们这些还能坚持写博客的人

        • wowo

          @schedule：理解的，这也是没办法的事情啊，为了生活啊。我们写的也很慢，确实挤不出多少时间的。

    • Lusson

      @SleepDeXiang：BL31路由可以给你做个简单说明：1、处理FIQ ，在BL31初始化结束optee后，配置normalword psci_ctx的SCR.FW=1, secure world的optee_ctx的SCR.FW=0。使得在kernel运行时，有FIQ触发则立即进入monitor的异常向量表进行FIQ处理程序，通过注册的opteed_sel1_interrupt_handler，然后调用optee的fiq_entry，处理相应FIQ内容。如果当前正在optee执行内容，则直接进入thread_vect_table.thread_fiq_handler 向量中执行FIQ的处理。2、IRQ的处理，IRQ不需要设置通过monitor路由，当处于linux kernel时，直接由kernel处理，如果正在optee中执行，则执行thread_irq_handler向量，在该向量处理程序中将通过TEESMC_OPTEED_RETURN_CALL_DONE命令smc返回BL31，BL31再返回kerenl的optee_handle_rpc ->OPTEE_SMC_RETURN_RPC_IRQ 中，此时当cpsr的IRQ屏蔽位已经打开，则会被IRQ中断信号触发而进入kenerl的IRQ中断处理程序，处理完以后中断返回，再次由RPC接口返回optee。

  • shoujixiaodao

    牛逼。

  • daisy

    有没有V8（A53/A57)流水线技术的描述文档，找了infocenter，没找到，想看下pc值是当前执行值的原因 只看到这些，实在是太晦涩了 Simple sequential execution The behavior of an implementation that fetches, decodes and completely executes each instruction before proceeding to the next instruction. Such an implementation performs no speculative accesses to memory, including to instruction memory. The implementation does not pipeline any phase of execution. In practice, this is the theoretical execution model that the architecture is based on, and ARM does not expect this model to correspond to a realistic implementation of the architecture.

    • wowo

      @daisy：抱歉，没有接触过这些:(

    • 邵靖杰

      @daisy：看到这个为之一振，我也非常想找到这方面的资料，网络上现在都是关于老版本ARM8,9,11之类的流水线技术细节。今天在ARM官网上逛了很久仍然没有大收获。希望您如果找到相关资料可以通过邮件告知一声。感激不尽。

      • 邵靖杰

        @邵靖杰：邮箱地址2248831103@qq.com

  • wenky

    版主，A64指令集可不是指ARMv8指令集是64位的，"Each instruction in A64 is defined within a fixed length 32-bit instruction."。实际上指令集只是对指令的一种编码方式，32位的编码对目前来说已经够用了。64位主要是指寄存器的宽度是64位，另外内存寻址范围跟寄存器的宽度也没关系，取决于处理器内部的总线宽度，实际上ARMv8寻址也只用到了48位。Intel32位的处理器内部寻址总线也远远不止32位。阅读量越来越大、请及时修正~~

    • wowo

      @wenky：非常感谢wenky的建议，由于对ARM64的理解不是很深刻，有些表述不清或者错误的地方，还请多指正、讨论。 关于A64指令集的定义，确实不太好表述，因此本文只是如实引用了ARM白皮书（ARMv8_white_paper_v5.pdf）中的说法：“Does ARMv8 need to be considering a full 64-bit instruction set architecture with its larger virtual address space architecture or not?”，也即64-bit指令集。至于这里的64-bit到底指的是什么，由于不想在这个介绍性的文档中带入太多信息，就没有提。是的，您的说法是正确的，指令编码是32位，通用寄存器等，是64位。 关于内存寻址，您说的也很正确，和总线以及内存管理单元有关，和指令集无关，但这并不是A64关心的地方。对于物理内存，ARMv7+LPAE是可以解决4GB的限制，但虚拟内存怎么办？这才是A64关心的地方。 正因为有MMU的存在，内存寻址才可以和指令集剥离开来，CPU访问虚拟地址，MMU将之转换为物理地址（理论上可以是任何范围）。但虚拟地址的范围由什么决定的呢？可以参考下面的表述（希望后续能以单独的文章和大家讨论AArch64的内存模型，这里就不再细述了）： The A64 instruction set supports 64-bit addresses. The valid address range is determined by the following factors: • The size of the implemented virtual address space. • Memory Management Unit (MMU) configuration settings.

      • wenky

        @wowo：O(∩_∩)O我也是接触不久一知半解、多多指教~~在这儿收获很多、谢谢~~

  • 老蛮熊

    hi , 楼主，不错，很好， 另外：正因为有MMU的存在，内存寻址才可以和指令集剥离开来。 这句的表达容易误解，没有MMU，数据访问和指令访问也是分开的。编译链接的时候就是不同的有效地址。 有效地址：程序编译链接时候设定的地址。 虚拟地址：ＣＰＵ　内部把有效地址映射成的一种中间地址。 物理地址： MMU把有效地址转为虚拟地址后最后放到总线上的地址（理解为DDR的地址线）

    • wowo

      @老蛮熊：多谢指正，确实，这个表达欠妥当。谢谢~~

  • jserv 主页

    感謝一直以來熱心分享，我是台灣的一位大學教師，日前指導學生彙整 ARMv8-A 相關題材，請多多指教: http://wiki.csie.ncku.edu.tw/embedded/ARMv8

    • wowo

      @jserv：感謝分享，已經閱讀，寫的還是蠻細緻的。ARMv8的內容是非常多的，希望你們能多研究一下這方面的內容。謝謝。

    • 游客1

      @jserv：感谢您，我是本科生，最近在做ARMv8相关研究，您这个wiki帮了我大忙，做的真好。

  • buhui

    多么好的文章，期待蜗蜗一直写下去，技术本来是美好的，我们要享受它。

    • wowo

      @buhui：多谢鼓励！没错，享受技术，和享受一杯咖啡，从本质上是没区别的。

  • 夏伟

    后来的Cortex-A15（ARMv7架构）通过Large Physical Address Extensions (LPAE) 技术，可以支持高达40bits的物理地址空间。但受限于32-bit的指令集，虚拟地址空间依旧只有32bits（4G） ============================================================================ @wowo 您好，最近刚好在研究LPAE，有个问题向您请教一下。 LPAE能够扩大物理地址空间，但是在ARMv7架构（linux平台）中，虚拟地址空间只有4G，按照3:1的划分，内核空间只划分到了1G的虚拟地址空间。假如要在内核空间申请大片内存（>1G）,那内核虚拟地址空间肯定是不够用了。这样一来，扩大的物理地址空间如何能够得到有效合理利用？ 换句话说，在打开LPAE的情况下，如何扩大的物理地址空间进行充分利用呢？

    • wowo

      @夏伟：简单来说：每个进程的VA都是32bit，物理内存是40bit，不同进程的32bit可以映射到物理内存40bit的不同位置啊，所以肯定可以利用的。

      • 夏伟

        @wowo：感谢！您的回答令我茅塞顿开，是我自己把思维局限于内核态的1G虚拟地址空间了。

  • 霍宏鹏

    通过LINUX DTS搜索，结识了您的博客，发现网上的文章都是基于您的文章来描述。后来看了您的其他文章，您的文章每一篇都是高水平，高质量，像是在写作、创作，真的很用心。您向技术致敬，我们向您致敬。

    • wowo

      @霍宏鹏：多谢鼓励，大家的认同就是我们最大的动力啊:-)

  • lethe 主页

    工作已经快三年了，刚毕业做driver的时后经常会看大佬技术blog和留言讨论，说真的很佩服十年如一日对技术的热情研究和心得分享，非常喜欢蜗窝，希望可以做一个像wowo一样真在的追求实质的developer，特此激励自己。

  • Roy

    拜阅 Guest OS（Linux kernel、window等）位于EL1 是否大致逻辑如下： 若实现Hypervisor（EL2），则EL1可运行若干GuestOS，否则EL1运行OS。 只有在异常发生时（或者异常处理返回时），才能切换Exception level（...） SMC或HVC 是否可直接触发EL切换，或者这类超级调用是先触发异常，在切换EL？没有具体深入研究过。