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 DD97BCD6E74 for ; Fri, 5 Jun 2026 07:39:44 +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=6eQtmLE1c8wLqcxp3CgPQl14giwjotvc8+E1FCWm2K4=; b=2tQX5pHgwiW1TzGKE1lWSKmuQM gs8f2gJWkbBEIyjP43MMsF1ZbnkB3K9JxsvAwIxz48Sku04lWYjlKjMOWtLkqaO/AREGsv9Z/JKEZ OxQgH/UynIuhxR2MtKHOZIkIKbphaVP/hAo+uJJDSxKTMyZ2qm/zoR5EvtdaT/RmFM37jprPPfW1q QLzEqJncs5vHUW/6B4fHlMPmC/Wvh3aVZ56A+S+I6o5WDvYTmujCVMJhtjkY0OKrr/cQv1qXsHV/J kn8jP8+jroYdrGFi4c5Kk0cAGqkrOTQtx3VyevcKWwgpKF+CajyKP0hU63M55I4ecPivRBNeWCCW9 JvTGg4VQ==; Received: from localhost ([::1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.99.1 #2 (Red Hat Linux)) id 1wVP9W-00000000FJP-0XcT; Fri, 05 Jun 2026 07:39:38 +0000 Received: from sea.source.kernel.org ([2600:3c0a:e001:78e:0:1991:8:25]) by bombadil.infradead.org with esmtps (Exim 4.99.1 #2 (Red Hat Linux)) id 1wVP9U-00000000FJD-0vbL for linux-arm-kernel@lists.infradead.org; Fri, 05 Jun 2026 07:39:36 +0000 Received: from smtp.kernel.org (quasi.space.kernel.org [100.103.45.18]) by sea.source.kernel.org (Postfix) with ESMTP id 86F934043E; Fri, 5 Jun 2026 07:39:35 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 66C601F00893; Fri, 5 Jun 2026 07:39:35 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=kernel.org; s=k20260515; t=1780645175; bh=6eQtmLE1c8wLqcxp3CgPQl14giwjotvc8+E1FCWm2K4=; h=Date:From:To:Cc:Subject:In-Reply-To:References; b=DHsIJtPF7yx3ED5qg2nSB/Xc4cuY/8kYs32Kh7L/+tAJAywSNRDN1m5LaKgwT/7TD EKU8AlYEXtae3aZELbaylxTU+0a+Ypl5foFFGpzW9YrGaQ6AgiP89KqWcy0A8WbQF9 aAifBpFIkaMu+T9r0Qv9dTvY2dWiP/+J0fKU9X1bqnIHLj+YGyUkoZr8XiBOG9tXOy q6oAlKUmECPlTt3WX0GF5tJ/ichzycY9xenjTcS0J47B8j160kwdS+acEo17WAYwdX 2GPYTqgtkdNTY/UphsgaxLQn56dZey696+IyE3s+JkSAb0fgGG6OxjEHskPrUyDjon ezd7PzO13U8cQ== 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 1wVP9R-00000009fpf-0I9V; Fri, 05 Jun 2026 07:39:33 +0000 Date: Fri, 05 Jun 2026 08:42:52 +0100 Message-ID: <87ecila0w3.wl-maz@kernel.org> From: Marc Zyngier To: Oliver Upton Cc: Hyunwoo Kim , 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, eric.auger@linaro.org, christoffer.dall@linaro.org, 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: 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: oupton@kernel.org, imv4bel@gmail.com, 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, eric.auger@linaro.org, christoffer.dall@linaro.org, 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, 05 Jun 2026 07:00:37 +0100, Oliver Upton wrote: > > On Fri, Jun 05, 2026 at 05:59:15AM +0900, Hyunwoo Kim wrote: > > vgic_prune_ap_list() drops both ap_list_lock and irq_lock while migrating > > an interrupt to another vCPU. After reacquiring the locks it only checks > > that the affinity is unchanged (target_vcpu == vgic_target_oracle(irq)) > > before moving the interrupt, which assumes that an interrupt whose affinity > > is preserved is still queued on this vCPU's ap_list. > > > > That assumption no longer holds if the interrupt is taken off the ap_list > > while the locks are dropped. vgic_flush_pending_lpis() removes the > > interrupt from the list and sets irq->vcpu to NULL, but leaves > > enabled/pending/target_vcpu untouched. As the interrupt is still enabled > > and pending, vgic_target_oracle() returns the same target_vcpu, so the > > affinity check passes and list_del() is run a second time on an entry that > > has already been removed. > > > > Also check that the interrupt is still assigned to this vCPU > > (irq->vcpu == vcpu) before moving it. > > > > Fixes: 0919e84c0fc1 ("KVM: arm/arm64: vgic-new: Add IRQ sync/flush framework") > > Signed-off-by: Hyunwoo Kim > > Looking at this and the other VGIC patch you sent (which should've been > a combined series), are you trying to deal with a vCPU writing to > another vCPU's redistributor? I.e. vCPU B setting GICR_CTLR.EnableLPIs=0 > behind the back of vCPU A? > > That is extremely relevant information as the off-the-cuff reaction is > that no race exists. But since the GIC architecture is awesome and > allows for this sort of insanity, it obviously does.... > > Anyway, for LPIs resident on a particular RD, there's zero expectation > that the pending state is preserved when EnableLPIs=0. So I'd rather > vgic_flush_pending_lpis() just invalidate the pending state. Just clearing the pending state introduces a potential problem as we now have an interrupt that is neither active nor pending on the AP list. It is not impossible to solve (we now have similar behaviours with SPI deactivation from another vcpu), but that requires posting a KVM_REQ_VGIC_PROCESS_UPDATE to the target vcpu. > Beyond that, I see two other fixes for lifetime issues around the > vgic_irq in the middle of migration. I'd like to see explicit RCU > protection around the release && reacquire of the ap_list_lock rather > than depending on the precondition that IRQs are disabled. I'm not sure I follow. Are you suggesting turning the AP list into an RCU protected list? Thanks, M. -- Jazz isn't dead. It just smells funny.