From: Yuchao Zhang <ndaugoing@gmail.com>
To: Marc Zyngier <maz@kernel.org>
Cc: Oliver Upton <oliver.upton@linux.dev>,
Fuad Tabba <tabba@google.com>, James Morse <james.morse@arm.com>,
Suzuki K Poulose <suzuki.poulose@arm.com>,
Zenghui Yu <yuzenghui@huawei.com>,
Catalin Marinas <catalin.marinas@arm.com>,
Will Deacon <will@kernel.org>,
kvmarm@lists.linux.dev, linux-arm-kernel@lists.infradead.org,
linux-kernel@vger.kernel.org, Yuchao Zhang <ndaugoing@gmail.com>
Subject: Re: [PATCH v3 0/1] KVM: arm64: vgic: Drop last_lr_irq and serialize overflow EOI replay
Date: Tue, 22 Sep 2026 18:16:23 +0800 [thread overview]
Message-ID: <20260922101623.39468-1-ndaugoing@gmail.com> (raw)
In-Reply-To: <87bj9r4h9z.wl-maz@kernel.org>
Hi Marc,
Thank you for the candid feedback and for cutting right to the heart of
the problem with the 3-patch series on your branch.
Your series is vastly simpler and elegant:
1. Only caching last_lr_irq when LRs are genuinely full eliminates the
overhead for non-overflow exits.
2. Holding a proper reference on last_lr_irq and releasing it under
ap_list_lock in vgic_prune_ap_list() cleanly addresses the lifetime
hazard without introducing lock-order inversions during folding.
3. Halting the VM (kvm_arm_halt_guest) on remote GICR_CTLR.EnableLPIs=0
completely avoids cross-vCPU concurrency for an event that almost
never happens in practice.
As requested, I wrote a KVM arm64 selftest for this scenario:
tools/testing/selftests/kvm/arm64/vgic_lpi_disable.c
The test:
- Configures an ITS with multiple LPIs targeting vCPU 0.
- Keeps vCPU 0 in guest mode with EOImode=0 while injecting bursts of
MSIs to force its List Registers to overflow into the ap_list.
- Concurrently, vCPU 1 repeatedly toggles GICR_CTLR.EnableLPIs on
vCPU 0's redistributor.
Regarding testing: I currently no longer have access to KVM-capable
hardware (my test setup is no longer available), so I cannot provide
a Tested-by for your series. The race itself was originally identified
through code inspection rather than a standalone reproducer, which is
why I turned the theoretical scenario directly into this selftest.
The selftest builds cleanly as part of the full arm64 kvm selftest
suite, and its framework plumbing was smoke-tested under QEMU TCG,
which by construction cannot exercise the race itself. I'd be grateful
if you could give it a spin on your setup.
The selftest patch is based on top of your kvm-arm64/vgic-last_lr_irq-fixes
branch and has been sent in reply to this thread.
Thanks,
Yuchao
next prev parent reply other threads:[~2026-09-22 10:16 UTC|newest]
Thread overview: 19+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-09-18 4:02 [PATCH v2 0/1] KVM: arm64: vgic: fix UAF/crash on remote LPI disable zjamg
2026-09-18 4:02 ` [PATCH v2] KVM: arm64: vgic: Do not remove in-flight LPIs from AP list on disable zjamg
2026-09-18 7:22 ` Fuad Tabba
2026-09-18 11:50 ` Yuchao Zhang
2026-09-18 11:58 ` Fuad Tabba
2026-09-18 19:15 ` Oliver Upton
2026-09-20 23:54 ` Marc Zyngier
2026-09-20 1:49 ` [PATCH v3 0/1] KVM: arm64: vgic: Drop last_lr_irq and serialize overflow EOI replay Yuchao Zhang
2026-09-20 1:49 ` [PATCH v3] " Yuchao Zhang
2026-09-20 23:47 ` [PATCH v3 0/1] " Marc Zyngier
2026-09-22 10:16 ` Yuchao Zhang [this message]
2026-09-22 10:16 ` [PATCH] KVM: selftests: arm64: Add test for cross-vCPU LPI disable race Yuchao Zhang
2026-09-22 10:29 ` sashiko-bot
2026-09-22 10:53 ` Yuchao Zhang
2026-09-22 10:53 ` [PATCH v2] " Yuchao Zhang
2026-09-22 11:03 ` sashiko-bot
2026-09-22 11:24 ` Yuchao Zhang
2026-09-22 17:08 ` Fuad Tabba
2026-09-22 17:05 ` [PATCH v3 0/1] KVM: arm64: vgic: Drop last_lr_irq and serialize overflow EOI replay 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=20260922101623.39468-1-ndaugoing@gmail.com \
--to=ndaugoing@gmail.com \
--cc=catalin.marinas@arm.com \
--cc=james.morse@arm.com \
--cc=kvmarm@lists.linux.dev \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-kernel@vger.kernel.org \
--cc=maz@kernel.org \
--cc=oliver.upton@linux.dev \
--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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.