From: Gavin Shan <gshan@redhat.com>
To: qemu-arm@nongnu.org
Cc: peter.maydell@linaro.org, drjones@redhat.com,
jthierry@redhat.com, aik@ozlabs.ru, maz@kernel.org,
qemu-devel@nongnu.org, eric.auger@redhat.com,
shan.gavin@gmail.com, pbonzini@redhat.com
Subject: Re: [RFC PATCH] hw/arm/virt: Support NMI injection
Date: Tue, 28 Jan 2020 17:48:32 +1100 [thread overview]
Message-ID: <d972631d-7db7-b6d5-61b8-244ae2c85882@redhat.com> (raw)
In-Reply-To: <20191219040612.28431-1-gshan@redhat.com>
[including more folks into the discussion]
> On Fri, 17 Jan 2020 at 14:00, Peter Maydell <peter.maydell@linaro.org> wrote:
>> On Thu, 19 Dec 2019 at 04:06, Gavin Shan <gshan@redhat.com> 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.
Thanks,
Gavin
next prev parent reply other threads:[~2020-01-28 6:49 UTC|newest]
Thread overview: 25+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-12-19 4:06 [RFC PATCH] hw/arm/virt: Support NMI injection Gavin Shan
2020-01-14 21:50 ` Gavin Shan
2020-01-17 14:00 ` Peter Maydell
2020-01-28 6:48 ` Gavin Shan [this message]
2020-01-28 8:05 ` Auger Eric
2020-01-28 9:25 ` Marc Zyngier
2020-01-28 10:56 ` Auger Eric
2020-01-28 10:59 ` Peter Maydell
2020-01-28 11:13 ` Marc Zyngier
2020-01-29 3:30 ` Gavin Shan
2020-01-28 8:29 ` Julien Thierry
2020-01-29 3:46 ` Gavin Shan
2020-01-29 7:57 ` Julien Thierry
2020-01-29 21:54 ` Gavin Shan
2020-01-30 10:58 ` Marc Zyngier
2020-01-31 6:51 ` Gavin Shan
2020-01-29 2:44 ` Alexey Kardashevskiy
2020-01-29 3:41 ` Gavin Shan
2020-01-29 9:04 ` Marc Zyngier
2020-01-31 6:59 ` Gavin Shan
2020-01-31 9:39 ` Marc Zyngier
2020-02-04 3:51 ` Gavin Shan
2020-02-04 10:22 ` Peter Maydell
2020-02-05 3:09 ` Shan Gavin
2020-02-05 8:07 ` Marc Zyngier
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=d972631d-7db7-b6d5-61b8-244ae2c85882@redhat.com \
--to=gshan@redhat.com \
--cc=aik@ozlabs.ru \
--cc=drjones@redhat.com \
--cc=eric.auger@redhat.com \
--cc=jthierry@redhat.com \
--cc=maz@kernel.org \
--cc=pbonzini@redhat.com \
--cc=peter.maydell@linaro.org \
--cc=qemu-arm@nongnu.org \
--cc=qemu-devel@nongnu.org \
--cc=shan.gavin@gmail.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).