[PATCH v1 00/18] arm64/nmi: Support for FEAT_NMI

[Marc Zyngier]

On Fri, 04 Nov 2022 23:54:35 +0000,
Mark Brown <broonie at kernel.org> wrote:
> 
> This series enables the architecture and GIC support for the arm64
> FEAT_NMI and FEAT_GICv3_NMI extensions in host kernels.  These introduce
> support for a new category of interrupts in the architecture code which
> we can use to provide NMI functionality, though the interrupts are in
> fact maskable as the name would not imply.  The GIC support was done by
> Loreozo Pieralisi.
> 
> There are two modes for using this FEAT_NMI, the one we use is the one
> where any entry to ELn causes all interrupts including those with
> superpriority to be masked by a new mask bit ALLINT.ALLINT on entry to
> ELn until the mask is explicitly removed by software.  We do this early
> in the C entry code for anything that is not a superpriority interrupt,
> those are handled without unmasking.  Independent controls are provided
> for this feature at each EL, usage at EL1 should not disrupt EL2 or EL3.
> 
> Since we can mask these not quite NMIs a large portion of the series is
> concerned with updating places where we really do not want to be taking
> interrupts of any kind to add masking for NMIs.  This masking is not
> added to our standard interrupt masking operations since that would
> result in widespread masking of NMIs which would undermine their value.
> Given that there's a large amount of kernel code a good proportion of
> which I'm not terribly familar with it is likely that this area of the
> series needs attention in review as there may be be be areas that have
> been missed or misunderstood.

Can you at least clarify why the no-quite-NMI cannot follow the
pattern established by the pseudo-NMI support? I would have expected
the critical sections to strictly map between the two so-called-NMI
implementations.

> 
> In order to ensure that we do not have both pseudo NMIs and real NMIs
> simultaneously enabled we disable NMIs if pseudo NMI support is enabled
> in the kernel and has been requested on the command line, since pseudo
> NMIs require explicit enablement it seemed most sensible to trust that
> the user preferred them for some reason.
> 
> Using this feature in KVM guests will require the implementation of vGIC
> support which is not present in this series, and there is also no usage
> of the feature at EL2.  While FEAT_NMI does add a new writable register
> ALLINT the value is already context switched for EL1 via SPSR_EL2.ALLINT 
> and we can't trap read access to the register so we don't manage the
> write trap that is available in HCRX_EL2.TALLINT.  Guests can read from
> the register anyway and should only be able to affect their own state.

... and create some architectural state that is impossible to manage
and migrate. Great.

Frankly, we are accumulating a bunch of half implemented features
(SME, SPE) for which there is no KVM support, and I don't think this
is the correct direction of travel.

	M.

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