linux-kernel - Re: [PATCH v4 30/30] KVM: selftests: Add test to populate a VM with the max possible guest mem

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <63f4a488-87f1-097f-95d5-f85e46786740@redhat.com>
Date:   Tue, 8 Mar 2022 15:47:26 +0100
From:   Paolo Bonzini <pbonzini@...hat.com>
To:     linux-kernel@...r.kernel.org, kvm@...r.kernel.org,
        Sean Christopherson <sean.j.christopherson@...el.com>,
        Marc Zyngier <Marc.Zyngier@....com>,
        Christian Borntraeger <borntraeger@...ibm.com>
Subject: Re: [PATCH v4 30/30] KVM: selftests: Add test to populate a VM with
 the max possible guest mem

On 3/3/22 20:38, Paolo Bonzini wrote:
> From: Sean Christopherson<seanjc@...gle.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.

> +			TEST_ASSERT(nr_vcpus, "#DE");

srsly? :)

Paolo