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

[Ashok Raj]

On Tue, Oct 27, 2026 at 11:56:41AM +0000, Marc Zyngier wrote:
> > 
> > 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.

Hi Marc,

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

Thank you for the feedback. 

I'll try to explain without tripping over myself :-)

The intent of that proposal was not to prescribe an OS interrupt
priority. The narrower goal was to give platform owners a way to
identify a small set of critical platform events for which we need
prompt OS handling. 

But I agree the Type-4 (GHES NMI) seems to prescribe rather than 
being a hint. Unlike x86, in ARM without the OS helping with the 
routing and setting the superpriority it would be a dead end.
Type4 seems like the wrong model. I won't pursue this further unless I
hear otherwise.

The second choice I prototyped was to just use the existing Type10
entry, it has the usual GSI and is already plumbed.

The missing piece here is to tell that we need "urgent" indication. 

We don't have a lot of room for meta-data, but one obvious candidate 
was to repurpose the ConfigurationWriteEnable bit. Currently the values
are

Bit 0  Type
Bit 1  Poll Interval
Bit 2  Switch To Polling Threshold Value
Bit 3  Switch To Polling Threshold Window
Bit 4  Error Threshold Value
Bit 5  Error Threshold Window

Bits6-15 are reserved and MBZ.

We could borrow a bit (bit15 for e.g), to indicate Urgent interrupt
source.

Proided that we can pursue this in the ACPI spec.

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

It doesn't need to be affinitized to one CPU. But request_nmi() seems to
required IRQF_PERCPU. 

I didn't change the default implementation, so I handled that with the
offline callback to retarget the interrupt to a different 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...

Sorry, weird spec language :-(

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

Maybe I missed something, if current version of request_nmi() can give
that migratable interrupt that's all we need. Likely I didn't set the
right bits. 

Let me know what you think about the Type10 proposal, and I'll drop the
Type4 and pursue this instead.

Cheers,
Ashok