1. 前言

ARMv8（當前只有A系列，即ARMv8-A）架構，是ARM公司為滿足新需求而重新設計的一個架構，是近20年來，ARM架構變動最大的一次。它引入的Execution State、Exception Level、Security State等新特性，已經和我們對舊的ARM架構的認知，有很大差距了。

因此，本文從ARMv8-A產生的背景開始，對它進行一個簡單的介紹，使大家從整體上，對ARMv8有一個簡單的了解。

2. 背景

有一點是可以確定的，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的解釋（只有偉大的公司才有偉大的理念?。?/p>

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模型。
編輯：hfy