[PATCH] KVM: arm64: Fix handling of FEAT_GTG for unimplemented granule sizes

[PATCH] KVM: arm64: Fix handling of FEAT_GTG for unimplemented granule sizes

[Marc Zyngier]

Booting an EL2 guest on a system only supporting a subset of the
possible page sizes leads to interesting situations.

For example, on a system that only supports 4kB and 64kB, and is
booted with a 4kB kernel, we end-up advertising 16kB support at
stage-2, which is pretty weird.

That's because we consider that any S2 bigger than our base granule
is fair game, irrespective of what the HW actually supports.

Add new checks that will verify that this granule size is actually
supported before publishing it to the guest.

Fixes: e7ef6ed4583ea ("KVM: arm64: Enforce NV limits on a per-idregs basis")
Signed-off-by: Marc Zyngier <maz@kernel.org>
---
 arch/arm64/kvm/nested.c | 26 +++++++++++++++++++++++---
 1 file changed, 23 insertions(+), 3 deletions(-)

diff --git a/arch/arm64/kvm/nested.c b/arch/arm64/kvm/nested.c
index 5b191f4dc5668..dc1d26559bfa3 100644
--- a/arch/arm64/kvm/nested.c
+++ b/arch/arm64/kvm/nested.c
@@ -1402,6 +1402,21 @@ static void kvm_map_l1_vncr(struct kvm_vcpu *vcpu)
 	}
 }
 
