Re: [RFC PATCH] hw/arm/virt: Support NMI injection

[Marc Zyngier]

On 2020-01-31 06:59, Gavin Shan wrote:
> On 1/29/20 8:04 PM, Marc Zyngier wrote:
> > On 2020-01-29 02:44, Alexey Kardashevskiy wrote:
> > > On 28/01/2020 17:48, Gavin Shan wrote:
> > > > but a NMI is injected
> > > > through LAPIC on x86. So I'm not sure what architect (system reset 
> > > > on
> > > > ppc or injecting NMI on x86) aarch64 should follow.
> > >
> > > I'd say whatever triggers in-kernel debugger or kdump but I am not
> > > familiar with ARM at all :)
> >
> > All that is completely OS specific, and has no relation to the 
> > architecture.
> > As I mentioned in another part of the thread, the closest thing to 
> > this
> > would be to implement SDEI together with an IMPDEF mechanism to enter 
> > it
> > (or even generate a RAS error).
> >
> > On the other hand, SDEI is pretty horrible, and means either KVM or 
> > QEMU
> > acting like a firmware for the guest. To say that I'm not keen is a 
> > massive
> > understatement.
> >
> >          M.
>
> Marc, could you please explain a bit about "IMPDEF mechanism"? I'm not 
> sure if
> it means a non-standard SDEI event should be used, corresponding to the 
> HMP/QMP
> "nmi" command.

SDEI doesn't quite describe *why* and *how* you enter it. You just get 
there by
some mean (SError, Group-0 interrupt, or IMPlementation DEFined 
mechanism).
It is then for the SDEI implementation to sort it out and enter the OS 
using the
registered entry point.

> Also, If I'm correct, you agree that a crash dump should be triggered 
> on arm64
> guest once HMP/QMP "nmi" command is issued?

No, I don't agree. QEMU and KVM are OS agnostic, and there is nothing in 
the ARMv8
architecture that talks about "crash dumps".  If your "nmi" command 
generates
a SDEI event and that event gets dispatched to the guest, it is entirely 
the guest's
responsibility to do whatever it wants. We should stay clear of assuming 
behaviours.

> I also dig into SDEI a bit. It seems the SDEI support in QEMU isn't 
> upstream yet:
>
> https://patchew.org/QEMU/address@hidden/

And I'm glad. SDEI, as I said, is absolutely horrible. I'm also very 
fortunate
to have been CC'd on this series on an email address I cannot read.
This would have huge impacts on both QEMU and KVM, and this needs more 
than
a knee jerk reaction to support a QEMU command.

And to be honest, if what you require is the guest kernel to panic, why 
don't
you just implement a QEMU-specific driver in Linux that does just that?
Some kind of watchdog driver, maybe?

Thanks,

        M.
--
Jazz is not dead. It just smells funny...