Re: [PATCH v2] KVM: selftests: Use TAP interface in the set_memory_region test

[Thomas Huth]

On 02/05/2024 21.37, Sean Christopherson wrote:
> On Fri, Apr 26, 2024, Thomas Huth wrote:
> > Use the kselftest_harness.h interface in this test to get TAP
> > output, so that it is easier for the user to see what the test
> > is doing. (Note: We are not using the KVM_ONE_VCPU_TEST_SUITE()
> > macro here since these tests are creating their VMs with the
> > vm_create_barebones() function, not with vm_create_with_one_vcpu())
> >
> > Reviewed-by: Andrew Jones <ajones@xxxxxxxxxxxxxxxx>
> > Signed-off-by: Thomas Huth <thuth@xxxxxxxxxx>
> > ---
> >   v2:
> >   - Rebase to linux-next branch
> >   - Make "loops" variable static
> >   - Added Andrew's Reviewed-by
> >
> >   .../selftests/kvm/set_memory_region_test.c    | 86 +++++++++----------
> >   1 file changed, 42 insertions(+), 44 deletions(-)
> >
> > diff --git a/tools/testing/selftests/kvm/set_memory_region_test.c b/tools/testing/selftests/kvm/set_memory_region_test.c
> > index 68c899d27561..a5c9bee5235a 100644
> > --- a/tools/testing/selftests/kvm/set_memory_region_test.c
> > +++ b/tools/testing/selftests/kvm/set_memory_region_test.c
> > @@ -16,6 +16,7 @@
> >   #include <test_util.h>
> >   #include <kvm_util.h>
> >   #include <processor.h>
> > +#include "kselftest_harness.h"
> >   
> >   /*
> >    * s390x needs at least 1MB alignment, and the x86_64 MOVE/DELETE tests need a
> > @@ -38,6 +39,8 @@ extern const uint64_t final_rip_end;
> >   
> >   static sem_t vcpu_ready;
> >   
> > +static int loops;
>
> ...
>
> > -static void test_add_overlapping_private_memory_regions(void)
> > +TEST(add_overlapping_private_memory_regions)
> >   {
> >   	struct kvm_vm *vm;
> >   	int memfd;
> >   	int r;
> >   
> > -	pr_info("Testing ADD of overlapping KVM_MEM_GUEST_MEMFD memory regions\n");
> > +	if (!has_cap_guest_memfd())
> > +		SKIP(return, "Missing KVM_MEM_GUEST_MEMFD / KVM_X86_SW_PROTECTED_VM");
>
> I like that we can actually report sub-tests as being skipped, but I don't like
> having multiple ways to express requirements.  And IMO, this is much less readable
> than TEST_REQUIRE(has_cap_guest_memfd());
>
> AIUI, each test runs in a child process, so TEST_REQUIRE() can simply exit(), it
> just needs to avoid ksft_exit_skip() so that a sub-test doesn't spit out the full
> test summary.
>
> And if using exit() isn't an option, setjmp()+longjmp() will do the trick (I got
> that working for KVM_ONE_VCPU_TEST() before I realized tests run as a child).
>
> The below is lightly tested, but I think it does what we want?

Not quite ... for example, if I force vmx_pmu_caps_test to skip the last 
test, I get:

TAP version 13
1..5
# Starting 5 tests from 1 test cases.
#  RUN           vmx_pmu_caps.guest_wrmsr_perf_capabilities ...
#            OK  vmx_pmu_caps.guest_wrmsr_perf_capabilities
ok 1 vmx_pmu_caps.guest_wrmsr_perf_capabilities
#  RUN           vmx_pmu_caps.basic_perf_capabilities ...
#            OK  vmx_pmu_caps.basic_perf_capabilities
ok 2 vmx_pmu_caps.basic_perf_capabilities
#  RUN           vmx_pmu_caps.fungible_perf_capabilities ...
#            OK  vmx_pmu_caps.fungible_perf_capabilities
ok 3 vmx_pmu_caps.fungible_perf_capabilities
#  RUN           vmx_pmu_caps.immutable_perf_capabilities ...
#            OK  vmx_pmu_caps.immutable_perf_capabilities
ok 4 vmx_pmu_caps.immutable_perf_capabilities
#  RUN           vmx_pmu_caps.lbr_perf_capabilities ...
ok 5 # SKIP - Requirement not met: host_cap.lbr_format && 0
#            OK  vmx_pmu_caps.lbr_perf_capabilities
ok 5 vmx_pmu_caps.lbr_perf_capabilities
# PASSED: 5 / 5 tests passed.
# Totals: pass:5 fail:0 xfail:0 xpass:0 skip:0 error:0

As you can see, the "ok 5" line is duplicated now, once marked with "# SKIP" 
and once as successfull. I don't think that this is valid TAP anymore?

> I also think we would effectively forbid direct use of TEST().  Partly because
> it's effectively necessary to use TEST_REQUIRE(), but also so that all tests will
> have an existing single point of contact if we need/want to make similar changes
> in the future.

Ok, but I wrote in the patch description, KVM_ONE_VCPU_TEST_SUITE() does not 
work for the set_memory_region test since it does not like to have a 
pre-defined vcpu ... so if we want to forbid TEST(), I assume we'd need 
another macro like KVM_BAREBONE_TEST_SUITE() ?

Not sure whether I really like it, though, since I'd prefer if we could keep 
the possibility to use the original selftest macros (for people who are 
already used to those macros from other selftests).

 Thomas