From: Sean Christopherson <seanjc@google.com>
To: Shivam Kumar <shivam.kumar1@nutanix.com>
Cc: pbonzini@redhat.com, kvm@vger.kernel.org,
Shaju Abraham <shaju.abraham@nutanix.com>,
Manish Mishra <manish.mishra@nutanix.com>,
Anurag Madnawat <anurag.madnawat@nutanix.com>
Subject: Re: [PATCH v3 3/3] KVM: selftests: Add selftests for dirty quota throttling
Date: Mon, 18 Apr 2022 16:17:21 +0000 [thread overview]
Message-ID: <Yl2PEXqHswOc2j0L@google.com> (raw)
In-Reply-To: <6c5ee7d1-63bb-a0a7-fb0c-78ffcfd97bc5@nutanix.com>
On Mon, Apr 18, 2022, Shivam Kumar wrote:
> > > +void vcpu_handle_dirty_quota_exit(struct kvm_run *run,
> > > + uint64_t test_dirty_quota_increment)
> > > +{
> > > + uint64_t quota = run->dirty_quota_exit.quota;
> > > + uint64_t count = run->dirty_quota_exit.count;
> > > +
> > > + /*
> > > + * Due to PML, number of pages dirtied by the vcpu can exceed its dirty
> > > + * quota by PML buffer size.
> > > + */
> > > + TEST_ASSERT(count <= quota + PML_BUFFER_SIZE, "Invalid number of pages
> > > + dirtied: count=%"PRIu64", quota=%"PRIu64"\n", count, quota);
> Sean, I don't think this would be valid anymore because as you mentioned, the
> vcpu can dirty multiple pages in one vmexit. I could use your help here.
TL;DR: Should be fine, but s390 likely needs an exception.
Practically speaking the 512 entry fuzziness is all but guaranteed to prevent
false failures.
But, unconditionally allowing for overflow of 512 entries also means the test is
unlikely to ever detect violations. So to provide meaningful coverage, this needs
to allow overflow if and only if PML is enabled.
And that brings us back to false failures due to _legitimate_ scenarios where a vCPU
can dirty multiple pages. Emphasis on legitimate, because except for an s390 edge
case, I don't think this test's guest code does anything that would dirty multiple
pages in a single instruction, e.g. there's no emulation, shouldn't be any descriptor
table side effects, etc... So unless I'm missing something, KVM should be able to
precisely handle the core run loop.
s390 does appear to have a caveat:
/*
* On s390x, all pages of a 1M segment are initially marked as dirty
* when a page of the segment is written to for the very first time.
* To compensate this specialty in this test, we need to touch all
* pages during the first iteration.
*/
for (i = 0; i < guest_num_pages; i++) {
addr = guest_test_virt_mem + i * guest_page_size;
*(uint64_t *)addr = READ_ONCE(iteration);
}
IIUC, subsequent iterations will be ok, but the first iteration needs to allow
for overflow of 256 (AFAIK the test only uses 4kb pages on s390).
next prev parent reply other threads:[~2022-04-18 16:17 UTC|newest]
Thread overview: 26+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-03-06 22:08 [PATCH v3 0/3] KVM: Dirty quota-based throttling Shivam Kumar
2022-03-06 22:08 ` [PATCH v3 1/3] KVM: Implement dirty quota-based throttling of vcpus Shivam Kumar
2022-03-31 0:28 ` Sean Christopherson
2022-03-31 7:20 ` Shivam Kumar
2022-03-31 15:37 ` Sean Christopherson
2022-04-06 12:32 ` Shivam Kumar
2022-05-02 22:14 ` Peter Xu
2022-05-03 7:22 ` Shivam Kumar
2022-05-03 13:43 ` Peter Xu
2022-05-04 6:33 ` Shivam Kumar
2022-05-04 17:26 ` Peter Xu
2022-05-05 15:17 ` Shivam Kumar
2022-03-06 22:08 ` [PATCH v3 2/3] KVM: Documentation: Update kvm_run structure for dirty quota Shivam Kumar
2022-03-31 0:40 ` Sean Christopherson
2022-03-31 7:30 ` Shivam Kumar
2022-03-31 15:24 ` Sean Christopherson
2022-04-01 13:49 ` Sean Christopherson
2022-04-06 12:39 ` Shivam Kumar
2022-04-06 12:44 ` Shivam Kumar
2022-03-06 22:08 ` [PATCH v3 3/3] KVM: selftests: Add selftests for dirty quota throttling Shivam Kumar
2022-04-18 4:55 ` Shivam Kumar
2022-04-18 4:59 ` Shivam Kumar
2022-04-18 16:17 ` Sean Christopherson [this message]
2022-04-28 7:00 ` Shivam Kumar
2022-04-28 23:59 ` Sean Christopherson
2022-03-19 18:21 ` [PATCH v3 0/3] KVM: Dirty quota-based throttling Shivam Kumar
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=Yl2PEXqHswOc2j0L@google.com \
--to=seanjc@google.com \
--cc=anurag.madnawat@nutanix.com \
--cc=kvm@vger.kernel.org \
--cc=manish.mishra@nutanix.com \
--cc=pbonzini@redhat.com \
--cc=shaju.abraham@nutanix.com \
--cc=shivam.kumar1@nutanix.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;
as well as URLs for NNTP newsgroup(s).