Third time's a charm.  Sorry for the spam.

Buried in the middle of this is a fix for the hardware_disable_test where
it can end up with a runtime of multiple minutes when running a preemptible
kernels on a large NUMA system.  Turns out my analysis/guess in v1 was wrong;
the problem isn't direct CPU contention, it's that letting the workers do any
amount of "real" work on any CPUs leads to pthread_create() slowdowns from
the perspective of the caller.

The vast, vast majority of the changes are adding kvm_xxx() syscall wrappers
so that tests don't need to manually assert that a syscall succeeds (the
hardware disable test had some ugly equivalents).

v3:
 - Key off _GNU_SOURCE, not __USE_GNU. [Sashiko]
 - Clear consumed CPUs from the allowed set. [Sashiko]
 - Assert that settings affinity attributes succeeds. [Sasiko]

v2:
 - https://lore.kernel.org/all/20260731170619.2620845-1-seanjc%40google.com
 - pause() the child after creating workers so as not to busy loop, and to
   maintain equivalent functionality. [Sashiko]
 - Don't bother pinning the parent of immediate child, and instead focus on
   affining workers to their CPUs asap.

v1: https://lore.kernel.org/all/20260730191908.2084803-1-seanjc@google.com


Sean Christopherson (12):
  KVM: selftests: Add a KVM syscall wrapper for sched_setaffinity()
  KVM: selftests: Set threads CPU affinity before doing work in hardware
    disable test
  KVM: selftests: Pre-set threads affinity in hardware disable test when
    possible
  KVM: selftests: Return the target CPU from pin_task_to_random_cpu()
  KVM: selftests: Extract picking of random CPU from cpu_set_t to
    separate API
  KVM: selftests: Affine threads to random CPUs in hardware disable test
  KVM: selftests: Drop unreachable, dead code from hardware disable test
  KVM: selftests: Add KVM syscall wrapper for pthread_create()
  KVM: selftests: Add KVM syscall wrappers for pthread_{cancel,join}()
  KVM: selftests: Add helper APIs to cancel+join pthreads
  KVM: selftests: Add KVM syscall wrappers for
    pthread_{g,s}etaffinity_np()
  KVM: selftests: Clean up global constants in hardware disable test

 tools/testing/selftests/kvm/arch_timer.c      |  18 +--
 tools/testing/selftests/kvm/arm64/vgic_irq.c  |  14 +--
 .../selftests/kvm/arm64/vgic_lpi_stress.c     |   8 +-
 tools/testing/selftests/kvm/dirty_log_test.c  |   4 +-
 .../selftests/kvm/hardware_disable_test.c     | 109 ++++++++----------
 .../selftests/kvm/include/kvm_syscalls.h      |  48 ++++++++
 .../testing/selftests/kvm/include/kvm_util.h  |  11 +-
 tools/testing/selftests/kvm/irq_test.c        |   4 +-
 tools/testing/selftests/kvm/irqfd_test.c      |   4 +-
 .../selftests/kvm/kvm_page_table_test.c       |   6 +-
 tools/testing/selftests/kvm/lib/kvm_util.c    |  10 +-
 tools/testing/selftests/kvm/lib/memstress.c   |   4 +-
 .../selftests/kvm/lib/userfaultfd_util.c      |   7 +-
 .../testing/selftests/kvm/memslot_perf_test.c |   4 +-
 tools/testing/selftests/kvm/mmu_stress_test.c |   4 +-
 .../selftests/kvm/pre_fault_memory_test.c     |   4 +-
 tools/testing/selftests/kvm/rseq_test.c       |  12 +-
 tools/testing/selftests/kvm/s390/memop.c      |   4 +-
 .../selftests/kvm/set_memory_region_test.c    |   6 +-
 tools/testing/selftests/kvm/steal_time.c      |   6 +-
 tools/testing/selftests/kvm/x86/hyperv_ipi.c  |  32 +----
 .../selftests/kvm/x86/hyperv_tlb_flush.c      |  30 +----
 .../kvm/x86/private_mem_conversions_test.c    |   4 +-
 .../kvm/x86/private_mem_kvm_exits_test.c      |   7 +-
 .../selftests/kvm/x86/recalc_apic_map_test.c  |   5 +-
 .../selftests/kvm/x86/sev_migrate_tests.c     |   4 +-
 .../selftests/kvm/x86/sync_regs_test.c        |   5 +-
 .../selftests/kvm/x86/tsc_scaling_sync.c      |   4 +-
 .../selftests/kvm/x86/xapic_ipi_test.c        |  31 +----
 .../selftests/kvm/x86/xen_shinfo_test.c       |  10 +-
 30 files changed, 187 insertions(+), 232 deletions(-)


base-commit: 3c7d7f908d574277a845423ec32250a8d8df44c8
-- 
2.55.0.508.g3f0d502094-goog

