From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-alma10-1.taild15c8.ts.net [100.103.45.18]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id D815C1A4F2F for ; Sun, 14 Jun 2026 15:13:25 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=100.103.45.18 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1781450006; cv=none; b=Gj/BBRrN4e9AdwLb4cRd8z+2GTRVcdeuLoC1zB+K/aT9UWyGcEjkknZKpEnpZoKQgKBRAKbypCDzvsOU4GnH0Jrt35mIvkOA4OPOVV60c28moi0lfCTPwSAzS6WvBDbadtyqLYN9299OszLIRPGe6Zl4JcMQWkiOQEYX0X/IIw0= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1781450006; c=relaxed/simple; bh=139tymh7HbUU5BLJMGzQ1LXS9EIMyy+mdMwid2wG4xw=; h=Date:Message-ID:From:To:Cc:Subject:In-Reply-To:References: MIME-Version:Content-Type; b=tvh1GpLpdC5DhfmkkX4T1XsJkZ07k7KTHLUtuwDnJUjMjTM6TFksuhgHZqgcb++ko5w+p2RwkItDf1KGueWJLGvLjFJnCRr7TH/kdAj3ngax3Wtr1hbEIxzgsyO58gQbKsKOC6otmsOoo/3IyPYAe1nLIvKHk+e4Oe+URzz1570= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=DzNXFAcS; arc=none smtp.client-ip=100.103.45.18 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="DzNXFAcS" Received: by smtp.kernel.org (Postfix) with ESMTPSA id AAF521F000E9; Sun, 14 Jun 2026 15:13:25 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=kernel.org; s=k20260515; t=1781450005; bh=n2oKn+Yfwb3U/LW7KgT+S5AiYyO0bhaWoNFG1I7y8uo=; h=Date:From:To:Cc:Subject:In-Reply-To:References; b=DzNXFAcSOasKanxmXVIoIWdhCvakb6h+Nub8mq/i6J65Yw097mZQ4WE46ukJ6wRxf l1KXPpKe3no6hDkiaMtk99ifXIAOOw8pQ4NbchHfTshysdpMXM5sZvnvtZBx+n6jfz GHqP3iiKbZal0GTnzY4V6j07ezom8KSD7FUtSv6V+N4wKkEy7YpXFDYWlCbudE+nhr n5C+n0hmCN+2CvNmQUTtklo4JM0P/VGZ+4XTlG2qNVDXmbkcj3qgmW4WqqVLQH1W4O Cwlz821ZMO2mZsWOoLKyJaX6GSAeRoYmtrpI8Xl3t4QFnl3FfUFKYEfXkVI6vBi3Rk /PjoNj1n6dT+w== Received: from sofa.misterjones.org ([185.219.108.64] helo=lobster-girl.misterjones.org) by disco-boy.misterjones.org with esmtpsa (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.98.2) (envelope-from ) id 1wYmWZ-0000000CgRX-0iKr; Sun, 14 Jun 2026 15:13:23 +0000 Date: Sun, 14 Jun 2026 16:16:44 +0100 Message-ID: <87ldch884j.wl-maz@kernel.org> From: Marc Zyngier To: Hyunwoo Kim Cc: Oliver Upton , joey.gouly@arm.com, seiden@linux.ibm.com, suzuki.poulose@arm.com, yuzenghui@huawei.com, catalin.marinas@arm.com, will@kernel.org, Sascha.Bischoff@arm.com, jic23@kernel.org, timothy.hayes@arm.com, andre.przywara@arm.com, linux-arm-kernel@lists.infradead.org, kvmarm@lists.linux.dev Subject: Re: [PATCH] KVM: arm64: vgic: Check the interrupt is still ours before migrating it In-Reply-To: References: <87ecila0w3.wl-maz@kernel.org> <865x3qtmg6.wl-maz@kernel.org> User-Agent: Wanderlust/2.15.9 (Almost Unreal) SEMI-EPG/1.14.7 (Harue) FLIM-LB/1.14.9 (=?UTF-8?B?R29qxY0=?=) APEL-LB/10.8 EasyPG/1.0.0 Emacs/30.1 (aarch64-unknown-linux-gnu) MULE/6.0 (HANACHIRUSATO) Precedence: bulk X-Mailing-List: kvmarm@lists.linux.dev List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 (generated by SEMI-EPG 1.14.7 - "Harue") Content-Type: text/plain; charset=US-ASCII X-SA-Exim-Connect-IP: 185.219.108.64 X-SA-Exim-Rcpt-To: imv4bel@gmail.com, oupton@kernel.org, joey.gouly@arm.com, seiden@linux.ibm.com, suzuki.poulose@arm.com, yuzenghui@huawei.com, catalin.marinas@arm.com, will@kernel.org, Sascha.Bischoff@arm.com, jic23@kernel.org, timothy.hayes@arm.com, andre.przywara@arm.com, linux-arm-kernel@lists.infradead.org, kvmarm@lists.linux.dev X-SA-Exim-Mail-From: maz@kernel.org X-SA-Exim-Scanned: No (on disco-boy.misterjones.org); SAEximRunCond expanded to false On Fri, 12 Jun 2026 03:22:35 +0100, Hyunwoo Kim wrote: > > On Wed, Jun 10, 2026 at 05:00:25PM +0100, Marc Zyngier wrote: > > It's rather unclear to me what the semantics of this are. > > > > If vcpu-a decides to nuke the LPIs of vcpu-b and the LPI had in the > > meantime been migrated to vcpu-c, but obviously not observed by vcpu-c > > yet as the LPI is still on vcpu-b's AP-list, then I don't see the > > point in keeping this state. > > > > Am I missing something obvious? > > I looked a bit more into Oliver's review, the one suggesting that pending > be cleared only for resident LPIs while the ones being migrated are left > in place. > > What the leave preserves is the pending edge of a single LPI whose target > is already vcpu-c but which is still on vcpu-b's ap_list. This edge is > always lost when we just clear it, but for a device that fires again a > later INT reaches vcpu-c through the oracle, so it is mostly harmless. Not completely harmless. When the guest writes EnableLPIs==0, it accepts the lost of any pending bit that could be stored. These won't be regenerated, unless the device signals a new event that maps to the same LPIs. But again, this is the guest's own decision, and I don't see a reason to prevent it from shooting itself in the foot. > The > exception is a software LPI that never fires again(irq->hw == false): > that edge is then lost with no way to recover it, because > its_sync_lpi_pending_table only re-syncs the LPIs whose target_vcpu matches, > and the disable path does no pending writeback. I am not entirely sure about > this part, though. I don't think this is a problem, as the architecture doesn't guarantee the state of the pending table after turning EnableLPIs off. There's even a note recommending to move the interrupts to another RD before doing that. > > Since this does not look like the common case, if it does not need to be > covered I will send v2 keeping only the pending clear and the ref hold in > vgic_prune_ap_list(). What do you think? So that it is entirely unambiguous, my suggestion is to have this: diff --git a/arch/arm64/kvm/vgic/vgic.c b/arch/arm64/kvm/vgic/vgic.c index 5a4768d8cd4f3..70a161383e5a6 100644 --- a/arch/arm64/kvm/vgic/vgic.c +++ b/arch/arm64/kvm/vgic/vgic.c @@ -203,6 +203,7 @@ void vgic_flush_pending_lpis(struct kvm_vcpu *vcpu) list_for_each_entry_safe(irq, tmp, &vgic_cpu->ap_list_head, ap_list) { if (irq_is_lpi(vcpu->kvm, irq->intid)) { raw_spin_lock(&irq->irq_lock); + irq->pending_latch = false; list_del(&irq->ap_list); irq->vcpu = NULL; raw_spin_unlock(&irq->irq_lock); @@ -792,7 +793,11 @@ static void vgic_prune_ap_list(struct kvm_vcpu *vcpu) continue; } - /* This interrupt looks like it has to be migrated. */ + /* + * This interrupt looks like it has to be migrated, + * make sure it is kept alive while locks are dropped. + */ + vgic_get_irq_ref(irq); raw_spin_unlock(&irq->irq_lock); raw_spin_unlock(&vgic_cpu->ap_list_lock); @@ -836,6 +841,8 @@ static void vgic_prune_ap_list(struct kvm_vcpu *vcpu) raw_spin_unlock(&vcpuB->arch.vgic_cpu.ap_list_lock); raw_spin_unlock(&vcpuA->arch.vgic_cpu.ap_list_lock); + deleted_lpis |= vgic_put_irq_norelease(vcpu->kvm, irq); + if (target_vcpu_needs_kick) { kvm_make_request(KVM_REQ_IRQ_PENDING, target_vcpu); kvm_vcpu_kick(target_vcpu); Could you please give it a go with whatever reproducer you have? Thanks, M. -- Jazz isn't dead. It just smells funny.