[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <Y1mlJqKdFtlgG3jR@google.com>
Date: Wed, 26 Oct 2022 14:22:46 -0700
From: David Matlack <dmatlack@...gle.com>
To: Wei Wang <wei.w.wang@...el.com>
Cc: seanjc@...gle.com, pbonzini@...hat.com, vipinsh@...gle.com,
ajones@...tanamicro.com, eric.auger@...hat.com,
kvm@...r.kernel.org, linux-kernel@...r.kernel.org
Subject: Re: [PATCH v1 00/18] KVM selftests code consolidation and cleanup
On Mon, Oct 24, 2022 at 07:34:27PM +0800, Wei Wang wrote:
> This patch series intends to improve kvm selftests with better code
> consolidation using the helper functions to perform vcpu and thread
> related operations.
>
> In general, several aspects are improved:
> 1) The current users allocate an array of vcpu pointers to the vcpus that
> are added to a vm, and an array of vcpu threads. This isn't necessary
> as kvm_vm already maintains a list of added vcpus. This series changes
> the list of vcpus in the kvm_vm struct to a vcpu array for users to
> work with and removes each user's own allocation of such vcpu arrays.
> Aslo add the vcpu thread to the kvm_vcpu struct, so that users don't
> need to explicitly allocate a thread array to manage vcpu threads on
> their own.
> 2) Change the users to use the helper functions provided by this series
> with the following enhancements:
> - Many users working with pthread_create/join forgot to check if
> error on returning. The helper functions have handled thoses inside,
> so users don't need to handle them by themselves;
> - The vcpu threads created via the helper functions are named in
> "vcpu-##id" format. Naming the threads facilitates debugging,
> performance tuning, runtime pining etc;
> - helper functions named with "vm_vcpu_threads_" iterates over all the
> vcpus that have been added to the vm. Users don't need a explicit
> loop to go through the added cpus by themselves.
> 3) kvm_vcpu is used as the interface parameter to the vcpu thread's
> start routine, and the user specific data is made to be the private
> data in kvm_vcpu. This can simplify the user specific data structures,
> as kvm_vcpu has already included the required info for the thread, for
> example, in patch 13, the cpu_idx field from "struct vcpu_thread"
> is a duplicate of vcpu->id.
I haven't dug too much into the actual code yet, but I have some high
level feedback based on a quick look through the series:
- Use the format "KVM: selftests: <Decsription>" for the shortlog.
- Make the shortlog more specific. "vcpu related code consolidation" is
vague.
- Do not introduce bugs and then fix them in subsequent commits. This
breaks bisection. For example, kvm_page_table_test is broken at "KVM:
selftests/kvm_util: use vm->vcpus[] when create vm with vcpus" and
then fixed by "KVM: selftests/kvm_page_table_test: vcpu related code
consolidation".
- Try to limit each patch to one logical change. This is somewhat more
art than science, but the basic idea is to avoid changing too much at
once so that the code is easier to review and bisect. For example,
"KVM: selftests/perf_test_util: vcpu related code consolidation" has
a list of 6 different changes being made in the commit description.
This is a sure sign this commit should be broken up. The same applies
to many of the other patches. This will also make it easier to come
up with more specific shortlogs.
>
> The changes have been tested on an SPR server. Patch 15 and 16 haven't
> been tested due to the lack of an ARM environment currently.
>
> Wei Wang (18):
> KVM: selftests/kvm_util: use array of pointers to maintain vcpus in
> kvm_vm
> KVM: selftests/kvm_util: use vm->vcpus[] when create vm with vcpus
> KVM: selftests/kvm_util: helper functions for vcpus and threads
> KVM: selftests/kvm_page_table_test: vcpu related code consolidation
> KVM: selftests/hardware_disable_test: code consolidation and cleanup
> KVM: selftests/dirty_log_test: vcpu related code consolidation
> KVM: selftests/max_guest_memory_test: vcpu related code consolidation
> KVM: selftests/set_memory_region_test: vcpu related code consolidation
> KVM: selftests/steal_time: vcpu related code consolidation and cleanup
> KVM: selftests/tsc_scaling_sync: vcpu related code consolidation
> KVM: selftest/xapic_ipi_test: vcpu related code consolidation
> KVM: selftests/rseq_test: name the migration thread and some cleanup
> KVM: selftests/perf_test_util: vcpu related code consolidation
> KVM: selftest/memslot_perf_test: vcpu related code consolidation
> KVM: selftests/vgic_init: vcpu related code consolidation
> KVM: selftest/arch_timer: vcpu related code consolidation
> KVM: selftests: remove the *vcpu[] input from __vm_create_with_vcpus
> KVM: selftests/kvm_create_max_vcpus: check KVM_MAX_VCPUS
>
> .../selftests/kvm/aarch64/arch_timer.c | 42 ++--
> .../testing/selftests/kvm/aarch64/vgic_init.c | 35 ++-
> .../selftests/kvm/access_tracking_perf_test.c | 18 +-
> .../selftests/kvm/demand_paging_test.c | 9 +-
> .../selftests/kvm/dirty_log_perf_test.c | 11 +-
> tools/testing/selftests/kvm/dirty_log_test.c | 16 +-
> .../selftests/kvm/hardware_disable_test.c | 56 ++---
> .../testing/selftests/kvm/include/kvm_util.h | 24 ++
> .../selftests/kvm/include/kvm_util_base.h | 12 +-
> .../selftests/kvm/include/perf_test_util.h | 9 +-
> .../selftests/kvm/kvm_create_max_vcpus.c | 7 +
> .../selftests/kvm/kvm_page_table_test.c | 16 +-
> tools/testing/selftests/kvm/lib/kvm_util.c | 217 +++++++++++++++---
> .../selftests/kvm/lib/perf_test_util.c | 68 ++----
> .../selftests/kvm/lib/x86_64/perf_test_util.c | 11 +-
> tools/testing/selftests/kvm/lib/x86_64/vmx.c | 2 +-
> .../selftests/kvm/max_guest_memory_test.c | 53 ++---
> .../kvm/memslot_modification_stress_test.c | 9 +-
> .../testing/selftests/kvm/memslot_perf_test.c | 137 +++++------
> tools/testing/selftests/kvm/rseq_test.c | 10 +-
> .../selftests/kvm/set_memory_region_test.c | 16 +-
> tools/testing/selftests/kvm/steal_time.c | 15 +-
> .../selftests/kvm/x86_64/tsc_scaling_sync.c | 25 +-
> .../selftests/kvm/x86_64/xapic_ipi_test.c | 54 ++---
> 24 files changed, 476 insertions(+), 396 deletions(-)
>
> --
> 2.27.0
>
Powered by blists - more mailing lists