ARMv8-a架构简介
作者:wowo 发布于:2015-7-7 22:31 分类:ARMv8A Arch
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有关的内容):
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。
标签: arm64 armv8-a exception_level;security;virtualization
评论:
2017-12-13 11:20
2017-10-10 21:31
============================================================================
@wowo 您好,最近刚好在研究LPAE,有个问题向您请教一下。
LPAE能够扩大物理地址空间,但是在ARMv7架构(linux平台)中,虚拟地址空间只有4G,按照3:1的划分,内核空间只划分到了1G的虚拟地址空间。假如要在内核空间申请大片内存(>1G),那内核虚拟地址空间肯定是不够用了。这样一来,扩大的物理地址空间如何能够得到有效合理利用? 换句话说,在打开LPAE的情况下,如何扩大的物理地址空间进行充分利用呢?
2015-09-15 15:45
2015-09-02 10:23
另外:正因为有MMU的存在,内存寻址才可以和指令集剥离开来。 这句的表达容易误解,没有MMU,数据访问和指令访问也是分开的。编译链接的时候就是不同的有效地址。
有效地址:程序编译链接时候设定的地址。
虚拟地址:CPU 内部把有效地址映射成的一种中间地址。
物理地址: MMU把有效地址转为虚拟地址后最后放到总线上的地址(理解为DDR的地址线)
2015-08-11 00:03
2015-08-11 09:15
关于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.
2015-07-27 16:03
只看到这些,实在是太晦涩了
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.
功能
最新评论
文章分类
随机文章
文章存档
- 2024年2月(1)
- 2023年5月(1)
- 2022年10月(1)
- 2022年8月(1)
- 2022年6月(1)
- 2022年5月(1)
- 2022年4月(2)
- 2022年2月(2)
- 2021年12月(1)
- 2021年11月(5)
- 2021年7月(1)
- 2021年6月(1)
- 2021年5月(3)
- 2020年3月(3)
- 2020年2月(2)
- 2020年1月(3)
- 2019年12月(3)
- 2019年5月(4)
- 2019年3月(1)
- 2019年1月(3)
- 2018年12月(2)
- 2018年11月(1)
- 2018年10月(2)
- 2018年8月(1)
- 2018年6月(1)
- 2018年5月(1)
- 2018年4月(7)
- 2018年2月(4)
- 2018年1月(5)
- 2017年12月(2)
- 2017年11月(2)
- 2017年10月(1)
- 2017年9月(5)
- 2017年8月(4)
- 2017年7月(4)
- 2017年6月(3)
- 2017年5月(3)
- 2017年4月(1)
- 2017年3月(8)
- 2017年2月(6)
- 2017年1月(5)
- 2016年12月(6)
- 2016年11月(11)
- 2016年10月(9)
- 2016年9月(6)
- 2016年8月(9)
- 2016年7月(5)
- 2016年6月(8)
- 2016年5月(8)
- 2016年4月(7)
- 2016年3月(5)
- 2016年2月(5)
- 2016年1月(6)
- 2015年12月(6)
- 2015年11月(9)
- 2015年10月(9)
- 2015年9月(4)
- 2015年8月(3)
- 2015年7月(7)
- 2015年6月(3)
- 2015年5月(6)
- 2015年4月(9)
- 2015年3月(9)
- 2015年2月(6)
- 2015年1月(6)
- 2014年12月(17)
- 2014年11月(8)
- 2014年10月(9)
- 2014年9月(7)
- 2014年8月(12)
- 2014年7月(6)
- 2014年6月(6)
- 2014年5月(9)
- 2014年4月(9)
- 2014年3月(7)
- 2014年2月(3)
- 2014年1月(4)
2022-12-08 15:54
Guest OS(Linux kernel、window等)位于EL1
是否大致逻辑如下:
若实现Hypervisor(EL2),则EL1可运行若干GuestOS,否则EL1运行OS。
只有在异常发生时(或者异常处理返回时),才能切换Exception level(...)
SMC或HVC 是否可直接触发EL切换,或者这类超级调用是先触发异常,在切换EL?没有具体深入研究过。