From: Peter Maydell <peter.maydell@linaro.org>
To: qemu-arm@nongnu.org, qemu-devel@nongnu.org
Cc: "Richard Henderson" <richard.henderson@linaro.org>,
"Shashi Mallela" <shashi.mallela@linaro.org>,
"Alex Bennée" <alex.bennee@linaro.org>,
"Marc Zyngier" <maz@kernel.org>
Subject: [PATCH for-6.2? 2/2] hw/intc/arm_gicv3: fix handling of LPIs in list registers
Date: Fri, 26 Nov 2021 16:39:15 +0000 [thread overview]
Message-ID: <20211126163915.1048353-3-peter.maydell@linaro.org> (raw)
In-Reply-To: <20211126163915.1048353-1-peter.maydell@linaro.org>
It is valid for an OS to put virtual interrupt ID values into the
list registers ICH_LR<n> which are greater than 1023. This
corresponds to (for example) KVM using the in-kernel emulated ITS to
give a (nested) guest an ITS. LPIs are delivered by the L1 kernel to
the L2 guest via the list registers in the same way as non-LPI
interrupts.
QEMU's code for handling writes to ICV_IARn (which happen when the L2
guest acknowledges an interrupt) and to ICV_EOIRn (which happen at
the end of the interrupt) did not consider LPIs, so it would
incorrectly treat interrupt IDs above 1023 as invalid. Fix this by
using the correct condition, which is gicv3_intid_is_special().
Note that the condition in icv_dir_write() is correct -- LPIs
are not valid there and so we want to ignore both "special" ID
values and LPIs.
(In the pseudocode this logic is in:
- VirtualReadIAR0(), VirtualReadIAR1(), which call IsSpecial()
- VirtualWriteEOIR0(), VirtualWriteEOIR1(), which call
VirtualIdentifierValid(data, TRUE) meaning "LPIs OK"
- VirtualWriteDIR(), which calls VirtualIdentifierValid(data, FALSE)
meaning "LPIs not OK")
This bug doesn't seem to have any visible effect on Linux L2 guests
most of the time, because the two bugs cancel each other out: we
neither mark the interrupt active nor deactivate it. However it does
mean that the L2 vCPU priority while the LPI handler is running will
not be correct, so the interrupt handler could be unexpectedly
interrupted by a different interrupt.
(NB: this has nothing to do with using QEMU's emulated ITS.)
Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
---
Not sure whether to put this into 6.2 -- I haven't ever seen
any actual misbehaviour, I found the bug by code inspection;
and we've behaved this way since the GICv3 support for
virtualization was first implemented, so it's not a regression.
---
hw/intc/arm_gicv3_cpuif.c | 5 ++---
1 file changed, 2 insertions(+), 3 deletions(-)
diff --git a/hw/intc/arm_gicv3_cpuif.c b/hw/intc/arm_gicv3_cpuif.c
index 7fbc36ff41b..7fba9314508 100644
--- a/hw/intc/arm_gicv3_cpuif.c
+++ b/hw/intc/arm_gicv3_cpuif.c
@@ -653,7 +653,7 @@ static uint64_t icv_iar_read(CPUARMState *env, const ARMCPRegInfo *ri)
if (thisgrp == grp && icv_hppi_can_preempt(cs, lr)) {
intid = ich_lr_vintid(lr);
- if (intid < INTID_SECURE) {
+ if (!gicv3_intid_is_special(intid)) {
icv_activate_irq(cs, idx, grp);
} else {
/* Interrupt goes from Pending to Invalid */
@@ -1265,8 +1265,7 @@ static void icv_eoir_write(CPUARMState *env, const ARMCPRegInfo *ri,
trace_gicv3_icv_eoir_write(ri->crm == 8 ? 0 : 1,
gicv3_redist_affid(cs), value);
- if (irq >= GICV3_MAXIRQ) {
- /* Also catches special interrupt numbers and LPIs */
+ if (gicv3_intid_is_special(irq)) {
return;
}
--
2.25.1
next prev parent reply other threads:[~2021-11-26 16:43 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-11-26 16:39 [PATCH for-6.2? 0/2] arm_gicv3: Fix handling of LPIs in list registers Peter Maydell
2021-11-26 16:39 ` [PATCH for-6.2? 1/2] hw/intc/arm_gicv3: Add new gicv3_intid_is_special() function Peter Maydell
2021-11-28 16:29 ` Alex Bennée
2021-11-26 16:39 ` Peter Maydell [this message]
2021-11-29 9:19 ` [PATCH for-6.2? 0/2] arm_gicv3: Fix handling of LPIs in list registers 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=20211126163915.1048353-3-peter.maydell@linaro.org \
--to=peter.maydell@linaro.org \
--cc=alex.bennee@linaro.org \
--cc=maz@kernel.org \
--cc=qemu-arm@nongnu.org \
--cc=qemu-devel@nongnu.org \
--cc=richard.henderson@linaro.org \
--cc=shashi.mallela@linaro.org \
/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).