mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
From: Fuad Tabba <fuad.tabba@linux.dev>
To: Marc Zyngier <maz@kernel.org>, Oliver Upton <oupton@kernel.org>
Cc: Hyunwoo Kim <imv4bel@gmail.com>, Eric Auger <eauger@redhat.com>,
	Joey Gouly <joey.gouly@arm.com>,
	Steffen Eiden <seiden@linux.ibm.com>,
	Suzuki K Poulose <suzuki.poulose@arm.com>,
	Zenghui Yu <yuzenghui@huawei.com>, Will Deacon <will@kernel.org>,
	Sascha Bischoff <sascha.bischoff@arm.com>,
	Sebastian Ene <sebastianene@google.com>,
	Fuad Tabba <tabba@google.com>,
	kvmarm@lists.linux.dev, linux-arm-kernel@lists.infradead.org,
	linux-kernel@vger.kernel.org, stable@vger.kernel.org
Subject: [PATCH v2] KVM: arm64: vgic-its: Update GITS_CTLR.Enabled under its_lock
Date: Mon,  2 Nov 2026 08:29:33 +0000	[thread overview]
Message-ID: <20261102082933.2673799-1-fuad.tabba@linux.dev> (raw)

A GITS_CTLR write that disables the ITS clears its->enabled and
invalidates the translation cache under cmd_lock, while an MSI
injection tests the enable bit and populates the cache under its_lock.
An injection that passed the test before the disable can cache its
translation after the invalidation, and the cached path then injects
the LPI from the disabled ITS on every later MSI for that event.

Take its_lock around the store and the invalidation, so that it
serializes the store against the test. Nest it under cmd_lock, as the
command handlers do.

Fixes: 86a7dae884f38 ("KVM: arm/arm64: vgic-its: Check the LPI translation cache on MSI injection")
Reported-by: Hyunwoo Kim <imv4bel@gmail.com>
Link: https://lore.kernel.org/ah6Lsi4MfKUU6wBR@v4bel/
Suggested-by: Oliver Upton <oupton@kernel.org>
Cc: stable@vger.kernel.org
Signed-off-by: Fuad Tabba <fuad.tabba@linux.dev>
---

Notes:
    Changes since v1 [1]:
      - Reworded the commit message.
      - Rebased on 7.4-rc1.
    
    Picking up the fix Marc was worried had stalled [2].
    
    The GICR_CTLR.EnableLPIs path has the same window and is left as
    is. vgic_its_invalidate_all_caches() can't take kvm->lock there (it
    runs with vcpu->mutex held) or config_lock (the userspace GICR_CTLR
    route already holds it). Instead, the vgic_target_oracle() check in
    my LPIs-disabled series [3] keeps an LPI off a redistributor with
    EnableLPIs clear. The two don't depend on each other.
    
    vgic_its_free_collection_list() still leaves the cache alone. A
    guest reaches it only through a GITS_BASER write, which already
    drops the cache (8cd92f77ae4f). An ITS reset frees the devices
    first, which drops it too. That leaves a failed collection-table
    restore. A VMM gets there with translations cached only by enabling
    the ITS before the restore, against the documented order. Those
    translations then keep injecting their LPIs into the old target
    vCPUs.
    
    Based on Linux 7.4-rc1 (6628e7d4c6b25; also applies to kvmarm/fixes
    79f3724ca8913).
    
    [1] https://lore.kernel.org/all/20260917162020.1612577-1-fuad.tabba@linux.dev/
    [2] https://lore.kernel.org/861pbr6emw.wl-maz@kernel.org/
    [3] https://lore.kernel.org/all/20261026092802.2636798-1-fuad.tabba@linux.dev/

 arch/arm64/kvm/vgic/vgic-its.c | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/arch/arm64/kvm/vgic/vgic-its.c b/arch/arm64/kvm/vgic/vgic-its.c
index 7e9b265b1f521..68e3034e52236 100644
--- a/arch/arm64/kvm/vgic/vgic-its.c
+++ b/arch/arm64/kvm/vgic/vgic-its.c
@@ -1800,9 +1800,12 @@ static void vgic_mmio_write_its_ctlr(struct kvm *kvm, struct vgic_its *its,
 		 !(its->cbaser & GITS_CBASER_VALID)))
 		goto out;
 
+	/* vgic_its_resolve_lpi() tests the enable bit and caches under its_lock. */
+	mutex_lock(&its->its_lock);
 	its->enabled = !!(val & GITS_CTLR_ENABLE);
 	if (!its->enabled)
 		vgic_its_invalidate_cache(its);
+	mutex_unlock(&its->its_lock);
 
 	/*
 	 * Try to process any pending commands. This function bails out early

base-commit: 6628e7d4c6b25c8d18f1345e3a20d21829aae7e4
-- 
2.47.3


                 reply	other threads:[~2026-11-02  8:29 UTC|newest]

Thread overview: [no followups] expand[flat|nested]  mbox.gz  Atom feed

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=20261102082933.2673799-1-fuad.tabba@linux.dev \
    --to=fuad.tabba@linux.dev \
    --cc=eauger@redhat.com \
    --cc=imv4bel@gmail.com \
    --cc=joey.gouly@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=oupton@kernel.org \
    --cc=sascha.bischoff@arm.com \
    --cc=sebastianene@google.com \
    --cc=seiden@linux.ibm.com \
    --cc=stable@vger.kernel.org \
    --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

all inboxes | Powered by JetHome®