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

[Marc Zyngier <maz@kernel.org>]

On Mon, 26 Oct 2026 19:25:21 +0000,
Ashok Raj <ashok.raj@oss.qualcomm.com> wrote:
> 
> On Fri, Oct 23, 2026 at 09:20:16PM -0700, Ashok Raj 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.
> > 
> FYI: I have submitted a code-first proposal for the Type-4 HEST/GHES
> changes.
> 
> I have some internal things to iron out to submit directly, thanks to
> Jonathan for helping out in the review and upload the document.
> 
> 
> https://github.com/tianocore/edk2/issues/13392
> 
> I have patches to work with this on top of the latest posted FEAT_NMI
> series all tested on Qemu SBSA ref. Will post them in a bit.
> 
> Please help with the review. 

I strongly oppose this sort of hacks.

Priorities (and by extension NMIs) only make sense when in the context
of the full set of priorities that the operating system uses. The fact
that Linux doesn't make much use of priorities should not result in
the firmware table becoming prescriptive.

The piece of SW that deals with the interrupt source should have
enough information to decide whether it is worth assigning a higher
priority to that interrupt, and there is no extra information to
convey. If the firmware table doesn't describe in enough detail what that
interrupt is for, then by any mean add that.

But mandating that the OS messes up its own priority scheme for
$ARBITRARY_REASONS is not an acceptable outcome.

Thanks,

	M.

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