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

[Mark Brown]

On Thu, Nov 10, 2022 at 08:26:44AM +0000, Marc Zyngier wrote:

> My gripe with the current approach is that it took us a *very* long
> while to make pNMI work correctly in all cases (I'm pretty sure that
> Mark Rutland still has nightmares about it). But now that we have the
> framework for it and the mental model to match, I'd really want both
> NMI methods to be merely two implementations of the same concept.

> The only obvious difference should be that we can identify NMIs early
> and that acking a NMI cannot result in acking an IRQ. I'd expect
> everything else to be otherwise similar.

OK, I can respin easily enough with that approach I think.  We can
try to reduce the locked regions incrementally I guess.  My impression
had been that the issues had been more around managing the GIC.

> > I might have missed part of how that's handled or used,
> > especially given that I've not actively worked through this yet, but if
> > we're not doing so then we've got other problems with for example
> > PSTATE.BTYPE or PSTATE.SSBS.  It looks like it's available and I'm not
> > seeing any filtering of the values or anything.

> Imagine you run a VM on some FEAT_NMI-enabled HW. The guest uses the
> PSTATE.ALLINT bit because it can. Now we migrate the VM somewhere else
> that doesn't have ALLINT, and the VM is dead.

> This is a general problem with the architecture, but we definitely
> should take care of it as we're enabling these features.

Ah, I see - that's a relief.  I wasn't super sympathetic to any guests
that might try to enumerate the feature by checking for an UNDEF on the
register rather than the ID registers, but yes that would allow such
guests to run until migrated rather than dying immediately when they try
to write to the register.  I'd thought you were concerned about an issue
for unmigrated VMs.

> > Yeah, it's not great.  For NMIs Lorenzo is looking at the GIC side, I'll
> > let him clarify his schedule.  Here it's more the case that implementing
> > the architecture side without an interrupt controller isn't useful (and
> > certainly not usefully testable) than anything else - my expectation is
> > that it should work fine, though from your comments above it sounds like
> > there will be issues with the handling of PSTATE that I've not realised.

> The vgic support should be rather trivial. It is only a matter of
> adding the required interrupt state, reworking the priority sorting
> and LR stuffing, handling the additional MMIO range and dealing with
> the GIC versioning. Trapping of ALLINT should be done at the same
> time.

> If people cannot be bothered, I'll end-up doing it myself.

It'll get done, it's more a question of the split of work between myself
and Lorenzo together with starting to push the review for the
architecture side.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 488 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20221110/4c1ac216/attachment.sig>