[PATCH 00/38] arm64: Add support for FEAT_NMI

[Ashok Raj]

On Mon, Sep 14, 2026 at 11:20:24AM +0100, Vladimir Murzin wrote:

> FEAT_NMI provides an architected mechanism for supporting non-maskable
> interrupts (NMIs) and less-masked interrupts (LMIs).
> 
> Since we already support pseudo-NMIs via priority masking, introducing
> another flavour of NMI on top of the existing infrastructure could
> easily become messy, making the code harder to follow and reason
> about.
> 
> To avoid that, this series first makes room for the new NMI "tenant"
> by restructuring the existing exception masking logic (patches 01/38 -
> 15/38)


Hi all,

I am working on arm64 HEST/GHES Type-4 (NMI) support using FEAT_NMI
and GIC NMI support.

On arm64, the proposed ACPI semantics are that the Type-4 Vector names
one GSI corresponding to an NMI-capable GIC SPI. The NMI property belongs
to that SPI, while its target PE is normal mutable GIC routing state
(GICD_IROUTER<n>). This also permits a platform to describe multiple
GHESv2 Type-4 sources, each with a distinct NMI SPI.

The current Linux GHES implementation registers the interrupt with:

    request_nmi(irq, handler,
                IRQF_PERCPU | IRQF_NOBALANCING |
                IRQF_NO_THREAD | IRQF_NO_AUTOEN,
                ...);

request_nmi() requires IRQF_PERCPU, which marks the descriptor IRQD_PER_CPU.
Generic CPU-offline IRQ migration then skips it. This makes sense for a
true PPI, but this GHES interrupt is an SPI: if its target CPU is offlined,
GICD_IROUTER<n> may remain pointed at the outgoing PE and notification can
be lost, or possibly it might fail the cpu offline since an interrupt
can't be retargetted. 

The GICv3 affinity callback can retarget an NMI-configured SPI: it masks
the SPI, updates GICD_IROUTER<n>, unmasks it, and updates effective
affinity.

Would maintainers prefer that GHES explicitly retarget these NMI SPIs in a
CPU-hotplug callback while retaining the current request_nmi() contract,
or should genirq gain an explicit routable-NMI SPI registration model that
is not marked IRQD_PER_CPU, but remains excluded from automatic balancing?

In either model, the intended policy is that irqbalance must not move the
interrupt, but OSPM must be able to retarget the SPI before its target CPU
is removed.

Thanks,
Ashok