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

[Sean Christopherson <seanjc@google.com>]

On Thu, Aug 27, 2026, Bibo Mao wrote:
> On 2026/8/27 上午7:38, Sean Christopherson wrote:
> > +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 is no limitation on LoongArch with physical address, the common address
> 0x180000 is ok. Originally it is to add huge page on VM side in future, it
> seems that it is VA address macro KVM_UTIL_MIN_VADDR rather than PA address
> for page table for huge page purpose.

Nice!  In that case, I'll replace this with a patch to switch LoongArch to
KVM_GUEST_PAGE_TABLE_MIN_PADDR.

Thanks!