From: Fuad Tabba <fuad.tabba@linux.dev>
To: Oliver Upton <oupton@kernel.org>, Marc Zyngier <maz@kernel.org>,
kvmarm@lists.linux.dev, linux-arm-kernel@lists.infradead.org
Cc: Joey Gouly <joey.gouly@arm.com>,
Suzuki K Poulose <suzuki.poulose@arm.com>,
Zenghui Yu <yuzenghui@huawei.com>,
Steffen Eiden <seiden@linux.ibm.com>,
Catalin Marinas <catalin.marinas@arm.com>,
Will Deacon <will@kernel.org>,
Mark Rutland <mark.rutland@arm.com>,
Andre Przywara <andre.przywara@arm.com>,
Eric Auger <eric.auger@redhat.com>,
Yuchao Zhang <ndaugoing@gmail.com>, Fuad Tabba <tabba@google.com>,
kvm@vger.kernel.org, linux-kernel@vger.kernel.org
Subject: [PATCH 0/3] KVM: arm64: vgic: Drop stale LPI pending state
Date: Thu, 5 Nov 2026 11:00:47 +0000 [thread overview]
Message-ID: <20261105110050.1244525-1-fuad.tabba@linux.dev> (raw)
Hi folks,
The GIC just keeps on giving. Three follow-ups to my LPI fixes for
redistributors with LPIs disabled [1], to fix pre-existing bugs Sashiko
found.
The first drops the pending state of every LPI targeting a
redistributor when the guest disables its LPIs, not just of those on
the AP list, so a re-enable with GICR_PENDBASER.PTZ set doesn't bring
any of them back. Linux never sets PTZ.
The second stops the pending-table save from writing to the table of a
redistributor while its LPIs are disabled.
The third stops KVM reading the pending table when mapping an LPI, so
that mapping a discarded LPI's INTID again doesn't make it pending a
second time. A Linux guest can hit that after its VMM pauses and
resumes it. It also drops the copy that patch 2 of [1] takes, which is
why it comes after the second. An LPI mapped after its redistributor
enabled LPIs no longer takes a bit the guest wrote into the table
before the enable. Keeping that needs a per-redistributor record of
the pending state of unmapped INTIDs. I can add it on top if you think
it's worth it.
A pending LPI that MOVI moves onto a redistributor with LPIs disabled,
or that a device signals there through a translation cached before the
move, can still be taken once after a PTZ-set enable. The architecture
lets KVM drop it, but that's pending state moved or raised onto a
redistributor with LPIs disabled, not state the guest gave up. I've
left it alone, but can fix it on top if you think it's worth it.
Reproducers for all three fail on kvmarm/fixes and pass with the
series. I'll fold them into vgic_lpi_stress separately.
Based on kvmarm/fixes (181a701fc14d3), which has [1].
Cheers,
/fuad
[1] https://lore.kernel.org/all/20261026092802.2636798-1-fuad.tabba@linux.dev/
Fuad Tabba (3):
KVM: arm64: vgic: Drop the pending state of all LPIs when disabling
LPIs
KVM: arm64: vgic-v3: Don't save pending tables with LPIs disabled
KVM: arm64: vgic-its: Don't read the pending table when mapping an LPI
.../virt/kvm/devices/arm-vgic-v3.rst | 1 +
arch/arm64/kvm/vgic/vgic-its.c | 33 ++++++++----
arch/arm64/kvm/vgic/vgic-mmio-v3.c | 13 ++---
arch/arm64/kvm/vgic/vgic-v3.c | 50 ++-----------------
arch/arm64/kvm/vgic/vgic.c | 16 +++++-
arch/arm64/kvm/vgic/vgic.h | 1 -
6 files changed, 49 insertions(+), 65 deletions(-)
base-commit: 181a701fc14d3d468c603b5ecfb9f12115c5fb72
--
2.47.3
next reply other threads:[~2026-11-05 11:01 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-11-05 11:00 Fuad Tabba [this message]
2026-11-05 11:00 ` [PATCH 1/3] KVM: arm64: vgic: Drop the pending state of all LPIs when disabling LPIs Fuad Tabba
2026-11-05 11:00 ` [PATCH 2/3] KVM: arm64: vgic-v3: Don't save pending tables with LPIs disabled Fuad Tabba
2026-11-05 11:00 ` [PATCH 3/3] KVM: arm64: vgic-its: Don't read the pending table when mapping an LPI Fuad Tabba
2026-11-05 15:51 ` [PATCH 0/3] KVM: arm64: vgic: Drop stale LPI pending state Marc Zyngier
2026-11-05 16:05 ` Fuad Tabba
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=20261105110050.1244525-1-fuad.tabba@linux.dev \
--to=fuad.tabba@linux.dev \
--cc=andre.przywara@arm.com \
--cc=catalin.marinas@arm.com \
--cc=eric.auger@redhat.com \
--cc=joey.gouly@arm.com \
--cc=kvm@vger.kernel.org \
--cc=kvmarm@lists.linux.dev \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-kernel@vger.kernel.org \
--cc=mark.rutland@arm.com \
--cc=maz@kernel.org \
--cc=ndaugoing@gmail.com \
--cc=oupton@kernel.org \
--cc=seiden@linux.ibm.com \
--cc=suzuki.poulose@arm.com \
--cc=tabba@google.com \
--cc=will@kernel.org \
--cc=yuzenghui@huawei.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