[PATCH 0/1] KVM: arm64: Fix hyp VA size between layout and MMU

[PATCH 0/1] KVM: arm64: Fix hyp VA size between layout and MMU

[Petteri Kangaslampi]

All,

In the KVM initialization code, kvm_mmu_init() and
kvm_compute_layout() use different logic when determining the
hypervisor's virtual address space size. Specifically, the MMU code
uses the larger of vabits_actual (the kernel's VA size) and
IDMAP_VA_BITS (48 bits), while the VA layout code just uses the
kernel's VA size.

This means that if the kernel is configured with a VA size of less
than 48 bits (like happens in our environment), the assumptions used
to calculate hyp_physvirt_offset and the code that determines VA
ranges to use for mappings in hyp/nvhe/mm.c get out of sync, which can
results in mapping failures.

The immediate fix is pretty obvious and attached here. This is against
6.12 but I don't think this code has changed recently. I think longer
term refactoring knowledge of the hypervisor's address space into one
place might be helpful; currently it is a bit spread out.

Petteri Kangaslampi (1):
  KVM: arm64: Fix hyp VA size between layout and MMU

 arch/arm64/kvm/va_layout.c | 17 ++++++++++++-----
 1 file changed, 12 insertions(+), 5 deletions(-)

-- 
2.52.0.351.gbe84eed79e-goog

[PATCH 1/1] KVM: arm64: Fix hyp VA size between layout and MMU

[Petteri Kangaslampi]

Use a consistent hypervisor VA size between memory layout and MMU
initialization logic when the kernel is configured for less than
IDMAP_VA_BITS of VA space.

Signed-off-by: Petteri Kangaslampi <pekangas@google.com>
---
 arch/arm64/kvm/va_layout.c | 17 ++++++++++++-----
 1 file changed, 12 insertions(+), 5 deletions(-)

diff --git a/arch/arm64/kvm/va_layout.c b/arch/arm64/kvm/va_layout.c
index f6ca0193a96f..76cdd62550e1 100644
--- a/arch/arm64/kvm/va_layout.c
+++ b/arch/arm64/kvm/va_layout.c
@@ -49,7 +49,7 @@ static void init_hyp_physvirt_offset(void)
 
 /*
  * We want to generate a hyp VA with the following format (with V ==
- * vabits_actual):
+ * hypervisor VA bits):
  *
  *  63 ... V |     V-1    | V-2 .. tag_lsb | tag_lsb - 1 .. 0
  *  ---------------------------------------------------------
@@ -62,10 +62,17 @@ __init void kvm_compute_layout(void)
 {
 	phys_addr_t idmap_addr = __pa_symbol(__hyp_idmap_text_start);
 	u64 hyp_va_msb;
+	u32 hyp_va_bits;
+
+	/*
+	 * We use the bigger of IDMAP_VA_BITS and kernel VA size as the
+	 * hypervisor VA address space size. See mmu.c.
+	 */
+	hyp_va_bits = max(IDMAP_VA_BITS, vabits_actual);
 
 	/* Where is my RAM region? */
-	hyp_va_msb  = idmap_addr & BIT(vabits_actual - 1);
-	hyp_va_msb ^= BIT(vabits_actual - 1);
+	hyp_va_msb  = idmap_addr & BIT(hyp_va_bits - 1);
+	hyp_va_msb ^= BIT(hyp_va_bits - 1);
 
 	tag_lsb = fls64((u64)phys_to_virt(memblock_start_of_DRAM()) ^
 			(u64)(high_memory - 1));
@@ -73,9 +80,9 @@ __init void kvm_compute_layout(void)
 	va_mask = GENMASK_ULL(tag_lsb - 1, 0);
 	tag_val = hyp_va_msb;
 
-	if (IS_ENABLED(CONFIG_RANDOMIZE_BASE) && tag_lsb != (vabits_actual - 1)) {
+	if (IS_ENABLED(CONFIG_RANDOMIZE_BASE) && tag_lsb != (hyp_va_bits - 1)) {
 		/* We have some free bits to insert a random tag. */
-		tag_val |= get_random_long() & GENMASK_ULL(vabits_actual - 2, tag_lsb);
+		tag_val |= get_random_long() & GENMASK_ULL(hyp_va_bits - 2, tag_lsb);
 	}
 	tag_val >>= tag_lsb;
 
-- 
2.52.0.351.gbe84eed79e-goog

Re: [PATCH 0/1] KVM: arm64: Fix hyp VA size between layout and MMU

[Marc Zyngier]

On Tue, 23 Dec 2025 19:34:39 +0000,
Petteri Kangaslampi <pekangas@google.com> wrote:
> 
> All,
> 
> In the KVM initialization code, kvm_mmu_init() and
> kvm_compute_layout() use different logic when determining the
> hypervisor's virtual address space size. Specifically, the MMU code
> uses the larger of vabits_actual (the kernel's VA size) and
> IDMAP_VA_BITS (48 bits), while the VA layout code just uses the
> kernel's VA size.
> 
> This means that if the kernel is configured with a VA size of less
> than 48 bits (like happens in our environment), the assumptions used
> to calculate hyp_physvirt_offset and the code that determines VA
> ranges to use for mappings in hyp/nvhe/mm.c get out of sync, which can
> results in mapping failures.
> 
> The immediate fix is pretty obvious and attached here. This is against
> 6.12 but I don't think this code has changed recently. I think longer
> term refactoring knowledge of the hypervisor's address space into one
> place might be helpful; currently it is a bit spread out.

I'm sorry, but posting a patch against a kernel that is over a year
old doesn't help. It may apply, but it doesn't mean it works. Please
post a tested patch against the latest released kernel, or even
better, the latest -rc.

Thanks,

	M.

-- 
Jazz isn't dead. It just smells funny.

Re: [PATCH 1/1] KVM: arm64: Fix hyp VA size between layout and MMU

[Marc Zyngier]

On Tue, 23 Dec 2025 19:34:40 +0000,
Petteri Kangaslampi <pekangas@google.com> wrote:
> 
> Use a consistent hypervisor VA size between memory layout and MMU
> initialization logic when the kernel is configured for less than
> IDMAP_VA_BITS of VA space.
>
> Signed-off-by: Petteri Kangaslampi <pekangas@google.com>
> ---
>  arch/arm64/kvm/va_layout.c | 17 ++++++++++++-----
>  1 file changed, 12 insertions(+), 5 deletions(-)
> 
> diff --git a/arch/arm64/kvm/va_layout.c b/arch/arm64/kvm/va_layout.c
> index f6ca0193a96f..76cdd62550e1 100644
> --- a/arch/arm64/kvm/va_layout.c
> +++ b/arch/arm64/kvm/va_layout.c
> @@ -49,7 +49,7 @@ static void init_hyp_physvirt_offset(void)
>  
>  /*
>   * We want to generate a hyp VA with the following format (with V ==
> - * vabits_actual):
> + * hypervisor VA bits):
>   *
>   *  63 ... V |     V-1    | V-2 .. tag_lsb | tag_lsb - 1 .. 0
>   *  ---------------------------------------------------------
> @@ -62,10 +62,17 @@ __init void kvm_compute_layout(void)
>  {
>  	phys_addr_t idmap_addr = __pa_symbol(__hyp_idmap_text_start);
>  	u64 hyp_va_msb;
> +	u32 hyp_va_bits;
> +
> +	/*
> +	 * We use the bigger of IDMAP_VA_BITS and kernel VA size as the
> +	 * hypervisor VA address space size. See mmu.c.
> +	 */
> +	hyp_va_bits = max(IDMAP_VA_BITS, vabits_actual);

Instead of duplicating the logic from kvm_mmu_init(), I'd rather you
make sure there is a single place where the EL2 VA width is computed,
and use that consistently all over the place.

Since you were complaining about the spread of the VA layout handling,
starting with this sort of consolidation seems like a decent starting
point.

Thanks,

	M.

-- 
Jazz isn't dead. It just smells funny.