Click the blue 'Arm Selection' at the top left and select 'Mark as Favorite'1. Concepts of Exceptions and Interrupts
AArch64 exception and interrupt handling
In the AArch64 architecture, exceptions and interrupts are one of the key mechanisms to ensure the normal operation of the system. An exception refers to a situation where the system requires privileged software (exception handler) to perform certain operations to handle an unexpected situation. Although in ARM terminology, interrupts are sometimes used synonymously with exceptions, in practice, they are a special case of asynchronous exceptions.
Exceptions are triggered by events that interrupt or modify the normal execution order of instructions, rather than being caused directly by the program. In contrast, an interrupt is a special type of exception that is typically triggered by external hardware signals, such as pressing a button or other external events.
Exceptions in the AArch64 architecture are categorized into two types: synchronous and asynchronous. Synchronous exceptions can be caused by various reasons, but they are handled in a similar manner. Asynchronous exceptions are further divided into three types of interrupts: IRQ (Interrupt Request), FIQ (Fast Interrupt Request), and SError (System Error), each with its specific handling method.
2. Methods of Generating Exceptions:
(1) Abort:
Instruction fetch failures result in instruction aborts, while data access failures trigger data aborts. These aborts can be caused by external storage systems providing erroneous responses during memory access (which may indicate that the specified address does not match the actual memory in the system). Additionally, the core’s Memory Management Unit (MMU) can also trigger aborts.
In the AArch64 architecture, synchronous aborts lead to synchronous exceptions. Asynchronous aborts trigger SError interrupt exceptions.
(2) Reset
Reset is a special case because it always has its own vector pointing to the highest priority implementation exception level. The address of this vector can be read from the Reset Vector Base Address Register, referred to as RVBAR_ELn, where n is the number of the highest implemented exception level.
All cores are equipped with a reset input, which generates a reset exception after being reset. This exception has the highest priority and cannot be masked by other exceptions. The reset exception is used to execute kernel initialization code after the system is powered on.
(3) Synchronous Exceptions
• The Supervisor Call (SVC) instruction enables User mode programs to request an OS service. • The Hypervisor Call (HVC) instruction enables the guest OS to request hypervisor services. • The Secure Monitor Call (SMC) instruction enables the Normal
(4) Asynchronous Exceptions (Interrupts)
There are three types of interrupts: IRQ, FIQ, and SError. Compared to SError, IRQ and FIQ are generally used for external asynchronous data aborts. Therefore, the term ‘interrupt’ usually refers only to IRQ and FIQ.
3. Handling of Synchronous and Asynchronous Exceptions
(1) Handling a Synchronous Exception
Exception Syndrome Register (ESR_ELn) Fault Address Register (FAR_ELn) The Exception Link Register (ELR_ELn)
The Exception Syndrome Register (ESR_ELn) and Fault Address Register (FAR_ELn) provide the ability to inform the exception handler about the reasons for synchronous exceptions.
The ESR_ELn register provides detailed information about the exception cause, while the FAR_ELn register holds the fault virtual addresses for all synchronous instruction and data aborts as well as alignment errors.
For systems that implement EL2 (Hypervisor) or EL3 (Secure Kernel), synchronous exceptions are typically taken at the current or higher exception levels. Asynchronous exceptions, if present, will be routed to higher exception levels for handling by the Hypervisor or Secure Kernel.
The SCR_EL3 register specifies which exceptions are routed to EL3, similarly, the HCR_EL2 specifies which exceptions are routed to EL2. Additionally, there are some independent bits used to control the routing of IRQ, FIQ, and SError independently.
(2) ESR_ELn – Exception Syndrome Register
Contains information that allows the exception handler to determine the cause of the exception. It is updated only for synchronous exceptions and SError. It is not updated for IRQ or FIQ since these interrupt handlers typically obtain status from the General Interrupt Controller (GIC) registers.
(3) Unallocated Instructions
Unallocated instructions cause a Synchronous Abort in AArch64. The reasons for this exception include: • An instruction opcode that is not allocated. • An instruction that requires a higher level of privilege than the current exception level. // For example, operating on the SCR_EL3 register while in EL1 • An instruction that has been disabled. • Any instruction when the PSTATE.IL field is set.
(4) System Calls
4. Exception Handling
The ARMv8-A architecture has four exception levels: EL0, EL1, EL2, and EL3. The processor can only move between exception levels by taking an exception or returning from an exception.
It is important to note:
-
When the processor moves from a higher to a lower exception level, the execution state can stay the same, or it can switch from AArch64 to AArch32.
-
When moving from a lower to a higher exception level, the execution state can stay the same or switch from AArch32 to AArch64. This means that if the higher level is AArch32, then the lower level must also be AArch32. If the higher level is AArch64, then the lower level can be either AArch32 or AArch64.
When an exception occurs, the processor automatically performs the following actions:
-
The SPSR_ELn is updated (where n is the exception level where the exception is taken), to store the PSTATE information required to return correctly at the end of the exception.
-
PSTATE is updated to reflect the new processor status (which can mean that the exception level is raised, or it can stay the same).
-
The address to return to at the end of the exception is stored in ELR_ELn. The _ELn suffix on register names indicates that there are multiple copies of these registers existing at different exception levels. This means, for example, that SPSR_EL1 is a different physical register than SPSR_EL2.
During exception handling, we will call the next level function to perform tasks, as illustrated in the following diagram:
After the exception handling is complete, the processor returns to a lower level using the ERET instruction.
4. Exception Vector Table
Each exception level has its own set of vector tables, with the base addresses written in the VBAR_EL3, VBAR_EL2, and VBAR_EL1 system registers. Each entry in the vector table is 16 instructions long (0x80 bytes) (in ARMv7-A and AArch32, each entry is only 4 bytes). This means that in AArch64, the top-level handler can execute directly in the vector instead of jumping to another address.
Each table executed by VBAR_ELn defines 16 entries, and which entry is taken is determined by the following factors: • The type of exception (SError, FIQ, IRQ, or Synchronous) • If the exception is taken at the same exception level, the stack pointer to be used (SP0 or SPn). • If the exception is taken at a lower exception level, the execution state of the next lower level (AArch64 or AArch32).
A classic vector table is shown below:
For a very simple example: kernel code executing in EL1, when an IRQ comes in, this interrupt is not configured to the hypervisor and secure environment, so its handling is completed only in the kernel, with the program jumping to VBAR_EL1+0x280, using sp_el1 (setting SPSel to sp_el1).
5. Exception Return
During exception handling, software needs to explicitly instruct the processor when to end exception handling and return to the normal program execution flow. This process is accomplished using the ERET instruction. The execution of the ERET instruction restores the processor state prior to the exception (stored in the SPSR_ELn register) and sets the program counter PC to the exception return address stored in the ELR_ELn register, allowing the program to return to the execution position prior to the exception.
In the A64 instruction set, the X30 register (used with the RET instruction) is used to return from subroutines.
The ELR_ELn register is used to save the return address after exception handling is complete. When an exception occurs, the processor automatically writes the current PC value into the ELR_ELn register as part of the exception entry. During the execution of the ERET instruction, the value in ELR_ELn is loaded into the PC register, allowing the program to correctly return from the exception handling.
In addition to the SPSR and ELR registers, each exception level has its own dedicated stack pointer registers: SP_EL0, SP_EL1, SP_EL2, and SP_EL3. These registers are used to point to the dedicated stack for each level. The stack is used to save the register values that are corrupted in the exception handler, so they can be restored to their original state before returning.
In the handler code, different stack usage can be achieved by switching the stack pointer registers (from SP_ELn to SP_EL0). For example, SP_EL1 may point to a memory block used for a smaller stack, while SP_EL0 may point to a larger kernel task stack. However, it should be noted that for the stack pointed to by SP_EL0, overflow cannot be guaranteed to not occur, and this switching process is controlled by writing to the SPSel register.
6. PSTATE
The current processor state is stored in PSTATE, and when an exception occurs, the value of PSTATE is automatically saved in SPSR. In AArch64, there are three SPSR registers: SPSR_EL3, SPSR_EL2, and SPSR_EL1. For example, if an exception targeting EL1 occurs, the current processor state will be automatically saved in SPSR_EL1;
7. Interrupt Handling Process
[Store Address]
[Customer Service Consultation]
