qemu-devel
[Top][All Lists]
Advanced

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

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


From: Julien Thierry
Subject: Re: [RFC PATCH] hw/arm/virt: Support NMI injection
Date: Tue, 28 Jan 2020 08:29:07 +0000
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.3.0

Hi Gavin,

On 1/28/20 6:48 AM, Gavin Shan wrote:
[including more folks into the discussion]

On Fri, 17 Jan 2020 at 14:00, Peter Maydell <address@hidden> wrote:
On Thu, 19 Dec 2019 at 04:06, Gavin Shan <address@hidden> wrote:
This supports NMI injection for virtual machine and currently it's only
supported on GICv3 controller, which is emulated by qemu or host kernel.
The design is highlighted as below:

* The NMI is identified by its priority (0x20). In the guest (linux)
kernel, the GICC_PMR is set to 0x80, to block all interrupts except
the NMIs when the external interrupt is disabled. It means the FIQ
and IRQ bit in PSTATE isn't touched when the functionality (NMI) is
functional.
* LPIs aren't considered as NMIs because of their nature. It means NMI
is either SPI or PPI. Besides, the NMIs are injected in round-robin
fashion is there are multiple NMIs existing.
* When the GICv3 controller is emulated by qemu, the interrupt states
(e.g. enabled, priority) is fetched from the corresponding data struct
directly. However, we have to pause all CPUs to fetch the interrupt
states from host in advance if the GICv3 controller is emulated by
host.

The testing scenario is to tweak guest (linux) kernel where the pl011 SPI can be enabled as NMI by request_nmi(). Check "/proc/interrupts" after injecting several NMIs, to see if the interrupt count is increased or not. The result
is just as expected.


So, QEMU is trying to emulate actual hardware. None of this
looks to me like what GICv3 hardware does... If you want to
have the virt board send an interrupt, do it the usual way
by wiring up a qemu_irq from some device to the GIC, please.
(More generally, there is no concept of an "NMI" in the GIC;
there are just interrupts at varying possible guest-programmable
priority levels.)


Peter, I missed to read your reply in time and apologies for late response.

Yes, there is no concept of "NMI" in the GIC from hardware perspective.
However, NMI has been supported from the software by kernel commit
bc3c03ccb4641 ("arm64: Enable the support of pseudo-NMIs"). The NMIs
have higher priority than normal ones. NMIs are deliverable after
local_irq_disable() because the SYS_ICC_PMR_EL1 is tweaked so that
normal interrupts are masked only.

It's unclear about the purpose of "nmi" QMP/HMP command. It's why I
put a RFC tag. The command has been supported by multiple architects
including x86/ppc. However, they are having different behaviors. The
system will be restarted on ppc with this command, 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.


As Peter stated, there is no NMI concept on aarch64 hardware. The pseudo-NMI in the Linux port is purely a software concept. The OS itself decides which interrupts should have the "NMI" properties and sets them up accordingly.

For QEMU to inject a pseudo-NMI into the guest would require it not only to know that the guest supports that feature. But also how such an interrupt has to be set up (currently there is no guaranty that the priority used for the NMI and the mask should stay the same across Linux version as it is purely internal to GICv3/arm64, no generic kAPI nor uAPI have access to it). And also, you would probably need to know what is handling the NMI you are injecting.

QEMU shouldn't try to guess "that might be dealt as an NMI, lets raise it".

I'm not familiar with the QMP/HMP nor the inner workings of QEMU, but if for some reason QEMU requires to trigger an NMI-like mechanic on aarch64, a proper way might be through para-virt. Having some "qemu-nmi-driver" in linux which calls "request_nmi()" and does the proper handling expected by QEMU.

Cheers,

--
Julien Thierry




reply via email to

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