linux-kernel - Re: [PATCH v5 5/7] KVM: selftests: Introduce a selftest to measure execution performance

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: Windows password security audit tool. GUI, reports in PDF.

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

Message-ID: <CADrL8HW-0i-ALX38af6MOrV-WoNfg0rWKCD87ZHddJ5eu2oYpw@mail.gmail.com>
Date: Mon, 28 Jul 2025 17:18:09 -0700
From: James Houghton <jthoughton@...gle.com>
To: Sean Christopherson <seanjc@...gle.com>
Cc: Paolo Bonzini <pbonzini@...hat.com>, Vipin Sharma <vipinsh@...gle.com>, 
	David Matlack <dmatlack@...gle.com>, kvm@...r.kernel.org, linux-kernel@...r.kernel.org
Subject: Re: [PATCH v5 5/7] KVM: selftests: Introduce a selftest to measure
 execution performance

On Wed, Jul 23, 2025 at 1:50 PM Sean Christopherson <seanjc@...gle.com> wrote:
>
> On Mon, Jul 07, 2025, James Houghton wrote:
> > From: David Matlack <dmatlack@...gle.com>
> >
> > Introduce a new selftest, execute_perf_test, that uses the
> > perf_test_util framework to measure the performance of executing code
> > within a VM. This test is similar to the other perf_test_util-based
> > tests in that it spins up a variable number of vCPUs and runs them
> > concurrently, accessing memory.
> >
> > In order to support execution, extend perf_test_util to populate guest
> > memory with return instructions rather than random garbage. This way
> > memory can be execute simply by calling it.
> >
> > Currently only x86_64 supports execution, but other architectures can be
> > easily added by providing their return code instruction.
> >
> > Signed-off-by: David Matlack <dmatlack@...gle.com>
> > Signed-off-by: James Houghton <jthoughton@...gle.com>
> > ---
> >  tools/testing/selftests/kvm/Makefile.kvm      |   1 +
> >  .../testing/selftests/kvm/execute_perf_test.c | 199 ++++++++++++++++++
>
> Honest question, is there really no way to dedup memstress tests?  This seems
> like an insane amount of code just to call memstress_set_execute().

The main pieces of this test come out to:
1. Parse arguments
2. Create a VM
3. Run a couple iterations of memory access
4. Run a few execution iterations
5. Destroy the VM

(1) is slightly difficult to de-duplicate, because the other tests
have more arguments, and so you'd have to look in two places for a
full argument list (in the source code at least).

(2+5) Creating and destroying a VM is already not much code, IMO.

(3+4) Running iterations of guest memory accesses is a pretty good
candidate for de-duplication.

The other memstress tests are:
- access_tracking_perf_test.c
- demand_paging_test.c
- dirty_log_perf_test.c
- memslot_modification_stress_test.c
- x86/dirty_log_page_splitting_test.c

Three of these tests use similar iteration logic (all but
memslot_modification_stress_test.c and demand_paging_test.c).

I could make memstress_start_vcpu_threads() take a pointer to the main
vCPU thread logic, put some iteration logic around that, and then
provide a "run_iteration" interface in memstress. The two tests that
don't really iterate multiple times can just iterate once.

I'm not really sure how much *better* that is, but I can at least give
it a go and see how it looks.

If you're happy with the nx hugepage test[1] in patch #7, feel free to
apply that one without waiting for this one.

[1]: https://lore.kernel.org/kvm/20250707224720.4016504-8-jthoughton@google.com/

>
> >  .../testing/selftests/kvm/include/memstress.h |   4 +
> >  tools/testing/selftests/kvm/lib/memstress.c   |  25 ++-
> >  4 files changed, 227 insertions(+), 2 deletions(-)
> >  create mode 100644 tools/testing/selftests/kvm/execute_perf_test.c
> >
> > diff --git a/tools/testing/selftests/kvm/Makefile.kvm b/tools/testing/selftests/kvm/Makefile.kvm
> > index 38b95998e1e6b..0dc435e944632 100644
> > --- a/tools/testing/selftests/kvm/Makefile.kvm
> > +++ b/tools/testing/selftests/kvm/Makefile.kvm
> > @@ -137,6 +137,7 @@ TEST_GEN_PROGS_x86 += x86/recalc_apic_map_test
> >  TEST_GEN_PROGS_x86 += access_tracking_perf_test
> >  TEST_GEN_PROGS_x86 += coalesced_io_test
> >  TEST_GEN_PROGS_x86 += dirty_log_perf_test
> > +TEST_GEN_PROGS_x86 += execute_perf_test
>
> How about call_ret_perf_test instead of execute_perf_test?  I like that "execute"
> aligns with "read" and "write", but as a test name it ends up being quite ambiguous.

call_ret_perf_test to me sounds quite x86-specific, and although the
test currently only supports x86, I think we might as well name it
something more generic in case it becomes useful to support other
architectures.