lkml.org 
[lkml]   [2022]   [Mar]   [8]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
SubjectRe: [PATCH v4 30/30] KVM: selftests: Add test to populate a VM with the max possible guest mem
From


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
>

\
 
 \ /
  Last update: 2022-03-08 16:38    [W:0.127 / U:0.664 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site