From: Sean Christopherson <seanjc@google.com>
To: Maxim Levitsky <mlevitsk@redhat.com>
Cc: Paolo Bonzini <pbonzini@redhat.com>,
kvm@vger.kernel.org, linux-kernel@vger.kernel.org,
Peter Xu <peterx@redhat.com>
Subject: Re: [PATCH 09/20] KVM: selftests: Honor "stop" request in dirty ring test
Date: Wed, 18 Dec 2024 18:00:41 -0800 [thread overview]
Message-ID: <Z2N-SamWEAIeaeeX@google.com> (raw)
In-Reply-To: <39f309e4a15ee7901f023e04162d6072b53c07d8.camel@redhat.com>
On Tue, Dec 17, 2024, Maxim Levitsky wrote:
> On Fri, 2024-12-13 at 17:07 -0800, Sean Christopherson wrote:
> > Now that the vCPU doesn't dirty every page on the first iteration for
> > architectures that support the dirty ring, honor vcpu_stop in the dirty
> > ring's vCPU worker, i.e. stop when the main thread says "stop". This will
> > allow plumbing vcpu_stop into the guest so that the vCPU doesn't need to
> > periodically exit to userspace just to see if it should stop.
>
> This is very misleading - by the very nature of this test it all runs in
> userspace, so every time KVM_RUN ioctl exits, it is by definition an
> userspace VM exit.
I honestly don't see how being more precise is misleading. I'm happy to reword
the changelog, but IMO just saying "exit" doesn't make it clear that the goal is
to avoid the deliberate exit to the selftest's userspace side of things. The
vCPU is constantly exiting to KVM for dirty logging, so to me, "periodically exit
just to see if it should stop" is confusing and ambiguous.
> > Add a comment explaining that marking all pages as dirty is problematic
> > for the dirty ring, as it results in the guest getting stuck on "ring
> > full". This could be addressed by adding a GUEST_SYNC() in that initial
> > loop, but it's not clear how that would interact with s390's behavior.
>
> I think that this commit description should be reworked to state that s390
> doesn't support dirty ring currently so the test doesn't introduce a regression.
Can do.
> > Signed-off-by: Sean Christopherson <seanjc@google.com>
> > ---
> > tools/testing/selftests/kvm/dirty_log_test.c | 12 ++++++++++--
> > 1 file changed, 10 insertions(+), 2 deletions(-)
> >
> > diff --git a/tools/testing/selftests/kvm/dirty_log_test.c b/tools/testing/selftests/kvm/dirty_log_test.c
> > index 55a385499434..8d31e275a23d 100644
> > --- a/tools/testing/selftests/kvm/dirty_log_test.c
> > +++ b/tools/testing/selftests/kvm/dirty_log_test.c
> > @@ -387,8 +387,7 @@ static void dirty_ring_after_vcpu_run(struct kvm_vcpu *vcpu)
> >
> > /* A ucall-sync or ring-full event is allowed */
> > if (get_ucall(vcpu, NULL) == UCALL_SYNC) {
> > - /* We should allow this to continue */
> > - ;
> > + vcpu_handle_sync_stop();
> > } else if (run->exit_reason == KVM_EXIT_DIRTY_RING_FULL) {
> > /* Update the flag first before pause */
> > WRITE_ONCE(dirty_ring_vcpu_ring_full, true);
> > @@ -697,6 +696,15 @@ static void run_test(enum vm_guest_mode mode, void *arg)
> > #ifdef __s390x__
> > /* Align to 1M (segment size) */
> > guest_test_phys_mem = align_down(guest_test_phys_mem, 1 << 20);
> > +
> > + /*
> > + * The workaround in guest_code() to write all pages prior to the first
> > + * iteration isn't compatible with the dirty ring, as the dirty ring
> > + * support relies on the vCPU to actually stop when vcpu_stop is set so
> > + * that the vCPU doesn't hang waiting for the dirty ring to be emptied.
> > + */
> > + TEST_ASSERT(host_log_mode != LOG_MODE_DIRTY_RING,
> > + "Test needs to be updated to support s390 dirty ring");
>
> This not clear either, the message makes me think that s390 does support dirty ring.
> The comment above should state stat since s390 doesn't support dirty ring,
> this is fine, and when/if the support is added,then the test will need to be updated.
How about this?
/*
* The s390 workaround in guest_code() to write all pages prior to the
* first iteration isn't compatible with the dirty ring test, as dirty
* ring testing relies on the vCPU to actually stop when vcpu_stop is
* set. If the vCPU doesn't stop, it will hang waiting for the dirty
* ring to be emptied. s390 doesn't currently support the dirty ring,
* and it's not clear how best to resolve the situation, so punt the
* problem to the future.
*/
TEST_ASSERT(host_log_mode != LOG_MODE_DIRTY_RING,
"Test needs to be updated to support dirty ring on s390; see comment for details");
next prev parent reply other threads:[~2024-12-19 2:00 UTC|newest]
Thread overview: 49+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-12-14 1:07 [PATCH 00/20] KVM: selftests: Fixes and cleanups for dirty_log_test Sean Christopherson
2024-12-14 1:07 ` [PATCH 01/20] KVM: selftests: Support multiple write retires in dirty_log_test Sean Christopherson
2024-12-14 1:07 ` [PATCH 02/20] KVM: selftests: Sync dirty_log_test iteration to guest *before* resuming Sean Christopherson
2024-12-17 23:58 ` Maxim Levitsky
2024-12-18 21:36 ` Sean Christopherson
2024-12-19 15:11 ` Maxim Levitsky
2024-12-14 1:07 ` [PATCH 03/20] KVM: selftests: Drop signal/kick from dirty ring testcase Sean Christopherson
2024-12-14 1:07 ` [PATCH 04/20] KVM: selftests: Drop stale srandom() initialization from dirty_log_test Sean Christopherson
2024-12-17 23:59 ` Maxim Levitsky
2024-12-14 1:07 ` [PATCH 05/20] KVM: selftests: Precisely track number of dirty/clear pages for each iteration Sean Christopherson
2024-12-17 23:59 ` Maxim Levitsky
2024-12-18 21:37 ` Sean Christopherson
2024-12-14 1:07 ` [PATCH 06/20] KVM: selftests: Read per-page value into local var when verifying dirty_log_test Sean Christopherson
2024-12-17 23:59 ` Maxim Levitsky
2024-12-14 1:07 ` [PATCH 07/20] KVM: selftests: Continuously reap dirty ring while vCPU is running Sean Christopherson
2024-12-18 0:00 ` Maxim Levitsky
2024-12-19 1:50 ` Sean Christopherson
2024-12-14 1:07 ` [PATCH 08/20] KVM: selftests: Limit dirty_log_test's s390x workaround to s390x Sean Christopherson
2024-12-14 1:07 ` [PATCH 09/20] KVM: selftests: Honor "stop" request in dirty ring test Sean Christopherson
2024-12-18 0:00 ` Maxim Levitsky
2024-12-19 2:00 ` Sean Christopherson [this message]
2024-12-19 15:07 ` Maxim Levitsky
2024-12-19 15:23 ` Sean Christopherson
2024-12-19 15:57 ` Maxim Levitsky
2024-12-14 1:07 ` [PATCH 10/20] KVM: selftests: Keep dirty_log_test vCPU in guest until it needs to stop Sean Christopherson
2024-12-18 0:01 ` Maxim Levitsky
2024-12-19 15:59 ` Maxim Levitsky
2024-12-14 1:07 ` [PATCH 11/20] KVM: selftests: Post to sem_vcpu_stop if and only if vcpu_stop is true Sean Christopherson
2024-12-18 0:01 ` Maxim Levitsky
2024-12-14 1:07 ` [PATCH 12/20] KVM: selftests: Use continue to handle all "pass" scenarios in dirty_log_test Sean Christopherson
2024-12-18 0:01 ` Maxim Levitsky
2024-12-14 1:07 ` [PATCH 13/20] KVM: selftests: Print (previous) last_page on dirty page value mismatch Sean Christopherson
2024-12-18 0:01 ` Maxim Levitsky
2024-12-14 1:07 ` [PATCH 14/20] KVM: selftests: Collect *all* dirty entries in each dirty_log_test iteration Sean Christopherson
2024-12-18 0:02 ` Maxim Levitsky
2024-12-19 2:13 ` Sean Christopherson
2024-12-19 12:55 ` Paolo Bonzini
2024-12-19 15:01 ` Maxim Levitsky
2024-12-14 1:07 ` [PATCH 15/20] KVM: sefltests: Verify value of dirty_log_test last page isn't bogus Sean Christopherson
2024-12-18 0:02 ` Maxim Levitsky
2024-12-14 1:07 ` [PATCH 16/20] KVM: selftests: Ensure guest writes min number of pages in dirty_log_test Sean Christopherson
2024-12-18 0:02 ` Maxim Levitsky
2024-12-14 1:07 ` [PATCH 17/20] KVM: selftests: Tighten checks around prev iter's last dirty page in ring Sean Christopherson
2024-12-18 0:03 ` Maxim Levitsky
2024-12-14 1:07 ` [PATCH 18/20] KVM: selftests: Set per-iteration variables at the start of each iteration Sean Christopherson
2024-12-14 1:07 ` [PATCH 19/20] KVM: selftests: Fix an off-by-one in the number of dirty_log_test iterations Sean Christopherson
2024-12-18 0:03 ` Maxim Levitsky
2024-12-14 1:07 ` [PATCH 20/20] KVM: selftests: Allow running a single iteration of dirty_log_test Sean Christopherson
2024-12-18 0:03 ` Maxim Levitsky
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=Z2N-SamWEAIeaeeX@google.com \
--to=seanjc@google.com \
--cc=kvm@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=mlevitsk@redhat.com \
--cc=pbonzini@redhat.com \
--cc=peterx@redhat.com \
/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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox