Re: [PATCH 02/20] KVM: selftests: Bump the minimum GPA for page tables to 0x200000

[Sean Christopherson <seanjc@google.com>]

+LoongArch folks (question below for you)

On Wed, Aug 26, 2026, sashiko-bot@kernel.org wrote:
> > diff --git a/tools/testing/selftests/kvm/include/kvm_util.h b/tools/testing/selftests/kvm/include/kvm_util.h
> > index 5a7a455b53875..70906a0d1003c 100644
> > --- a/tools/testing/selftests/kvm/include/kvm_util.h
> > +++ b/tools/testing/selftests/kvm/include/kvm_util.h
> > @@ -175,7 +175,7 @@ static inline struct userspace_mem_region *vm_get_mem_region(struct kvm_vm *vm,
> >  
> >  /* Minimum allocated guest virtual and physical addresses */
> >  #define KVM_UTIL_MIN_VADDR		0x2000
> > -#define KVM_GUEST_PAGE_TABLE_MIN_PADDR	0x180000
> > +#define KVM_GUEST_PAGE_TABLE_MIN_PADDR	0x200000
> 
> [Severity: High]
> Does bumping the minimum GPA to 0x200000 cause the guest page tables to overlap
> with the VGIC redistributor on ARM64?

This is definitely a Marc/Oliver question.  FWIW, I didn't see failures on arm64,
but I also have no idea if the hardware I was using supports the v3 tests, so
it's entirely possible this is a real and obvious problem.

> In tools/testing/selftests/kvm/arm64/vgic_init.c:subtest_v3_redist_regions(),
> the redistributor is hardcoded to be placed at the same address:
> 
>     addr = REDIST_REGION_ATTR_ADDR(2, 0x200000, 0, 0);
>     kvm_device_attr_set(v->gic_fd, KVM_DEV_ARM_VGIC_GRP_ADDR,
>                         KVM_VGIC_V3_ADDR_TYPE_REDIST_REGION, &addr);
> 
> Because KVM maps the redistributor over memory, wouldn't the hardware MMU's
> stage-1 page table walk attempt to read page table entries from an emulated IO
> region?
> 
> This seems like it would cause a stage-2 fault that KVM cannot handle for a
> stage-1 page table walk, leading to an infinite exception loop.
> 
> Additionally, does starting allocations at 0x200000 severely reduce the
> available memory in memslot 0?
> 
> In tools/testing/selftests/kvm/lib/kvm_util.c:vm_nr_pages_required(), memslot 0
> is sized to be just slightly larger than 2MB:
> 
>     nr_pages = 512;
>     
>     /* Account for the per-vCPU stacks on behalf of the test. */
>     nr_pages += nr_runnable_vcpus * DEFAULT_STACK_PGS;

Ugh, right, because this doesn't change the base of the memslot.

Why does LoongArch use 0x200000 instead of 0x180000 as the base?  I switched the
common macro purely because I thought it would be the path of least resistance,
but maybe "fixing" LoongArch to use KVM_GUEST_PAGE_TABLE_MIN_PADDR is easier?

> It seems like this leaves only a few pages for page tables. If a test has
> multiple vCPUs, wouldn't it exhaust this tiny pool and trigger the abort in
> tools/testing/selftests/kvm/lib/kvm_util.c:____vm_phy_pages_alloc()?
> 
>     enomem:
>         fprintf(stderr, "No guest physical page available, min_gpa: 0x%lx "
>                 "page_size: 0x%x memslot: %u\n",
>                 min_gpa, vm->page_size, memslot);
>         fputs("---- vm dump ----\n", stderr);
>         vm_dump(stderr, vm, 2);
>         abort();
> 
> >  
> >  #define DEFAULT_GUEST_STACK_VADDR_MIN	0xab6000
> >  #define DEFAULT_STACK_PGS		5
> 
> -- 
> Sashiko AI review · https://sashiko.dev/#/patchset/20260826230511.972824-1-seanjc@google.com?part=2