On Fri, 31 Jul 2026 12:56:00 -0700, Sean Christopherson wrote:
> Third time's a charm.  Sorry for the spam.
> 
> Buried in the middle of this is a fix for the hardware_disable_test where
> it can end up with a runtime of multiple minutes when running a preemptible
> kernels on a large NUMA system.  Turns out my analysis/guess in v1 was wrong;
> the problem isn't direct CPU contention, it's that letting the workers do any
> amount of "real" work on any CPUs leads to pthread_create() slowdowns from
> the perspective of the caller.
> 
> [...]

Applied to kvm-x86 selftests2, thanks!

[01/12] KVM: selftests: Add a KVM syscall wrapper for sched_setaffinity()
        https://github.com/kvm-x86/linux/commit/f766bf3d0ac8
[02/12] KVM: selftests: Set threads CPU affinity before doing work in hardware disable test
        https://github.com/kvm-x86/linux/commit/2887da61c42d
[03/12] KVM: selftests: Pre-set threads affinity in hardware disable test when possible
        https://github.com/kvm-x86/linux/commit/496779b54943
[04/12] KVM: selftests: Return the target CPU from pin_task_to_random_cpu()
        https://github.com/kvm-x86/linux/commit/8de0e85f654e
[05/12] KVM: selftests: Extract picking of random CPU from cpu_set_t to separate API
        https://github.com/kvm-x86/linux/commit/d58cc7bbc5a0
[06/12] KVM: selftests: Affine threads to random CPUs in hardware disable test
        https://github.com/kvm-x86/linux/commit/563416ea9ae4
[07/12] KVM: selftests: Drop unreachable, dead code from hardware disable test
        https://github.com/kvm-x86/linux/commit/bb0e7d84c4be
[08/12] KVM: selftests: Add KVM syscall wrapper for pthread_create()
        https://github.com/kvm-x86/linux/commit/5171573ce7cb
[09/12] KVM: selftests: Add KVM syscall wrappers for pthread_{cancel,join}()
        https://github.com/kvm-x86/linux/commit/bc9143135bf3
[10/12] KVM: selftests: Add helper APIs to cancel+join pthreads
        https://github.com/kvm-x86/linux/commit/939b20e5f35e
[11/12] KVM: selftests: Add KVM syscall wrappers for pthread_{g,s}etaffinity_np()
        https://github.com/kvm-x86/linux/commit/83b5065f3e1c
[12/12] KVM: selftests: Clean up global constants in hardware disable test
        https://github.com/kvm-x86/linux/commit/1039496ae75d

--
https://github.com/kvm-x86/linux/tree/next

On Fri, Jul 31, 2026 at 12:56 PM Sean Christopherson <seanjc@google.com> wrote:
>
> Third time's a charm.  Sorry for the spam.
>
> Buried in the middle of this is a fix for the hardware_disable_test where
> it can end up with a runtime of multiple minutes when running a preemptible
> kernels on a large NUMA system.  Turns out my analysis/guess in v1 was wrong;
> the problem isn't direct CPU contention, it's that letting the workers do any
> amount of "real" work on any CPUs leads to pthread_create() slowdowns from
> the perspective of the caller.

How long does the test take to run with this series?

On Fri, Jul 31, 2026, Yosry Ahmed wrote:
> On Fri, Jul 31, 2026 at 12:56 PM Sean Christopherson <seanjc@google.com> wrote:
> >
> > Third time's a charm.  Sorry for the spam.
> >
> > Buried in the middle of this is a fix for the hardware_disable_test where
> > it can end up with a runtime of multiple minutes when running a preemptible
> > kernels on a large NUMA system.  Turns out my analysis/guess in v1 was wrong;
> > the problem isn't direct CPU contention, it's that letting the workers do any
> > amount of "real" work on any CPUs leads to pthread_create() slowdowns from
> > the perspective of the caller.
> 
> How long does the test take to run with this series?

Less than 5 seconds if nothing else is running.  ~12 seconds if I run it
concurrently with mmu_stress_test using default settings, and ~25 seconds if I
run it on an overloaded system (naively running all selftests in parallel).

On Fri, Jul 31, 2026 at 2:41 PM Sean Christopherson <seanjc@google.com> wrote:
>
> On Fri, Jul 31, 2026, Yosry Ahmed wrote:
> > On Fri, Jul 31, 2026 at 12:56 PM Sean Christopherson <seanjc@google.com> wrote:
> > >
> > > Third time's a charm.  Sorry for the spam.
> > >
> > > Buried in the middle of this is a fix for the hardware_disable_test where
> > > it can end up with a runtime of multiple minutes when running a preemptible
> > > kernels on a large NUMA system.  Turns out my analysis/guess in v1 was wrong;
> > > the problem isn't direct CPU contention, it's that letting the workers do any
> > > amount of "real" work on any CPUs leads to pthread_create() slowdowns from
> > > the perspective of the caller.
> >
> > How long does the test take to run with this series?
>
> Less than 5 seconds if nothing else is running.  ~12 seconds if I run it
> concurrently with mmu_stress_test using default settings, and ~25 seconds if I
> run it on an overloaded system (naively running all selftests in parallel).

Cool, I will stop skipping it after this series lands then :)