From: Thomas Huth <thuth@redhat.com>
To: Sean Christopherson <seanjc@google.com>
Cc: Paolo Bonzini <pbonzini@redhat.com>,
kvm@vger.kernel.org, Shuah Khan <shuah@kernel.org>,
linux-kernel@vger.kernel.org, linux-kselftest@vger.kernel.org
Subject: Re: [PATCH v2 7/7] KVM: selftests: x86: Use TAP interface in the userspace_msr_exit test
Date: Thu, 8 Feb 2024 20:31:09 +0100 [thread overview]
Message-ID: <ed511f49-ef77-4cc6-bebb-7f4e7c69e008@redhat.com> (raw)
In-Reply-To: <ZbQIz3thIczeRhCs@google.com>
On 26/01/2024 20.32, Sean Christopherson wrote:
> On Thu, Oct 05, 2023, 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're not using the KVM_ONE_VCPU_TEST() macro here (but the
>> generic TEST() macro from kselftest_harness.h) since each of the
>> tests needs a different guest code function.
>
> I would much rather we add a KVM framework that can deal with this, i.e. build
> something that is flexible from the get-go. Allowing tests to set the entry point
> after vCPU is fairly straightforward (patch below, compile tested only on x86).
>
> With that, my vote would be to have KVM_ONE_VCPU_TEST_SUITE() *always* pass NULL
> for the entry point, and instead always require sub-tests to pass the guest code
> to KVM_ONE_VCPU_TEST(). I think having the sub-test explicitly specify its guest
> code will be helpful for developers reading the code.
Yes, I agree that sounds quite a bit nicer. I'll give it a try...
Thomas
prev parent reply other threads:[~2024-02-08 19:31 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-10-05 14:38 [PATCH v2 0/7] Use TAP in some more x86 KVM selftests Thomas Huth
2023-10-05 14:38 ` [PATCH v2 1/7] KVM: selftests: x86: sync_regs_test: Use vcpu_run() where appropriate Thomas Huth
2023-10-05 14:38 ` [PATCH v2 2/7] KVM: selftests: x86: sync_regs_test: Get regs structure before modifying it Thomas Huth
2023-10-05 14:38 ` [PATCH v2 3/7] KVM: selftests: Add a macro to define a test with one vcpu Thomas Huth
2023-10-05 14:38 ` [PATCH v2 4/7] KVM: selftests: x86: Use TAP interface in the sync_regs test Thomas Huth
2023-10-05 14:38 ` [PATCH v2 5/7] KVM: selftests: x86: Use TAP interface in the fix_hypercall test Thomas Huth
2023-10-05 14:38 ` [PATCH v2 6/7] KVM: selftests: x86: Use TAP interface in the vmx_pmu_caps test Thomas Huth
2023-10-05 14:38 ` [PATCH v2 7/7] KVM: selftests: x86: Use TAP interface in the userspace_msr_exit test Thomas Huth
2024-01-26 19:32 ` Sean Christopherson
2024-02-08 19:31 ` Thomas Huth [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=ed511f49-ef77-4cc6-bebb-7f4e7c69e008@redhat.com \
--to=thuth@redhat.com \
--cc=kvm@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-kselftest@vger.kernel.org \
--cc=pbonzini@redhat.com \
--cc=seanjc@google.com \
--cc=shuah@kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.