ARMv8 异常处理简介
内核稳定性问题复杂多样，最常见的莫过于“kernel panic”，意为“内核恐慌，不知所措”。这种情况下系统自然无法正常运转，只能自我结束生命，留下死亡信息。诸如：
“Unable to handle kernel XXX at virtual address XXX”
“undefined instruction XXX”
“Bad mode in Error handler detected on CPUX, code 0xbe000011 -- SError”
......
这些死亡信息是系统在什么状态下产生？如何产生？以及如何处理？本文主要从这三个方面介绍ARMv8架构下CPU的异常处理流程。
一、ARMv8异常简介
1.异常级别
不同于Armv7架构采用CPU模式切换的方式进行异常处理，Armv8架构定义了一组全新的异常级别进行异常处理，即EL0至EL3，有如下特性：
如果ELn为异常级别，则n的值增加表示软件执行特权增加。
EL0处的执行称为无特权执行，不能处理异常。
EL2提供对虚拟化的支持。
EL3提供了在两个安全状态（安全状态和非安全状态）之间切换的支持。
一个实现可以不包括所有的异常级别，但都必须包括EL0和EL1。EL2和EL3是可选的。
如下是典型的异常级别使用模型:
2. 同步异常和异步异常
如果满足以下所有条件，则将异常描述为同步的：
由于直接执行某个指令而产生异常。
异常处理程序的返回地址可以表明导致该异常的指令。
异常是精确的。
如果满足以下任一条件，则将异常描述为异步的：
不是因为直接执行某条指令而产生异常。
异常处理程序的返回地址不可以表明导致该异常的指令。
异常是不精确的。
3. 主要寄存器
（1）通用寄存器R0-R30
在基本指令集处理指令时，将使用通用寄存器组。它包括31个通用寄存器R0-R30。这些寄存器可以作为31个64位寄存器X0-X30或31个32位寄存器W0-W30进行访问。
（2）堆栈指针寄存器SP
在AArch64状态下，除了通用寄存器外，还为以下每个异常级别实现了专用的堆栈指针寄存器，
堆栈指针寄存器为：
SP_EL0和SP_EL1。
如果实现包括EL2，则为SP_EL2。
如果实现包括EL3，则为SP_EL3。
堆栈指针寄存器选择：
在EL0上执行时，处理器使用EL0堆栈指针SP_EL0。在其他任何异常级别执行时，可以将处理器配置为使用SP_EL0或配置为对应该异常级别的堆栈指针SP_ELx。默认情况下，采用目标异常级别的堆栈指针SP_ELx。例如，EL1的异常选择SP_EL1，软件可以在目标异常级别执行的时候通过更新PSTATE.SP来指向SP_EL0的堆栈指针。
可以通过异常级别的堆栈指针后缀表明所选的堆栈指针：
t表明使用SP_EL0堆栈指针。
h表明使用SP_ELx堆栈指针。
t和h后缀基于线程(thread)和处理程序(handler)的首字母。
（3）保存的程序状态寄存器SPSR
保存的程序状态寄存器SPSR（Saved Program Status Registers）用于在发生异常时保存处理器状态。在AArch64状态下，每个异常级别都有一个SPSR：
SPSR_EL1，发生在EL1的异常。
如果实现了EL2，则为SPSR_EL2，发生在EL2的异常。
如果实现了EL3，则为SPSR_EL3，发生在EL3的异常。
注：EL0不能处理异常。
当处理器发生异常时，会将处理器状态从SPSTATE中的PSTATE(Process state)保存到对应异常级别的SPSR。例如，如果异常发生在EL1，则将处理器状态保存在SPSR_EL1中。
保存处理器状态意味着异常处理程序可以：
从异常返回时，将处理器状态恢复到SPSR中存储的异常级别的状态。例如，异常处理程序从EL1返回时，处理器状态恢复到存储在SPSR_EL1中的状态。
检查发生异常时PSTATE的值，确定引起异常指令的当前执行状态和异常级别,例如，当前执行状态是AArch64还是AArch32等。
（4）异常链接寄存器（ELR）
异常链接寄存器ELR(Exception Link Registers)包含异常返回地址。当处理器发生异常时，返回地址将保存在异常级别对应的ELR中。例如，当处理器将异常处理交给EL1处理时，会将异常返回地址保存在ELR_EL1中。在异常返回时，PC恢复到存储在ELR中的地址。例如，从EL1返回时，PC将恢复到ELR_EL1中存储的地址。
AArch64状态为每个异常级别都提供了ELR寄存器：
ELR_EL1，用于EL1的异常。
如果实现了EL2，ELR_EL2用于EL2的异常。
如果实现了EL3，ELR_EL3用于EL3的异常。
（5）ESR(Exception Syndrome Register)
异常综合表征寄存器ESR_ELn包含的异常信息用以异常处理程序确定异常原因。仅针对同步异常和SError进行更新。因为IRQ或FIQ中断处理程序从通用中断控制器（GIC）寄存器的信息获取状态。
ESR_ELn的BIT[31:26]指示处理程序执行对应的异常，比如：
EC == 0b100010，PC alignment fault exception.
EC == 0b100101，Data Abort taken without a change in Exception level.
EC == 0b101111，SError interrupt.
位[25]表示被捕获指令的长度（0为16位指令，1为32位指令）
位[24：0]构成ISS域(Instruction Specific Syndrome)，根据EC域指定的不同异常类型，ISS有不用的解释。有：
ISS encoding for an exception from an Instruction Abort
ISS encoding for an exception from a Data Abort
ISS encoding for an SError interrupt
ISS encoding for an exception from a WFI or WFE instruction.
等等。
以 Data Abort为例，ISS解读如下：
BIT[5:0] DFSC(Data Fault Status Code)解释了data abort发生的状态信息：
*其他bit位解释可以参考ARM v8手册
4.异常入口
每个异常都有特定的异常级别。异常所对应的异常级别是由软件编程决定，或者由异常自身性质决定的。在任何情况下，异常执行时都不会移至较低的异常级别。异常入口的基本执行内容是：
处理器状态保存到目标异常级别的SPSR_ELx中。
返回地址保存到目标异常级别的ELR_ELx中。
如果异常是同步异常或SError中断，异常的表征信息将保存在目标异常级别的ESR_ELx中。
如果是指令止异常(Instruction Abort exception)，数据中止异常(Data Abort exception,)，PC对齐错误异常(PC alignment fault exception),故障的虚拟地址将保存在FAR_ELx中。
堆栈指针保存到目标异常级别的专用堆栈指针寄存器SP_ELx。
执行移至目标异常级别，并从异常向量定义的地址开始执行。
二、异常处理流程
1.异常向量表
当发生异常时，处理器必须执行与之对应的处理程序。处理程序在内存中的存储位置称为异常向量。在ARM体系结构中，异常向量存储在一个表中，该表称为异常向量表。每个异常级别都有其自己的向量表，即EL3，EL2和EL1都有一个，该表包含要执行的指令。
每个表占128个字节，可以保存32条指令（arm64的指令长度也是4字节），以linux kernel-4.19/arch/arm64/kernel/entry.S为例，异常向量表的入口如下图,一共有4组16个表：
用另外一张表可以更好理解这个异常向量表的入口：
比如当前代码运行在内核空间，发生了data abort，异常向量表的入口地址就是0x200。
2.kernel_ventry
异常发生后，处理器从对应的异常向量表入口地址开始执行，第一条指令是kernel_ventry。kernel_ventry是一个宏定义，先检查栈空间是否有溢出，然后跳转到指定的异常处理标签。
以下以EL1发生data abort异常为例介绍异常处理流程。
EL1发生data abort异常后进入对应的异常向量表入口，先检查栈是否有溢出，然后跳转至：el1_sync(data abort属于同步异常)。
3.elx_sync
（1）保存现场
el1_sync第一条指令执行kernel_entry 1。kernel_entry也是一个宏定义，首先将CPU寄存器保存到栈空间，因为这些寄存器接下来会被覆盖使用。为了保证kernel_exit时能恢复准确的现场，这里有必要对第一现场先做保存。
其次设置栈帧大小S_FRAM_SIZE，S_FRAM_SIZE根据pt_regs结构体大小而设定。
pt_regs结构体：
另外就是读取elr_el1和spsr_el1等寄存器值。总之，kernel_entry主要将CPU寄存器按照pt_regs结构体的定义将异常第一现场保存到栈上。
（2）判断异常类型
kernel_entry保存完第一现场之后，接下来读取esr_el1寄存器的值，并判断异常的具体类型。如2.3.5章节所描述的ESR寄存器定义，ESR包含的异常信息主要用于异常处理程序确定异常原因，其中ESR_ELn的BIT[31:26] EC域指示处理程序执行的对应异常类型。
发生DataAbort时，EC = 0b100101，即ESR_ELx_EC_DABT_CUR=0x25，el1_syn将跳转至el1_da。
ESR_ELx_EC_DABT_CUR定义在/kernel/msm-4.19/arch/arm64/include/asm/esr.h。
除此之外，还有其他的同步异常类型，比如:
（3）跳转至异常类型标签
通过esr_el1寄存器值确定同步异常的具体类型后，跳转至对应的异常处理标签el1_da。el1_da第一条指令，mrs x3,far_el1，将far_el1保存到x3。在2.4异常入口章节介绍过如果发生数据中止异常(DataAbort exception)，故障的虚拟地址将保存在FAR_ELx中。这里就是首先将data abort异常发生的虚拟地址第一时间取出，保持在x3中。
el1_da 跳转到异常处理程序do_mem_abort之前，为其设置好了三个入参：
x0:产生DataAbort的故障虚拟地址。
x1:esr_el1,异常综合表征寄存器值，在el1_sync第二条指令已经保存。
x2:stack frame 地址，即pt_regs结构体的首地址，在kernel_entry已对其填充。
x0~x2分别对应do_mem_abort函数的三个参数：addr,esr,*regs。
（4）跳转至异常处理程序
do_mem_abort 函数位于/kernel/msm-4.19/arch/arm64/mm/fault.c
do_mem_abort首先根据esr寄存器获取data abort fault_info。在2.3.5章节介绍了ESR寄存器BIT[24:0]的ISS域，它记录了data abort的具体类型。这里将用到ISS域，也就是fault_info中的name变量。我们通常看到的“do_page_fault”、“do_translation_fault”等data abort下细分的调用栈就是由这里的ISS域区分而来。
fault_info结构体：
Fault_info[]数组：
fault_info 数组中对应的处理函数对当前的异常进一步处理，如果发现当前的data abort确实是属于非法，无法处理的，比如paging request 非法地址，就会抛出异常信息，并走到panic流程。
最后，调用arm64_notify_die,如果是用户空间发生data abort，输出异常信息和发送signal给当前进程。如果是异常发生在内核空间，走die流程。
die函数最终可能会调用到panic。但die函数也不是一定会走到panic，它先是走oops流程告警系统现在的异常，如果异常发生在中断上下文，走panic。或者如果设定了CONFIG_PANIC_ON_OOPS_VALUE=y,无论是否在中断上下文均走panic。
如果此次异常并没有走到panic流程，那么系统还是要继续运行，抛出oops警告后系统如何恢复异常发生前的环境？回到el1_da处理指令，do_mem_abort执行完如果不需要panic，跳转到kernel_exit进行异常退出处理。
4.kernel_exit
kernel_exit恢复现场。主要恢复kernel_entry保存在栈上的处理器相关寄存器等。至此发生在el1级别的data baort异常处理流程分析结束。
参考资料
[1]《DDI0487F_a_armv8_arm.pdf》
[2]《DEN0024A_v8_architecture_PG.pdf》