On Sat, May 30, 2026, Josh Hilke wrote:
> David Matlack (12):
> KVM: selftests: Build and link selftests/vfio/lib into KVM selftests
> KVM: selftests: Add /proc/interrupts parsing helpers for IRQ test
> KVM: selftests: Add guest read/write macros
> KVM: selftests: Add IRQ injection test
> KVM: selftests: Verify IRQ bypass works in IRQ test
> KVM: selftests: Verify interrupts are received when IRQ affinity
> changes in IRQ test
> KVM: selftests: Verify IRQs wake up halted vCPUs in IRQ test
> KVM: selftests: Verify interrupts are received after modifying IRQ
> routes in IRQ test
> KVM: selftests: Make number of IRQs configurable in IRQ test
> KVM: selftests: Verify non-postable IRQ remapping in IRQ test
> KVM: selftests: Make number of vCPUs configurable in IRQ test
> KVM: selftests: Add xAPIC support in IRQ test
>
> Josh Hilke (7):
> KVM: selftests: Rename guest_rng to kvm_rng
> KVM: selftests: Add helper to generate random u64 in range [min,max]
> KVM: selftests: Add kvm_gettid() wrapper and convert users
> KVM: selftests: Add kvm_sched_getaffinity() wrapper and convert users
> KVM: selftests: Add pin_task_to_random_cpu() helper function
> KVM: selftests: Verify vCPU migration during IRQ delivery in IRQ test
> KVM: selftests: Print vCPU affinity on timeout during IRQ test
>
> tools/testing/selftests/kvm/Makefile.kvm | 8 +-
> tools/testing/selftests/kvm/arch_timer.c | 2 +-
> .../kvm/arm64/arch_timer_edge_cases.c | 2 +-
> .../selftests/kvm/demand_paging_test.c | 2 +-
> .../selftests/kvm/dirty_log_perf_test.c | 4 +-
> tools/testing/selftests/kvm/dirty_log_test.c | 8 +-
> .../selftests/kvm/include/kvm_syscalls.h | 6 +
> .../testing/selftests/kvm/include/kvm_util.h | 13 +
> .../testing/selftests/kvm/include/proc_util.h | 28 ++
> .../testing/selftests/kvm/include/test_util.h | 25 +-
> .../selftests/kvm/include/x86/kvm_util_arch.h | 4 +-
> tools/testing/selftests/kvm/irq_test.c | 370 ++++++++++++++++++
> tools/testing/selftests/kvm/lib/assert.c | 8 +-
> tools/testing/selftests/kvm/lib/kvm_util.c | 95 ++++-
> tools/testing/selftests/kvm/lib/memstress.c | 8 +-
> tools/testing/selftests/kvm/lib/proc_util.c | 62 +++
> tools/testing/selftests/kvm/lib/test_util.c | 27 +-
> tools/testing/selftests/kvm/mmu_stress_test.c | 15 +-
> tools/testing/selftests/kvm/rseq_test.c | 6 +-
> tools/testing/selftests/kvm/steal_time.c | 22 +-
> 20 files changed, 635 insertions(+), 80 deletions(-)
> create mode 100644 tools/testing/selftests/kvm/include/proc_util.h
> create mode 100644 tools/testing/selftests/kvm/irq_test.c
> create mode 100644 tools/testing/selftests/kvm/lib/proc_util.c
>
> --
Please read through Documentation/process/maintainer-kvm-x86.rst. This isn't
strictly scoped to KVM x86, but at the same time it's pretty obvious who is going
to be applying this series.
Specifically:
Git Base
~~~~~~~~
If you are using git version 2.9.0 or later (Googlers, this is all of you!),
use ``git format-patch`` with the ``--base`` flag to automatically include the
base tree information in the generated patches.
Note, ``--base=auto`` works as expected if and only if a branch's upstream is
set to the base topic branch, e.g. it will do the wrong thing if your upstream
is set to your personal repository for backup purposes. An alternative "auto"
solution is to derive the names of your development branches based on their
KVM x86 topic, and feed that into ``--base``. E.g. ``x86/pmu/my_branch_name``,
and then write a small wrapper to extract ``pmu`` from the current branch name
to yield ``--base=x/pmu``, where ``x`` is whatever name your repository uses to
track the KVM x86 remote.
and to a lesser extent:
Base Tree/Branch
~~~~~~~~~~~~~~~~
Fixes that target the current release, a.k.a. mainline, should be based on
``git://git.kernel.org/pub/scm/virt/kvm/kvm.git master``. Note, fixes do not
automatically warrant inclusion in the current release. There is no singular
rule, but typically only fixes for bugs that are urgent, critical, and/or were
introduced in the current release should target the current release.
Everything else should be based on ``kvm-x86/next``, i.e. there is no need to
select a specific topic branch as the base. If there are conflicts and/or
dependencies across topic branches, it is the maintainer's job to sort them
out.
The only exception to using ``kvm-x86/next`` as the base is if a patch/series
is a multi-arch series, i.e. has non-trivial modifications to common KVM code
and/or has more than superficial changes to other architectures' code. Multi-
arch patch/series should instead be based on a common, stable point in KVM's
history, e.g. the release candidate upon which ``kvm-x86 next`` is based. If
you're unsure whether a patch/series is truly multi-arch, err on the side of
caution and treat it as multi-arch, i.e. use a common base.
Through random guessing, I discovered that this appears to be based on 7.0.
(a) I shouldn't have to guess. (b) that's simply too old of a base, e.g. this
doesn't even apply clean only 7.1-rc1.
While there's room for interpretation in the "Base Tree/Branch" section, IMO
using any base older than 7.1-rc2 is blatantly wrong. Any of 7.1-rc2+, kvm/next,
or kvm-x86/next would be acceptable (though fairly literal reading of the docs
would say "don't use kvm-x86/next").
> 2.54.0.929.g9b7fa37559-goog
>