[0/4] Use TAP in some more x86 KVM selftests

Here's a follow-up from my RFC series last year:

 https://lore.kernel.org/lkml/20221004093131.40392-1-thuth@redhat.com/T/

Basic idea of this series is now to use the kselftest_harness.h
framework to get TAP output in the tests, so that it is easier
for the user to see what is going on, and e.g. to be able to
detect whether a certain test is part of the test binary or not
(which is useful when tests get extended in the course of time).

Thomas Huth (4):
  KVM: selftests: Rename the ASSERT_EQ macro
  KVM: selftests: x86: Use TAP interface in the sync_regs test
  KVM: selftests: x86: Use TAP interface in the fix_hypercall test
  KVM: selftests: x86: Use TAP interface in the userspace_msr_exit test

 .../selftests/kvm/aarch64/aarch32_id_regs.c   |   8 +-
 .../selftests/kvm/aarch64/page_fault_test.c   |  10 +-
 .../testing/selftests/kvm/include/test_util.h |   4 +-
 tools/testing/selftests/kvm/lib/kvm_util.c    |   2 +-
 .../selftests/kvm/max_guest_memory_test.c     |   2 +-
 tools/testing/selftests/kvm/s390x/cmma_test.c |  62 +++++-----
 tools/testing/selftests/kvm/s390x/memop.c     |   6 +-
 tools/testing/selftests/kvm/s390x/tprot.c     |   4 +-
 .../x86_64/dirty_log_page_splitting_test.c    |  18 +--
 .../x86_64/exit_on_emulation_failure_test.c   |   2 +-
 .../selftests/kvm/x86_64/fix_hypercall_test.c |  16 ++-
 .../kvm/x86_64/nested_exceptions_test.c       |  12 +-
 .../kvm/x86_64/recalc_apic_map_test.c         |   6 +-
 .../selftests/kvm/x86_64/sync_regs_test.c     | 113 +++++++++++++++---
 .../selftests/kvm/x86_64/tsc_msrs_test.c      |  32 ++---
 .../kvm/x86_64/userspace_msr_exit_test.c      |  19 +--
 .../vmx_exception_with_invalid_guest_state.c  |   2 +-
 .../selftests/kvm/x86_64/vmx_pmu_caps_test.c  |   3 +-
 .../selftests/kvm/x86_64/xapic_state_test.c   |   8 +-
 .../selftests/kvm/x86_64/xen_vmcall_test.c    |  20 ++--
 20 files changed, 218 insertions(+), 131 deletions(-)

On Wed, 12 Jul 2023 09:59:06 +0200, Thomas Huth wrote:
> Here's a follow-up from my RFC series last year:
> 
>  https://lore.kernel.org/lkml/20221004093131.40392-1-thuth@redhat.com/T/
> 
> Basic idea of this series is now to use the kselftest_harness.h
> framework to get TAP output in the tests, so that it is easier
> for the user to see what is going on, and e.g. to be able to
> detect whether a certain test is part of the test binary or not
> (which is useful when tests get extended in the course of time).
> 
> [...]

Applied patch 1 to kvm-x86 selftests, thanks!

[1/4] KVM: selftests: Rename the ASSERT_EQ macro
      https://github.com/kvm-x86/linux/commit/6d85f51a1f08

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

On 02/08/2023 23.31, Sean Christopherson wrote:
> On Wed, Aug 02, 2023, Sean Christopherson wrote:
>> Oh, and no need to post "KVM: selftests: Rename the ASSERT_EQ macro" in the next
>> version, I'm planning on grabbing that one straightaway.
> 
> After paging this all back in...
> 
> I would much prefer that we implement the KVM specific macros[*], e.g. KVM_ONE_VCPU_TEST(),
> and build on top of those.  I'm definitely ok doing a "slow" conversion, i.e. starting
> with a few easy tests.  IIRC at some point I said I strongly preferred an all-or-nothing
> approach, but realistically I don't think we'll make progress anytime soon if we try to
> boil the ocean.

At least I don't have enough spare time to do such a big conversion all at 
once - I'm only occasionally looking at the KVM selftests, mostly for s390x, 
and I also lack the knowledge how to test all those x86 tests. So don't 
expect such a big conversion from me, all I can provide is a small patch 
here or there.

> But I do think we should spend the time to implement the infrastructure right away.  We
> may end up having to tweak the infrastructure down the road, e.g. to convert other tests,
> but I would rather do that then convert some tests twice.
> 
> [*] https://lore.kernel.org/all/Y2v+B3xxYKJSM%2FfH@google.com

Sorry, I somehow completely missed that KVM_ONE_VCPU_TEST suggestion when 
picking up the series up again after working on other stuff for more than 
half a year. I'll try to incorporate this into the next version.

(the other patches don't need a fixture, so I think they shouldn't be 
affected by this?)

  Thomas