[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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

From: Marc Zyngier
Subject: Re: [RFC PATCH] hw/arm/virt: Support NMI injection
Date: Fri, 31 Jan 2020 09:39:03 +0000
User-agent: Roundcube Webmail/1.3.8

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


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:


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?


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

reply via email to

[Prev in Thread] Current Thread [Next in Thread]