Received-SPF: pass (google.com: domain of linux-kernel+bounces-76703-linux.lists.archive=gmail.com@vger.kernel.org designates 2604:1380:45e3:2400::1 as permitted sender) client-ip=2604:1380:45e3:2400::1;
Date: Thu, 22 Feb 2024 14:31:38 +0000
Message-ID: <87frxka7ud.wl-maz@kernel.org>
From: Marc Zyngier <maz@kernel.org>
To: Paolo Bonzini <pbonzini@redhat.com>,
    Oliver Upton <oliver.upton@linux.dev>
Cc: Stephen Rothwell <sfr@canb.auug.org.au>,
	Joey Gouly <joey.gouly@arm.com>,
	Christoffer Dall <cdall@cs.columbia.edu>,
	KVM <kvm@vger.kernel.org>,
	Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
	Linux Next Mailing List <linux-next@vger.kernel.org>
Subject: Re: linux-next: build failure after merge of the kvm-arm tree
In-Reply-To: <b9d9a871-ba64-4c13-a186-0c60adc8d245@redhat.com>
References: <20240222220349.1889c728@canb.auug.org.au>
	<20240222111129.GA946362@e124191.cambridge.arm.com>
	<20240222224041.782761fd@canb.auug.org.au>
	<b9d9a871-ba64-4c13-a186-0c60adc8d245@redhat.com>
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/28.2
 (x86_64-pc-linux-gnu) MULE/6.0 (HANACHIRUSATO)
Precedence: bulk
MIME-Version: 1.0 (generated by SEMI-EPG 1.14.7 - "Harue")
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: quoted-printable

On Thu, 22 Feb 2024 13:11:59 +0000,
Paolo Bonzini <pbonzini@redhat.com> wrote:
>=20
> On 2/22/24 12:40, Stephen Rothwell wrote:
> >> This fails because https://git.kernel.org/pub/scm/linux/kernel/git/arm=
64/linux.git/commit/?id=3Dfdd867fe9b32
> >> added new fields to that register (ID_AA64DFR1_EL1)
> >>=20
> >> and commit b80b701d5a6 ("KVM: arm64: Snapshot all non-zero RES0/RES1 s=
ysreg fields for later checking")
> >> took a snapshot of the fields, so the RES0 (reserved 0) bits don't mat=
ch anymore.
> >>=20
> >> Not sure how to resolve it in the git branches though.
> >=20
> > Thanks.  I will apply this patch to the merge of the kvm-arm tree from
> > tomorrow (and at the end of today's tree).
>=20
> Marc, Oliver, can you get a topic branch from Catalin and friends for
> this sysreg patch, and apply the fixup directly to the kvm-arm branch
> in the merge commit?
>=20
> Not _necessary_, as I can always ask Linus to do the fixup, but
> generally he prefers to have this sorted out by the maintainers if it
> is detected by linux-next.

I think that's not the correct thing to do at this time. I should have
timed the introduction of these checks a bit later, after the merge
window.

But more to the point, the proposed patch is also not the best thing
to merge, because it hides that there is a discrepancy between what
the architecture describes, and what KVM knows. I really want to know
about it, or it will be yet another bug that we wont detect easily.
Specially for ID_AA64DFR*_EL1 which are a bloody mine-field.

So I'd rather we make the check optional, and we'll play catch up for
a bit longer. Something like the patch below.

Oliver, do you mind queuing this ASAP (also pushed out to my dev
branch)?

Thanks,

	M.

=46rom 85d861a6ca055c7681c826c580e7c90d74c26ac5 Mon Sep 17 00:00:00 2001
From: Marc Zyngier <maz@kernel.org>
Date: Thu, 22 Feb 2024 14:12:09 +0000
Subject: [PATCH] KVM: arm64: Make build-time check of RES0/RES1 bits option=
al

In order to ease the transition towards a state of absolute
paranoia where all RES0/RES1 bits gets checked against what
KVM know of them, make the checks optional and garded by a
config symbol (CONFIG_KVM_ARM64_RES_BITS_PARANOIA) default to n.

Signed-off-by: Marc Zyngier <maz@kernel.org>
---
 arch/arm64/kvm/Kconfig          | 11 +++++++++++
 arch/arm64/kvm/check-res-bits.h |  4 ++++
 2 files changed, 15 insertions(+)

diff --git a/arch/arm64/kvm/Kconfig b/arch/arm64/kvm/Kconfig
index 5c2a672c06a8..fa9389270cfe 100644
--- a/arch/arm64/kvm/Kconfig
+++ b/arch/arm64/kvm/Kconfig
@@ -67,4 +67,15 @@ config PROTECTED_NVHE_STACKTRACE
=20
 	  If unsure, or not using protected nVHE (pKVM), say N.
=20
+config KVM_ARM64_RES_BITS_PARANOIA
+	bool "Build-time check of RES0/RES1 bits"
+	depends on KVM
+	default n
+	help
+	  Say Y here to validate that KVM's knowledge of most system
+	  registers' RES0/RES1 bits matches when the rest of the kernel
+	  defines. Expect the build to fail badly if you enable this.
+
+	  Just say N.
+
 endif # VIRTUALIZATION
diff --git a/arch/arm64/kvm/check-res-bits.h b/arch/arm64/kvm/check-res-bit=
s.h
index 967b5d171d53..2d98e60efc3c 100644
--- a/arch/arm64/kvm/check-res-bits.h
+++ b/arch/arm64/kvm/check-res-bits.h
@@ -21,6 +21,8 @@
  */
 static inline void check_res_bits(void)
 {
+#ifdef CONFIG_KVM_ARM64_RES_BITS_PARANOIA
+
 	BUILD_BUG_ON(OSDTRRX_EL1_RES0		!=3D (GENMASK_ULL(63, 32)));
 	BUILD_BUG_ON(MDCCINT_EL1_RES0		!=3D (GENMASK_ULL(63, 31) | GENMASK_ULL(28=
, 0)));
 	BUILD_BUG_ON(MDSCR_EL1_RES0		!=3D (GENMASK_ULL(63, 36) | GENMASK_ULL(28, =
28) | GENMASK_ULL(25, 24) | GENMASK_ULL(20, 20) | GENMASK_ULL(18, 16) | GEN=
MASK_ULL(11, 7) | GENMASK_ULL(5, 1)));
@@ -118,4 +120,6 @@ static inline void check_res_bits(void)
 	BUILD_BUG_ON(TRBMAR_EL1_RES0		!=3D (GENMASK_ULL(63, 12)));
 	BUILD_BUG_ON(TRBTRG_EL1_RES0		!=3D (GENMASK_ULL(63, 32)));
 	BUILD_BUG_ON(TRBIDR_EL1_RES0		!=3D (GENMASK_ULL(63, 12) | GENMASK_ULL(7, =
6)));
+
+#endif
 }
--=20
2.39.2


--=20
Without deviation from the norm, progress is not possible.