Messages in this thread | | | Date | Tue, 8 Mar 2022 16:36:31 +0100 | Subject | Re: [PATCH v4 30/30] KVM: selftests: Add test to populate a VM with the max possible guest mem | From | Christian Borntraeger <> |
| |
Am 08.03.22 um 15:47 schrieb Paolo Bonzini: > On 3/3/22 20:38, Paolo Bonzini wrote: >> From: Sean Christopherson<seanjc@google.com> >> >> Add a selftest that enables populating a VM with the maximum amount of >> guest memory allowed by the underlying architecture. Abuse KVM's >> memslots by mapping a single host memory region into multiple memslots so >> that the selftest doesn't require a system with terabytes of RAM. >> >> Default to 512gb of guest memory, which isn't all that interesting, but >> should work on all MMUs and doesn't take an exorbitant amount of memory >> or time. E.g. testing with ~64tb of guest memory takes the better part >> of an hour, and requires 200gb of memory for KVM's page tables when using >> 4kb pages. > > I couldn't quite run this on a laptop, so I'll tune it down to 128gb and 3/4 of the available CPUs. > >> To inflicit maximum abuse on KVM' MMU, default to 4kb pages (or whatever >> the not-hugepage size is) in the backing store (memfd). Use memfd for >> the host backing store to ensure that hugepages are guaranteed when >> requested, and to give the user explicit control of the size of hugepage >> being tested. >> >> By default, spin up as many vCPUs as there are available to the selftest, >> and distribute the work of dirtying each 4kb chunk of memory across all >> vCPUs. Dirtying guest memory forces KVM to populate its page tables, and >> also forces KVM to write back accessed/dirty information to struct page >> when the guest memory is freed. >> >> On x86, perform two passes with a MMU context reset between each pass to >> coerce KVM into dropping all references to the MMU root, e.g. to emulate >> a vCPU dropping the last reference. Perform both passes and all >> rendezvous on all architectures in the hope that arm64 and s390x can gain >> similar shenanigans in the future. > > Did you actually test aarch64 (not even asking about s390 :))? For now let's only add it for x86.
I do get spurious # selftests: kvm: max_guest_memory_test # ==== Test Assertion Failure ==== # lib/kvm_util.c:883: !ret # pid=575178 tid=575178 errno=22 - Invalid argument # 1 0x000000000100385f: vm_set_user_memory_region at kvm_util.c:883 # 2 0x0000000001001ee1: main at max_guest_memory_test.c:242 # 3 0x000003ffa1033731: ?? ??:0 # 4 0x000003ffa103380d: ?? ??:0 # 5 0x0000000001002389: _start at ??:? # KVM_SET_USER_MEMORY_REGION failed, errno = 22 (Invalid argument) not ok 9 selftests: kvm: max_guest_memory_test # exit=254
as the userspace address must be 1MB-aligned but the mmap is not (due to aslr).
There are probably more issues, so it certainly is ok to skip s390 for now. > >> + TEST_ASSERT(nr_vcpus, "#DE"); > > srsly? :) > > Paolo >
| |