Skip to content
  • Will Deacon's avatar
    irqchip/gic: Ensure we have an ISB between ack and ->handle_irq · 39a06b67
    Will Deacon authored
    
    
    Devices that expose their interrupt status registers via system
    registers (e.g. Statistical profiling, CPU PMU, DynamIQ PMU, arch timer,
    vgic (although unused by Linux), ...) rely on a context synchronising
    operation on the CPU to ensure that the updated status register is
    visible to the CPU when handling the interrupt. This usually happens as
    a result of taking the IRQ exception in the first place, but there are
    two race scenarios where this isn't the case.
    
    For example, let's say we have two peripherals (X and Y), where Y uses a
    system register for its interrupt status.
    
    Case 1:
    1. CPU takes an IRQ exception as a result of X raising an interrupt
    2. Y then raises its interrupt line, but the update to its system
       register is not yet visible to the CPU
    3. The GIC decides to expose Y's interrupt number first in the Ack
       register
    4. The CPU runs the IRQ handler for Y, but the status register is stale
    
    Case 2:
    1. CPU takes an IRQ exception as a result of X raising an interrupt
    2. CPU reads the interrupt number for X from the Ack register and runs
       its IRQ handler
    3. Y raises its interrupt line and the Ack register is updated, but
       again, the update to its system register is not yet visible to the
       CPU.
    4. Since the GIC drivers poll the Ack register, we read Y's interrupt
       number and run its handler without a context synchronisation
       operation, therefore seeing the stale register value.
    
    In either case, we run the risk of missing an IRQ. This patch solves the
    problem by ensuring that we execute an ISB in the GIC drivers prior
    to invoking the interrupt handler. This is already the case for GICv3
    and EOIMode 1 (the usual case for the host).
    
    Cc: Marc Zyngier <marc.zyngier@arm.com>
    Signed-off-by: default avatarWill Deacon <will.deacon@arm.com>
    Signed-off-by: default avatarMarc Zyngier <marc.zyngier@arm.com>
    39a06b67