From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-1.web.codeaurora.org [10.30.226.201]) (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 88F2C84FAB for ; Thu, 7 Mar 2024 10:09:06 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=10.30.226.201 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1709806146; cv=none; b=JwitLNKCDDYTqrkK8WSYleEPQGmM3uFVWj7mzYS+VJXcBHKyGLX5rp7N6Nof+CAb2WUIIO+YZRF+dUYqng2ORlfc3X+e9E8Y6slpzDTv7XkM42Htpq6Nlb2bgHzKiB9S4Ta7v6xycpnGG0fj+0hqwCJD/dP7KiaWI8Cv+EtpcfM= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1709806146; c=relaxed/simple; bh=yMXjWgq0mOAdw1nmjd1l1sqfbnHdVcr32lZZ4bxqwEc=; h=Date:Message-ID:From:To:Cc:Subject:In-Reply-To:References: MIME-Version:Content-Type; b=nhHldPojxPMgkKv2rfWPL62Ft3dO80gxSStyc/8HW8Hr4oz+Wj+7JKV+gUZ4kJtJOp6OLNcOxAa7BLUwEVrR719UImWWV1n1CrxWTr65cB/blvrOBV8xUk/bQIg1+0wldWCmttjax4bBLXqFjzmtocAOTabdVxnv4FrExYDTqqw= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=KMMw2YNQ; arc=none smtp.client-ip=10.30.226.201 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="KMMw2YNQ" Received: by smtp.kernel.org (Postfix) with ESMTPSA id 23231C433C7; Thu, 7 Mar 2024 10:09:06 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1709806146; bh=yMXjWgq0mOAdw1nmjd1l1sqfbnHdVcr32lZZ4bxqwEc=; h=Date:From:To:Cc:Subject:In-Reply-To:References:From; b=KMMw2YNQxYk/L6R67hJOk9fx7RTTwCq48dPq8zisLtcwBdk1ePs5URk64RT+ZxwMR iq37xyU7n2MUh3QYBGDQdSupXMsCTROq2vndJ0xEpbi3HBgBMhFGeKXvSuZCayZ1l7 kuwAgljs8sEUOay9fUN9Xfzao8Hg7DZ31FzQCN+juarikVcjHNLwMs5eSeI/QKGi0I IiRPNo2QWaXgQ0i8n4jQ6szeppAuPRb0O5dRws1pbHCvRXRRuMV/tw2yF1v6HwBJi0 5ahufky5Nd9Fzm3Es9rgSPzshe0d7Udca+M9u6pGdAdej33LcAhzMALeDWYwW2uS9i EePrVGiULG5QQ== 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.95) (envelope-from ) id 1riAgQ-00AFEh-Pf; Thu, 07 Mar 2024 10:09:03 +0000 Date: Thu, 07 Mar 2024 10:09:02 +0000 Message-ID: <86o7bq1hhd.wl-maz@kernel.org> From: Marc Zyngier To: Zenghui Yu Cc: Oliver Upton , , James Morse , Suzuki K Poulose , Eric Auger Subject: Re: [PATCH] KVM: arm64: vgic-v3: Don't load pending state when enabling LPIs on RD In-Reply-To: References: <20240228000117.2297982-1-oliver.upton@linux.dev> 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/29.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: yuzenghui@huawei.com, oliver.upton@linux.dev, kvmarm@lists.linux.dev, james.morse@arm.com, suzuki.poulose@arm.com, eric.auger@redhat.com X-SA-Exim-Mail-From: maz@kernel.org X-SA-Exim-Scanned: No (on disco-boy.misterjones.org); SAEximRunCond expanded to false Hi Zenghui, On Thu, 07 Mar 2024 09:00:42 +0000, Zenghui Yu wrote: > > So I've tested it with kvm-unit-tests and got failure with the > its-pending-migration case: > > INFO: gicv3: its-pending-migration: Migration complete > INFO: gicv3: its-pending-migration: expected 128 LPIs on PE #30, 0 observed > FAIL: gicv3: its-pending-migration: 128 LPIs on both PE0 and PE1 after > migration > SUMMARY: 1 tests, 1 unexpected failures > > where the guest SW directly writes to the pending table when > GICR_CTLR.EnableLPIs == 0. I seriously doubt there is any use case like > that in real world. But not sure whether it is a funky behaviour from > the architectural perspective. Right, so this is *exactly* the thing I was worried about. A mapping has been established, the interrupt wasn't pending, all good. Now, an interrupt lands while GICR_CTLR.EnableLPIs == 0. The spec says (4.7.3 "Effect of disabling interrupts") "When GICR_CTLR.EnableLPIs == 0, LPIs are never set pending." which to me is a pretty damning indication that we shouldn't take these bits into account. Of course, there is a grey area, in the sense that when we restore an LPI via the restore interface, we are actually consuming pending bits before EnableLPIs is set to 1. But I would tend to draw the line between an interrupt that is restored as part of rebuilding the KVM state, and an interrupt that is forcefully injected behind our back. Thanks, M. -- Without deviation from the norm, progress is not possible.