Interrupt Masking Ineffectiveness in AArch64 Exception Routing
In ARM architectures, particularly in AArch64, the handling of interrupts across different Exception Levels (ELs) is a critical aspect of system design. A common issue arises when interrupts, despite being masked at a lower Exception Level (e.g., EL1), are still signaled and cause exceptions to be taken at a higher Exception Level (e.g., EL2). This behavior is often observed when developers attempt to route interrupts to EL2 for preliminary checks or handling before delegating them back to EL1. The core of the problem lies in the architectural design of ARM’s exception handling and interrupt routing mechanisms, which do not allow interrupts routed to a higher EL to be masked at a lower EL. This means that even if the interrupt mask bits (PSTATE.I/F) are set in SPSR_EL2, the interrupt will still be taken at EL2 if it is routed there via HCR_EL2.IMO/FMO.
The issue is further complicated when using GICv3/4, as the virtualization of interrupt controllers introduces additional layers of complexity. Specifically, when HCR_EL2.IMO/FMO is set, EL1 accesses to GIC registers are virtualized, meaning that EL1 interacts with the ICV (Virtual CPU Interface) rather than the ICC (Physical CPU Interface). This virtualization can lead to scenarios where EL1 attempts to acknowledge an interrupt but ends up interacting with the virtual interface, which may not be aware of the physical interrupt that was originally routed to EL2. This misalignment can cause the interrupt to remain pending, leading to repeated exceptions and unexpected behavior.
Architectural Constraints and GIC Virtualization Misalignment
The root cause of the interrupt masking issue stems from two primary architectural constraints in ARM’s AArch64 exception handling model. First, exceptions routed to a higher EL cannot be masked at a lower EL. This means that if an interrupt is routed to EL2 via HCR_EL2.IMO/FMO, it will be taken at EL2 regardless of the interrupt mask bits (PSTATE.I/F) set in SPSR_EL2. This behavior is by design, as higher ELs are intended to have full control over exception handling, including the ability to intercept and manage interrupts before they reach lower ELs.
Second, the use of GICv3/4 introduces additional complexity due to the virtualization of interrupt controllers. When HCR_EL2.IMO/FMO is set, EL1 accesses to GIC registers are redirected to the virtual interface (ICV) rather than the physical interface (ICC). This redirection means that EL1 is no longer directly interacting with the physical interrupt controller, which can lead to misalignment between the physical and virtual interrupt states. For example, if EL2 acknowledges a physical interrupt but does not properly register a corresponding virtual interrupt with the GIC, EL1 may attempt to acknowledge the interrupt but end up interacting with the virtual interface, which may not have the necessary information to properly handle the interrupt.
This misalignment can result in the interrupt remaining pending, causing repeated exceptions and preventing the system from making progress. Additionally, the virtualization of interrupt controllers can introduce subtle timing issues, particularly in systems where interrupts are frequently routed between EL2 and EL1. These timing issues can exacerbate the problem, making it difficult to diagnose and resolve.
Implementing Proper Interrupt Routing and Virtualization Handling
To address the issue of interrupt masking ineffectiveness and GIC virtualization misalignment, developers must adopt a structured approach to interrupt routing and handling. The following steps outline a recommended workflow for ensuring proper interrupt handling across EL2 and EL1:
Step 1: Configure HCR_EL2.IMO/FMO to Route Physical Interrupts to EL2
The first step is to configure HCR_EL2.IMO/FMO to route physical interrupts to EL2. This ensures that all physical interrupts are initially handled by EL2, allowing for preliminary checks and management before delegating them to EL1. This configuration is critical for systems where EL2 acts as a hypervisor or security monitor, as it provides a mechanism for intercepting and managing interrupts before they reach lower ELs.
Step 2: Acknowledge Physical Interrupts in EL2
Once an interrupt is routed to EL2, the hypervisor or security monitor must acknowledge the physical interrupt in the GIC. This acknowledgment ensures that the interrupt is properly registered with the GIC and prevents it from being repeatedly signaled. During this step, the hypervisor should also perform any necessary checks or management tasks, such as switching stage 2 page tables or updating system state.
Step 3: Register a Virtual Interrupt with the GIC
After acknowledging the physical interrupt, the hypervisor must register a corresponding virtual interrupt with the GIC. This virtual interrupt is linked to the acknowledged physical interrupt and ensures that EL1 can properly handle the interrupt when it is delegated. The registration process involves configuring the GIC’s virtual interface (ICV) to reflect the state of the physical interrupt, including its priority and pending status.
Step 4: ERET to EL1 and Handle the Virtual Interrupt
Once the virtual interrupt is registered, the hypervisor can perform an ERET to EL1, allowing the lower EL to handle the interrupt. At this point, EL1 will take the virtual interrupt exception and acknowledge the interrupt in the GIC’s virtual interface. The EL1 kernel can then perform any necessary handling, such as updating process state or scheduling tasks, before deactivating the virtual interrupt.
Step 5: Deactivate the Virtual and Physical Interrupts
After handling the interrupt, EL1 must deactivate the virtual interrupt in the GIC’s virtual interface. This deactivation also deactivates the linked physical interrupt, ensuring that the interrupt is fully resolved and does not remain pending. This step is critical for preventing repeated exceptions and ensuring system stability.
By following this structured approach, developers can ensure proper interrupt handling across EL2 and EL1, even in systems with complex virtualization requirements. Additionally, this approach helps to mitigate the architectural constraints and GIC virtualization misalignment issues that can lead to interrupt masking ineffectiveness.
Summary of Key Considerations and Best Practices
To summarize, the issue of interrupt masking ineffectiveness during EL2-to-EL1 transitions is a complex problem that requires careful consideration of ARM’s architectural constraints and GIC virtualization mechanisms. Developers must be aware of the following key considerations and best practices:
- Exception Routing and Masking: Exceptions routed to a higher EL cannot be masked at a lower EL. This means that interrupts routed to EL2 will always be taken at EL2, regardless of the interrupt mask bits set in SPSR_EL2.
- GIC Virtualization: When using GICv3/4, EL1 accesses to GIC registers are virtualized if HCR_EL2.IMO/FMO is set. This virtualization can lead to misalignment between physical and virtual interrupt states, causing interrupts to remain pending and triggering repeated exceptions.
- Structured Interrupt Handling: A structured approach to interrupt handling, including proper acknowledgment of physical interrupts, registration of virtual interrupts, and deactivation of interrupts, is essential for ensuring system stability and preventing repeated exceptions.
By adhering to these best practices and understanding the underlying architectural constraints, developers can effectively manage interrupts across EL2 and EL1, even in complex systems with virtualization requirements.
