2021年09月28日 | Arm64中的异常处理

闲话

最近优化环境中出现了多次不同种类的异常，其他文章中也有提及，为此专门去研究了一下Arm64的异常处理机制和代码，之前主要的开发和应用环境为X86，ARM接触很少，也没有机会去研究和学习，总以为不会有用上的一天，谁知，现在。。。 可能是机会来了，让自己多长些见识，学习之后发现又有另一番收获。

Exception in ARM64

## Exception类型

ARM64中包含如下几种类型的异常：

中断(Interrupts)，就是我们平常理解的中断，主要由外设触发，是典型的异步异常。 ARM64中主要包括两种类型的中断：IRQ(普通中断)和FIQ(高优先级中断，处理更快)。 Linux内核中好像没有使用FIQ，还没有仔细看代码，具体不详述了。

Aborts。 可能是同步或异步异常。包括指令异常(取指令时产生)、数据异常(读写内存数据时产生)，可以由MMU产生(比如典型的缺页异常)，也可以由外部存储系统产生(通常是硬件问题)。

Reset。复位被视为一种特殊的异常。

Exception generating instructions。由异常触发指令触发的异常，比如Supervisor Call (SVC)、Hypervisor Call (HVC)、Secure monitor Call (SMC)

异常级别(EL)

ARM中，异常由级别之分，具体如下图所示，只要关注：

普通的用户程序处于EL0，级别最低

内核处于EL1，HyperV处于EL2，EL1-3属于特权级别。

Arm64中的异常级别

异常处理

Arm中的异常处理过程与X86比较相似，同样包括硬件自动完成部分和软件部分，同样需要设置中断向量，保存上下文，不同的异常类型的处理方式可能有细微差别。 这里不详述了。

需要关注：用户态(EL0)不能处理异常，当异常发生在用户态时，异常级别(EL)会发生切换，默认切换到EL1(内核态)。

中断向量表

Arm64架构中的中断向量表有点特别(相对于X86来说~)，包含16个entry，这16个entry分为4组，每组包含4个entry，每组中的4个entry分别对应4种类型的异常：

SError

FIQ

IRQ

Synchronous Aborts

4个组的分类根据发生异常时是否发生异常级别切换、和使用的堆栈指针来区别。分别对应于如下4组：

异常发生在当前级别且使用SP_EL0(EL0级别对应的堆栈指针)，即发生异常时不发生异常级别切换，可以简单理解为异常发生在内核态(EL1)，且使用EL0级别对应的SP。 这种情况在Linux内核中未进行实质处理，直接进入bad_mode()流程。

异常发生在当前级别且使用SP_ELx(ELx级别对应的堆栈指针，x可能为1、2、3)，即发生异常时不发生异常级别切换，可以简单理解为异常发生在内核态(EL1)，且使用EL1级别对应的SP。 这是比较常见的场景。

异常发生在更低级别且在异常处理时使用AArch64模式。 可以简单理解为异常发生在用户态，且进入内核处理异常时，使用的是AArch64执行模式(非AArch32模式)。 这也是比较常见的场景。

异常发生在更低级别且在异常处理时使用AArch32模式。 可以简单理解为异常发生在用户态，且进入内核处理异常时，使用的是AArch32执行模式(非AArch64模式)。 这中场景基本未做处理。

代码分析

## 中断向量表

Linux内核中，中断向量表实现在entry.S文件中，代码如下：

/*

* Exception vectors.

*/

.align 11 //EL1的异常向量表保存在VBAR_EL1寄存器中（Vector Base Address Register (EL1)），该寄存器的低11bit是reserve的，11～63表示了Vector Base Address，因此这里的异常向量表是2K对齐的。

/*el1代表内核态，el0代表用户态*/

ENTRY(vectors)

ventry el1_sync_invalid // Synchronous EL1t 

ventry el1_irq_invalid // IRQ EL1t

ventry el1_fiq_invalid // FIQ EL1t

/*内核态System Error ，使用SP_EL0(用户态栈)*/

ventry el1_error_invalid // Error EL1t

ventry el1_sync // Synchronous EL1h

ventry el1_irq // IRQ EL1h

ventry el1_fiq_invalid // FIQ EL1h

/*内核态System Error ，使用SP_EL1(内核态栈)*/

ventry el1_error_invalid // Error EL1h

ventry el0_sync // Synchronous 64-bit EL0

ventry el0_irq // IRQ 64-bit EL0

ventry el0_fiq_invalid // FIQ 64-bit EL0

/*用户态System Error ，使用SP_EL1(内核态栈)*/

ventry el0_error_invalid // Error 64-bit EL0

#ifdef CONFIG_COMPAT

ventry el0_sync_compat // Synchronous 32-bit EL0

