From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from bombadil.infradead.org (bombadil.infradead.org [198.137.202.133]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.lore.kernel.org (Postfix) with ESMTPS id 64921CD98D2 for ; Sun, 14 Jun 2026 15:13:36 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=lists.infradead.org; s=bombadil.20210309; h=Sender:List-Subscribe:List-Help :List-Post:List-Archive:List-Unsubscribe:List-Id:Content-Type:MIME-Version: References:In-Reply-To:Subject:Cc:To:From:Message-ID:Date:Reply-To: Content-Transfer-Encoding:Content-ID:Content-Description:Resent-Date: Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:List-Owner; bh=n2oKn+Yfwb3U/LW7KgT+S5AiYyO0bhaWoNFG1I7y8uo=; b=caOkQhbSw4Kei+uDxT9vvk1Ii4 1rb9txSc3JUSawtlccrcfw5jD6CtJJ4qtUWtc7lpLmHXYfQSZuga16mUpG0vHQej92OMuBX4bwcQD EcrlRsaQR+AjV3wGJilLdu+am+2+0Mic2UmbU+/1sRGSzoQJiCcMG/Pydh0fB6aDJ5pRKZOhkbqr+ cOnka9xX4IMLbVtXharAFGsFIDsj8wiTpXOwhTz1nFC5Ug1A+pSia/qLNBq6yGYvf0tDQYtg3KyKQ 0IxcKA3ZUtfXswl4B7auDNREkLmgk60NOxvyhMZg5mreW71YgD6ZL83u2fY+Z96laumM/OOFYVsMC Wc038i5Q==; Received: from localhost ([::1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.99.1 #2 (Red Hat Linux)) id 1wYmWd-0000000D6uC-31hs; Sun, 14 Jun 2026 15:13:27 +0000 Received: from tor.source.kernel.org ([172.105.4.254]) by bombadil.infradead.org with esmtps (Exim 4.99.1 #2 (Red Hat Linux)) id 1wYmWd-0000000D6u1-00AA for linux-arm-kernel@lists.infradead.org; Sun, 14 Jun 2026 15:13:27 +0000 Received: from smtp.kernel.org (quasi.space.kernel.org [100.103.45.18]) by tor.source.kernel.org (Postfix) with ESMTP id 08E106008A; Sun, 14 Jun 2026 15:13:26 +0000 (UTC) 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) 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 X-BeenThere: linux-arm-kernel@lists.infradead.org X-Mailman-Version: 2.1.34 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: "linux-arm-kernel" Errors-To: linux-arm-kernel-bounces+linux-arm-kernel=archiver.kernel.org@lists.infradead.org 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.