GICv3 Dynamic Interrupt Priority Change and Delivery Guarantees

GICv3 Interrupt Priority Change Challenges with Pending Interrupts

The ARM Generic Interrupt Controller (GIC) version 3 (GICv3) is a sophisticated interrupt management system designed to handle a wide range of interrupt scenarios in modern ARM-based systems. One of the more nuanced challenges when working with GICv3 is dynamically changing the priority of an interrupt that is already pending. The GICv3 specification explicitly states that when the priority of a pending interrupt is modified, the GIC may use either the old or the new priority value, and the change must take effect in finite time. This creates a significant challenge for developers who need to ensure that the new priority is applied immediately, especially in real-time or virtualized environments where timing and predictability are critical.

The core issue revolves around the behavior of the GICR_IPRIORITYRn registers, which control the priority of interrupts. When an interrupt is pending, writing to these registers does not guarantee that the new priority will be used immediately. Instead, the GIC may continue to use the old priority until the interrupt signal is deasserted and reasserted. This behavior is particularly problematic for level-triggered Private Peripheral Interrupts (PPIs), such as those generated by the generic timer or Performance Monitoring Unit (PMU), where the interrupt signal remains asserted until explicitly cleared.

In a virtualized environment, this issue becomes even more complex. During a Virtual Machine (VM) context switch, the hypervisor must load new interrupt priorities and ensure that any pending interrupts are delivered according to the new priorities. If the old priority prevents the interrupt from being delivered (e.g., due to the Priority Mask Register (PMR) settings), the hypervisor must ensure that the new priority takes effect immediately to maintain correct VM behavior. This requires careful handling of the GIC state, including potential "flickering" of the interrupt signal to force the GIC to recognize the new priority.

Memory Barriers, Interrupt Flickering, and GIC Sampling Rates

To address the challenge of ensuring that a new interrupt priority takes effect immediately, several factors must be considered. First, the timing of the priority change relative to the GIC’s sampling of the interrupt signal is critical. The GIC samples level-triggered interrupts at specific intervals, and if the priority change and interrupt deassertion/reassertion occur too quickly, the GIC may not detect the change. This raises the question of whether the GIC’s sampling rate must be accounted for when implementing a priority change sequence.

Second, the use of memory barriers is essential to ensure that the priority change and interrupt flickering are executed in the correct order. The ARM architecture provides several types of barriers, including Instruction Synchronization Barriers (ISB) and Data Synchronization Barriers (DSB). An ISB ensures that all subsequent instructions are fetched after the barrier, while a DSB ensures that all memory accesses before the barrier are completed before any subsequent memory accesses. In this context, a DSB is necessary to ensure that the write to the GICR_IPRIORITYRn register is completed before the interrupt is flickered. However, the GICv3 specification’s requirement that the priority change takes effect in "finite time" suggests that even a DSB may not guarantee immediate visibility of the change.

Finally, the sequence of operations must be carefully designed to avoid race conditions. For example, if the interrupt is flickered before the priority change is fully propagated through the GIC, the interrupt may be delivered with the old priority. This could lead to unpredictable behavior, especially in real-time systems where interrupt latency and priority are critical.

Implementing a Reliable Priority Change Sequence with GICv3

To implement a reliable sequence for changing the priority of a pending interrupt in GICv3, the following steps should be taken:

1. Disable the Interrupt: Begin by disabling the interrupt using the GICx_ICENABLERn register. This ensures that the interrupt is no longer signalable and prevents the GIC from delivering it while the priority is being changed. Disabling the interrupt also forces the GIC to recall any pending instances of the interrupt from CPU interfaces.

2. Poll for Completion: After disabling the interrupt, poll the GICx_CTLR.RWP (Register Write Pending) bit until it reads as 0. This bit indicates whether the GIC is still processing the disable operation. Waiting for RWP to clear ensures that the interrupt has been fully recalled and is no longer pending on any CPU interface.

3. Change the Priority: Once the interrupt is disabled and the RWP bit is clear, write the new priority value to the GICR_IPRIORITYRn register. This ensures that the new priority is applied before the interrupt is reenabled.

4. Reenable the Interrupt: Finally, reenable the interrupt using the GICx_ISENABLERn register. This makes the interrupt signalable again, and the GIC will use the new priority when delivering it.

This sequence guarantees that the priority change takes effect immediately and avoids race conditions. However, it does introduce some latency due to the need to disable and reenable the interrupt, as well as the polling of the RWP bit. In practice, this latency is typically on the order of microseconds, which is acceptable for most real-time and virtualized environments.

For scenarios where the interrupt cannot be disabled (e.g., due to system constraints), an alternative approach is to flicker the interrupt signal. This involves deasserting and reasserting the interrupt signal after changing the priority. While this approach avoids the need to disable the interrupt, it requires careful handling of memory barriers and GIC sampling rates to ensure that the priority change is recognized. A DSB should be used after writing the new priority to ensure that the change is visible to the GIC before the interrupt is flickered. Additionally, a delay may be necessary to account for the GIC’s sampling rate, although this is highly implementation-dependent.

In conclusion, dynamically changing the priority of a pending interrupt in GICv3 is a complex but solvable challenge. By carefully designing the sequence of operations and accounting for the GIC’s behavior, developers can ensure that priority changes take effect immediately and reliably. This is particularly important in real-time and virtualized environments, where interrupt handling must be both predictable and efficient.