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 9CE2521E088; Mon, 10 Mar 2025 11:42:51 +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=1741606971; cv=none; b=Lz2Hqd4cthYZZ/lPWhQJqAIYCQrowCarpaodcqt36Nev9H2SFZzjw69AlEC6PrRb2EewBPhluwteHXd5okPyHHm17Z1uWrR1IYolAEiy4ctmVTw64PIegIu3vxl0JoDpdmlCKXD6IlGGEcWDMEDuOHgQun87xstbhqTFg8chN/Y= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1741606971; c=relaxed/simple; bh=xypKLBSRK+f/hP1WP1Z/qtoHUvhbr3rrnxD0zz/vPi0=; h=Date:Message-ID:From:To:Cc:Subject:In-Reply-To:References: MIME-Version:Content-Type; b=JoAaZ3suz5WBLdrIfVKIiQwek3uGL3MK4NxD3fmaZVS5qP3KeGX/fcnUP6laN1nvlKt2hhD5QiR+RqCiRBAQP69YUpdimpTRd+4b54zvKQIj9mZt8nlF3Q6oGQBeyPEx9WmVFvSMJGazjjaZ04xGkxVgtsCK8zx0qmbxVk7gjA0= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=Bram9Ioq; 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="Bram9Ioq" Received: by smtp.kernel.org (Postfix) with ESMTPSA id 1608FC4CEE5; Mon, 10 Mar 2025 11:42:51 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1741606971; bh=xypKLBSRK+f/hP1WP1Z/qtoHUvhbr3rrnxD0zz/vPi0=; h=Date:From:To:Cc:Subject:In-Reply-To:References:From; b=Bram9Ioq++dX2SLjUUUyVswCF6Rk9Ou8XjSu6yp70TNv3b11WBAuN2o2/BdZ08KNL Lo50Ux7k1hEwZJZ4/4Gtl77Ea9oNstZyxqBHPQY1b8ueiFOymzd8Wc7OBDWvJUwKa+ NPJygOZNQQDdqzsCYHdihQzS1IunX9yeaG8LAUB2H6cS2LEUydWJuDcfot8rw3/fGf 6fGjMl/DvlBewrnUSkNvD06BOcZfdNiB3xCxaHMlLbu2AWNVR/KjcH0JHhzOok4BFo bQlDEhqeBU6mnUnQnWVp0VZdhtoxNvpC50SbWrP/D/pLl8oeC5iEHA+Pk7E+YcA624 Y8aYSqp/wi6DQ== 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 1trbWy-00C9i8-I3; Mon, 10 Mar 2025 11:42:48 +0000 Date: Mon, 10 Mar 2025 11:42:48 +0000 Message-ID: <8634flp0w7.wl-maz@kernel.org> From: Marc Zyngier To: Fuad Tabba Cc: kvmarm@lists.linux.dev, kvm@vger.kernel.org, linux-arm-kernel@lists.infradead.org, Joey Gouly , Suzuki K Poulose , Oliver Upton , Zenghui Yu , Mark Rutland Subject: Re: [PATCH 07/18] KVM: arm64: Compute FGT masks from KVM's own FGT tables In-Reply-To: References: <20250210184150.2145093-1-maz@kernel.org> <20250210184150.2145093-8-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/29.4 (aarch64-unknown-linux-gnu) MULE/6.0 (HANACHIRUSATO) Precedence: bulk X-Mailing-List: kvm@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: tabba@google.com, kvmarm@lists.linux.dev, kvm@vger.kernel.org, linux-arm-kernel@lists.infradead.org, joey.gouly@arm.com, suzuki.poulose@arm.com, oliver.upton@linux.dev, yuzenghui@huawei.com, mark.rutland@arm.com X-SA-Exim-Mail-From: maz@kernel.org X-SA-Exim-Scanned: No (on disco-boy.misterjones.org); SAEximRunCond expanded to false On Tue, 04 Mar 2025 16:55:50 +0000, Fuad Tabba wrote: > > Hi Marc, > > On Mon, 10 Feb 2025 at 18:42, Marc Zyngier wrote: > > > > In the process of decoupling KVM's view of the FGT bits from the > > wider architectural state, use KVM's own FGT tables to build > > a synthitic view of what is actually known. > > synthitic -> synthetic > > > > This allows for some checking along the way. > > > > Signed-off-by: Marc Zyngier > > --- > > arch/arm64/include/asm/kvm_arm.h | 4 ++ > > arch/arm64/include/asm/kvm_host.h | 14 ++++ > > arch/arm64/kvm/emulate-nested.c | 102 ++++++++++++++++++++++++++++++ > > 3 files changed, 120 insertions(+) > > > > diff --git a/arch/arm64/include/asm/kvm_arm.h b/arch/arm64/include/asm/kvm_arm.h > > index 8d94a6c0ed5c4..e424085f2aaca 100644 > > --- a/arch/arm64/include/asm/kvm_arm.h > > +++ b/arch/arm64/include/asm/kvm_arm.h > > @@ -359,6 +359,10 @@ > > #define __HAFGRTR_EL2_MASK (GENMASK(49, 17) | GENMASK(4, 0)) > > #define __HAFGRTR_EL2_nMASK ~(__HAFGRTR_EL2_RES0 | __HAFGRTR_EL2_MASK) > > > > +/* Because the sysreg file mixes R and W... */ > > +#define HFGRTR_EL2_RES0 HFGxTR_EL2_RES0 (0) > > +#define HFGWTR_EL2_RES0 (HFGRTR_EL2_RES0 | __HFGRTR_ONLY_MASK) > > __HFGRTR_ONLY_MASK is a hand-crafted bitmask. The only bit remaining > in HFGxTR_EL2 that is RES0 is bit 51. If that were to be used as an > HFGRTR-only bit without __HFGRTR_ONLY_MASK getting updated, then > aggregate_fgt() below would set its bit in hfgwtr_masks. Could this be > a problem if this happens and the polarity of this bit ends up being > negative, thereby setting the corresponding nmask bit? This could become a problem indeed. But the only fix for that is to kill the HFGxTR stupidity and describe all the bits as needed so that we stop assuming things. I'm half tempted to do that next. Thanks, M. -- Without deviation from the norm, progress is not possible.