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

[Marc Zyngier]

On Sat, 24 Oct 2026 05:20:16 +0100,
Ashok Raj <ashok.raj at oss.qualcomm.com> wrote:
> 
> 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.

I've already said all I had to say about encoding the notion of
priority in FW tables.

> 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. 

Obviously, the PERCPU flag says exactly that. So if anything needs
fixing, it is the GHES driver.

> 
> 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?

The question really is: why does the GHES interrupt need to be
strictly affine to one given CPU?

> In either model, the intended policy is that irqbalance must not move the
> interrupt,

NOBALANCING achieves this, by preventing userspace from changing the
affinity.

> but OSPM must be able to retarget the SPI before its target CPU is
> removed.

Whatever OSPM is...

The real question is *WHY* do you need this. What breaks if you let
these interrupts be migrated at will?

	M.

-- 
Without deviation from the norm, progress is not possible.