+#define has_tgran_2(__r, __sz)						\
+	({								\
+		u64 _s1, _s2, _mmfr0 = __r;				\
+									\
+		_s2 = SYS_FIELD_GET(ID_AA64MMFR0_EL1,			\
+				    TGRAN##__sz##_2, _mmfr0);		\
+									\
+		_s1 = SYS_FIELD_GET(ID_AA64MMFR0_EL1,			\
+				    TGRAN##__sz, _mmfr0);		\
+									\
+		((_s2 != ID_AA64MMFR0_EL1_TGRAN##__sz##_2_NI &&		\
+		  _s2 != ID_AA64MMFR0_EL1_TGRAN##__sz##_2_TGRAN##__sz) || \
+		 (_s2 == ID_AA64MMFR0_EL1_TGRAN##__sz##_2_TGRAN##__sz && \
+		  _s1 != ID_AA64MMFR0_EL1_TGRAN##__sz##_NI));		\
+	})
 /*
  * Our emulated CPU doesn't support all the possible features. For the
  * sake of simplicity (and probably mental sanity), wipe out a number
@@ -1411,6 +1426,8 @@ static void kvm_map_l1_vncr(struct kvm_vcpu *vcpu)
  */
 u64 limit_nv_id_reg(struct kvm *kvm, u32 reg, u64 val)
 {
+	u64 orig_val = val;
+
 	switch (reg) {
 	case SYS_ID_AA64ISAR0_EL1:
 		/* Support everything but TME */
@@ -1480,13 +1497,16 @@ u64 limit_nv_id_reg(struct kvm *kvm, u32 reg, u64 val)
 		 */
 		switch (PAGE_SIZE) {
 		case SZ_4K:
-			val |= SYS_FIELD_PREP_ENUM(ID_AA64MMFR0_EL1, TGRAN4_2, IMP);
+			if (has_tgran_2(orig_val, 4))
+				val |= SYS_FIELD_PREP_ENUM(ID_AA64MMFR0_EL1, TGRAN4_2, IMP);
 			fallthrough;
 		case SZ_16K:
-			val |= SYS_FIELD_PREP_ENUM(ID_AA64MMFR0_EL1, TGRAN16_2, IMP);
+			if (has_tgran_2(orig_val, 16))
+				val |= SYS_FIELD_PREP_ENUM(ID_AA64MMFR0_EL1, TGRAN16_2, IMP);
 			fallthrough;
 		case SZ_64K:
-			val |= SYS_FIELD_PREP_ENUM(ID_AA64MMFR0_EL1, TGRAN64_2, IMP);
+			if (has_tgran_2(orig_val, 64))
+				val |= SYS_FIELD_PREP_ENUM(ID_AA64MMFR0_EL1, TGRAN64_2, IMP);
 			break;
 		}
 
-- 
2.39.2

Re: [PATCH] KVM: arm64: Fix handling of FEAT_GTG for unimplemented granule sizes

[Oliver Upton]

On Tue, Jul 01, 2025 at 03:22:25PM +0100, Marc Zyngier wrote:
> Booting an EL2 guest on a system only supporting a subset of the
> possible page sizes leads to interesting situations.
> 
> For example, on a system that only supports 4kB and 64kB, and is
> booted with a 4kB kernel, we end-up advertising 16kB support at
> stage-2, which is pretty weird.
> 
> That's because we consider that any S2 bigger than our base granule
> is fair game, irrespective of what the HW actually supports.

While this is ugly as hell, it is _technically_ OK though right? Since
we always shadow the stage-2 MMU we can emulate the otherwise
unsupported page size.

Now, mismatched granularity at S1 and S2 is a massive can of worms we
should not entertain :)

> Add new checks that will verify that this granule size is actually
> supported before publishing it to the guest.
> 
> Fixes: e7ef6ed4583ea ("KVM: arm64: Enforce NV limits on a per-idregs basis")
> Signed-off-by: Marc Zyngier <maz@kernel.org>

It'd be good to clarify the rationale a bit further in the changelog,
but full agreement on disallowing this sort of stupidity.

Reviewed-by: Oliver Upton <oliver.upton@linux.dev>

Thanks,
Oliver

Re: [PATCH] KVM: arm64: Fix handling of FEAT_GTG for unimplemented granule sizes

[Marc Zyngier]

On Wed, 02 Jul 2025 03:35:44 +0100,
Oliver Upton <oliver.upton@linux.dev> wrote:
> 
> On Tue, Jul 01, 2025 at 03:22:25PM +0100, Marc Zyngier wrote:
> > Booting an EL2 guest on a system only supporting a subset of the
> > possible page sizes leads to interesting situations.
> > 
> > For example, on a system that only supports 4kB and 64kB, and is
> > booted with a 4kB kernel, we end-up advertising 16kB support at
> > stage-2, which is pretty weird.
> > 
> > That's because we consider that any S2 bigger than our base granule
> > is fair game, irrespective of what the HW actually supports.
> 
> While this is ugly as hell, it is _technically_ OK though right? Since
> we always shadow the stage-2 MMU we can emulate the otherwise
> unsupported page size.
> 
> Now, mismatched granularity at S1 and S2 is a massive can of worms we
> should not entertain :)
> 
> > Add new checks that will verify that this granule size is actually
> > supported before publishing it to the guest.
> > 
> > Fixes: e7ef6ed4583ea ("KVM: arm64: Enforce NV limits on a per-idregs basis")
> > Signed-off-by: Marc Zyngier <maz@kernel.org>
> 
> It'd be good to clarify the rationale a bit further in the changelog,
> but full agreement on disallowing this sort of stupidity.

Indeed, I have now added some verbiage to that effect.

> Reviewed-by: Oliver Upton <oliver.upton@linux.dev>

Thanks!

	M.

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

Re: [PATCH] KVM: arm64: Fix handling of FEAT_GTG for unimplemented granule sizes

[Marc Zyngier]

On Tue, 01 Jul 2025 15:22:25 +0100, Marc Zyngier wrote:
> Booting an EL2 guest on a system only supporting a subset of the
> possible page sizes leads to interesting situations.
> 
> For example, on a system that only supports 4kB and 64kB, and is
> booted with a 4kB kernel, we end-up advertising 16kB support at
> stage-2, which is pretty weird.
> 
> [...]

Applied to fixes, thanks!

[1/1] KVM: arm64: Fix handling of FEAT_GTG for unimplemented granule sizes
      commit: 105485a182dc6ba32e55db46839af756c105afae

Cheers,

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