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

[Marc Zyngier <maz@kernel.org>]

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/20191105091056.9541-1-guoheyi@huawei.com/

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...