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 12B644CC639; Mon, 12 Oct 2026 18:12:23 +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=1791828745; cv=none; b=cTXwBU7W/OOpr4g5Zf1PhV5eJIE/Xw6/67KBVMNjHQySMSaTrrN3NMTr7TUWd/gZ57n69kdB/zkG7y4HUoDaWMUJvoRHMkGQCs9dQNTTqf157wJ609RQOvz9gMnDwyXUJj4tpbeYFv9gCJJm89DwTVdszYcl9lHdKsJA4ThS64E= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1791828745; c=relaxed/simple; bh=ROJcSTTKh3rot1iRBmeJv/AQWQFclYTpFCWg2iYigwc=; h=Date:Message-ID:From:To:Cc:Subject:In-Reply-To:References: MIME-Version:Content-Type; b=XCHTDs3fKT38dvogjOol1Ua8LDKXmxN8hCDryaqk8R8/N7cpaE1ijRnFUS2/7Z0QaCQI+FWznElWTQ9QlIoE5HCdMtBrHelGGzTklqlU69co3N8EI5X1cvwyMsC1QLUwQj6B/mWHpzLzbjCRpecnYWPxxikN1xGCBA3rCgVklJA= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=EUhNMnvH; 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="EUhNMnvH" Received: by smtp.kernel.org (Postfix) with ESMTPSA id AB9071F008A1; Mon, 12 Oct 2026 18:12:23 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=kernel.org; s=k20260515; t=1791828743; bh=4uCUhIE6G5JFckb9nIlCjDzETQkPo/I1KxDu5i4hUVA=; h=Date:From:To:Cc:Subject:In-Reply-To:References; b=EUhNMnvHF8Z+yDS5LZ3fp/Ly/EsdPzAOdZ2tDgkj3G1zeq0FM0JwM1dc3wm5UtO17 gBprWlkC637unc6yqDzHeyYJejgjeJHBsgrro2ELXbxnGwaRfw0PGWqEiYeyBA2QUZ H1f+nZajSlbOm6hVlqbFkJT7FmonWcB3Da90+dakk+X6i5nxF3+lhEk5zwGqydLbaW Tux9BWWMstP70D4DCpZHL2pcPkIZZ/j/FgPw7TPIHHKDnEG/6Sle1TNxmXxd3I0RzO dulJt/IhqfCORnhCBk5FTs573kG6dtK3q/yT+EW1D40qZn/6sTgJEvdOUDja53co0l Rm04C/jT7pMpw== Received: from sofa.misterjones.org ([185.219.108.64] helo=goblin-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 1xGKVZ-000000021Pt-2am8; Mon, 12 Oct 2026 18:12:21 +0000 Date: Mon, 12 Oct 2026 19:12:21 +0100 Message-ID: <86zewi23ga.wl-maz@kernel.org> From: Marc Zyngier To: Fuad Tabba Cc: Oliver Upton , Joey Gouly , Steffen Eiden , Suzuki K Poulose , Zenghui Yu , Catalin Marinas , Will Deacon , Mark Rutland , linux-arm-kernel@lists.infradead.org, kvmarm@lists.linux.dev, linux-kernel@vger.kernel.org Subject: Re: [PATCH v1] KVM: arm64: vgic-v4: Don't forward an LPI with no target vCPU In-Reply-To: References: <20261012084743.2228612-1-fuad.tabba@linux.dev> <8633ub2mlg.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: linux-kernel@vger.kernel.org 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: fuad.tabba@linux.dev, 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, mark.rutland@arm.com, linux-arm-kernel@lists.infradead.org, kvmarm@lists.linux.dev, linux-kernel@vger.kernel.org X-SA-Exim-Mail-From: maz@kernel.org X-SA-Exim-Scanned: No (on disco-boy.misterjones.org); SAEximRunCond expanded to false On Mon, 12 Oct 2026 15:13:51 +0100, Fuad Tabba wrote: > > Hi Marc, > > On Mon, 12 Oct 2026 12:18:51 +0100, Marc Zyngier wrote: > [...] > > Isn't the core problem that we don't correctly handle the UNPRED > > double mapping of the same LPI? I'd rather we attack the issue at the > > source instead of papering over the consequences. > > > > I hacked the following, which is obviously untested. Can you give it a > > go? > > With your diff on rc3, the second MAPTI is dropped, and forwarding the > vfio-pci MSI to its event leaves the host up. > > However, a vgic_irq outlives its ITE while the LPI is pending on a > vCPU, so the check also drops a legitimate remap: a guest that > DISCARDs a pending LPI and then maps it again loses the new mapping. But this is yet another bug: 5.3.4 is pretty clear that DISCARD should get rid of everything (pending bit and mapping). I reckon this is yet another case of the initial implementation being overly worried about kicking vcpus out of the guest when destructive action is required. We should fix this. Thanks, M. -- Without deviation from the norm, progress is not possible.