ventry el0_irq_compat // IRQ 32-bit EL0

ventry el0_fiq_invalid_compat // FIQ 32-bit EL0

ventry el0_error_invalid_compat // Error 32-bit EL0

#else

ventry el0_sync_invalid // Synchronous 32-bit EL0

ventry el0_irq_invalid // IRQ 32-bit EL0

ventry el0_fiq_invalid // FIQ 32-bit EL0

ventry el0_error_invalid // Error 32-bit EL0

#endif

END(vectors)

可以明显看出分组和分类的情况。

invalid类处理

带invalid后缀的向量都是Linux做未做进一步处理的向量，默认都会进入bad_mode()流程，说明这类异常Linux内核无法处理，只能上报给用户进程(用户态，sigkill或sigbus信号)或die(内核态)

带invalid后缀的向量最终都调用了inv_entry，inv_entry实现如下：

/*

 * Invalid mode handlers

 */

  /*Invalid类异常都在这里处理，统一调用bad_mode函数*/

.macro inv_entry, el, reason, regsize = 64

kernel_entry el, regsize

/*传入bad_mode的三个参数*/

mov x0, sp

/*reason由上一级传入*/

mov x1, #reason

/*esr_el1是EL1(内核态)级的ESR(异常状态寄存器)，用于记录异常的详细信息，具体内容解析需要参考硬件手册*/

mrs x2, esr_el1

/*调用bad_mode函数*/

b bad_mode

.endm

调用bad_mode，是C函数，通知用户态进程或者panic。

/*

 * bad_mode handles the impossible case in the exception vector.

 */

asmlinkage void bad_mode(struct pt_regs *regs, int reason, unsigned int esr)

{

siginfo_t info;

/*获取异常时的PC指针*/

void __user *pc = (void __user *)instruction_pointer(regs);

console_verbose();

/*打印异常信息，messages中可以看到。*/

pr_crit("Bad mode in %s handler detected, code 0x%08x -- %sn",

handler[reason], esr, esr_get_class_string(esr));

/*打印寄存器内容*/

__show_regs(regs);

/*如果发生在用户态，需要向其发送信号，这种情况下，发送SIGILL信号，所以就不会有core文件产生了*/

info.si_signo = SIGILL;

info.si_errno = 0;

info.si_code  = ILL_ILLOPC;

info.si_addr  = pc;

/*给用户态进程发生信号，或者die然后panic*/

arm64_notify_die("Oops - bad mode", regs, &info, 0);

}

arm64_notify_die：

void arm64_notify_die(const char *str, struct pt_regs *regs,

      struct siginfo *info, int err)

{

/*如果发生异常的上下文处于用户态，则给相应的用户态进程发送信号*/

if (user_mode(regs)) {

current->thread.fault_address = 0;

current->thread.fault_code = err;

force_sig_info(info->si_signo, info, current);

} else {

/*如果是内核态，则直接die，最终会panic*/

die(str, regs, err);

}

}

IRQ中断处理

场景的场景中(不考虑EL2和EL3)，IRQ处理分两种情况：用户态发生的中断和内核态发生的中断，相应的中断处理接口分别为：

el0_sync

el1_sync

相应代码如下：

el1_sync：

.align 6

el1_irq:

/*保存中断上下文*/

kernel_entry 1

enable_dbg

#ifdef CONFIG_TRACE_IRQFLAGS

bl trace_hardirqs_off

#endif

/*调用中断处理默认函数*/

irq_handler

/*如果支持抢占，处理稍复杂*/

#ifdef CONFIG_PREEMPT

get_thread_info tsk

ldr w24, [tsk, #TI_PREEMPT] // get preempt count

cbnz w24, 1f // preempt count != 0

ldr x0, [tsk, #TI_FLAGS] // get flags

tbz x0, #TIF_NEED_RESCHED, 1f // needs rescheduling?

bl el1_preempt

1:

#endif

#ifdef CONFIG_TRACE_IRQFLAGS

bl trace_hardirqs_on

#endif

/*恢复上下文*/

kernel_exit 1

ENDPROC(el1_irq)

代码非常简单，主要就是调用了irq_handler()函数，不做深入解析了，有兴趣可以自己再看看代码。

el0_sync处理类似，主要区别在于：其涉及用户态和内核态的上下文切换和恢复。

.align 6

el0_irq:

kernel_entry 0

el0_irq_naked:

enable_dbg

#ifdef CONFIG_TRACE_IRQFLAGS

bl trace_hardirqs_off

#endif

/*退出用户上下文*/

ct_user_exit

irq_handler

#ifdef CONFIG_TRACE_IRQFLAGS

bl trace_hardirqs_on

#endif

/*返回用户态*/

b ret_to_user

ENDPROC(el0_irq)