From: Sean Christopherson <seanjc@google.com>
To: "Maciej S. Szmigiero" <mail@maciej.szmigiero.name>
Cc: Paolo Bonzini <pbonzini@redhat.com>,
Vitaly Kuznetsov <vkuznets@redhat.com>,
Wanpeng Li <wanpengli@tencent.com>,
Jim Mattson <jmattson@google.com>,
Igor Mammedov <imammedo@redhat.com>,
Marc Zyngier <maz@kernel.org>, James Morse <james.morse@arm.com>,
Julien Thierry <julien.thierry.kdev@gmail.com>,
Suzuki K Poulose <suzuki.poulose@arm.com>,
Huacai Chen <chenhuacai@kernel.org>,
Aleksandar Markovic <aleksandar.qemu.devel@gmail.com>,
Paul Mackerras <paulus@ozlabs.org>,
Christian Borntraeger <borntraeger@de.ibm.com>,
Janosch Frank <frankja@linux.ibm.com>,
David Hildenbrand <david@redhat.com>,
Cornelia Huck <cohuck@redhat.com>,
Claudio Imbrenda <imbrenda@linux.ibm.com>,
Joerg Roedel <joro@8bytes.org>,
kvm@vger.kernel.org, linux-kernel@vger.kernel.org
Subject: Re: [PATCH v5 13/13] KVM: Optimize overlapping memslots check
Date: Thu, 28 Oct 2021 17:53:33 +0000 [thread overview]
Message-ID: <YXrjnSKBhzG7JVLF@google.com> (raw)
In-Reply-To: <4222ead3-f80f-0992-569f-9e1a7adbabcc@maciej.szmigiero.name>
On Wed, Oct 27, 2021, Maciej S. Szmigiero wrote:
> On 26.10.2021 20:59, Sean Christopherson wrote:
> > > + /* kvm_for_each_in_gfn_no_more() guarantees that cslot->base_gfn < nend */
> > > + if (cend > nslot->base_gfn)
> >
> > Hmm, IMO the need for this check means that kvm_for_each_memslot_in_gfn_range()
> > is flawed. The user of kvm_for_each...() should not be responsible for skipping
> > memslots that do not actually overlap the requested range. I.e. this function
> > should be no more than:
> >
> > static bool kvm_check_memslot_overlap(struct kvm_memslots *slots,
> > struct kvm_memory_slot *slot)
> > {
> > gfn_t start = slot->base_gfn;
> > gfn_t end = start + slot->npages;
> >
> > kvm_for_each_memslot_in_gfn_range(&iter, slots, start, end) {
> > if (iter.slot->id != slot->id)
> > return true;
> > }
> >
> > return false;
> > }
> >
> >
> > and I suspect kvm_zap_gfn_range() could be further simplified as well.
> >
> > Looking back at the introduction of the helper, its comment's highlighting of
> > "possibily" now makes sense.
> >
> > /* Iterate over each memslot *possibly* intersecting [start, end) range */
> > #define kvm_for_each_memslot_in_gfn_range(node, slots, start, end) \
> >
> > That's an unnecessarily bad API. It's a very solvable problem for the iterator
> > helpers to advance until there's actually overlap, not doing so violates the
> > principle of least surprise, and unless I'm missing something, there's no use
> > case for an "approximate" iteration.
>
> In principle this can be done, however this will complicate the gfn
> iterator logic - especially the kvm_memslot_iter_start() part, which
> will already get messier from open-coding kvm_memslots_gfn_upper_bound()
> there.
Hmm, no, this is trivial to handle, though admittedly a bit unpleasant.
/*
* Note, kvm_memslot_iter_start() finds the first memslot that _may_ overlap
* the range, it does not verify that there is actual overlap. The check in
* the loop body filters out the case where the highest memslot with a base_gfn
* below start doesn't actually overlap.
*/
#define kvm_for_each_memslot_in_gfn_range(iter, node, slots, start, end) \
for (kvm_memslot_iter_start(iter, node, slots, start, end); \
kvm_memslot_iter_is_valid(iter); \
kvm_memslot_iter_next(node)) \
if (iter->slot->base_gfn + iter->slot->npages < start) { \
} else
> At the same kvm_zap_gfn_range() will still need to do the memslot range
> <-> request range merging by itself as it does not want to process the
> whole returned memslot, but rather just the part that's actually
> overlapping its requested range.
That's purely coincidental though. IMO, kvm_zap_gfn_range() would be well within
its rights to sanity the memslot, e.g.
if (WARN_ON(memslot->base_gfn + memslot->npages < gfn_start))
continue;
> In the worst case, the current code can return one memslot too much, so
> I don't think it's worth bringing additional complexity just to detect
> and skip it
I strongly disagree. This is very much a case of one chunk of code that knows
the internal details of what it's doing taking on all the pain and complexity
so that users of the helper
> it's not that uncommon to design an API that needs extra checking from its
> caller to cover some corner cases.
That doesn't mean it's desirable.
> For example, see pthread_cond_wait() or kernel waitqueues with their
> spurious wakeups or atomic_compare_exchange_weak() from C11.
> And these are higher level APIs than a very limited internal KVM one
> with just two callers.
Two _existing_ callers. Odds are very, very high that future usage of
kvm_for_each_memslot_in_gfn_range() will overlook the detail about the helper
not actually doing what it says it does. That could be addressed to some extent
by renaming it kvm_for_each_memslot_in_gfn_range_approx() or whatever, but as
above this isn't difficult to handle, just gross.
> In case of kvm_zap_gfn_range() the necessary checking is already
> there and has to be kept due to the above range merging.
>
> Also, a code that is simpler is easier to understand, maintain and
> so less prone to subtle bugs.
Heh, and IMO that's an argument for putting all the complexity into a single
location. :-)
next prev parent reply other threads:[~2021-10-28 17:53 UTC|newest]
Thread overview: 53+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-09-20 21:38 [PATCH v5 00/13] KVM: Scalable memslots implementation Maciej S. Szmigiero
2021-09-20 21:38 ` [PATCH v5 01/13] KVM: x86: Cache total page count to avoid traversing the memslot array Maciej S. Szmigiero
2021-10-19 22:24 ` Sean Christopherson
2021-10-19 22:31 ` Sean Christopherson
2021-10-20 18:40 ` Maciej S. Szmigiero
2021-10-20 18:41 ` Maciej S. Szmigiero
2021-10-20 19:01 ` Sean Christopherson
2021-11-01 22:29 ` Sean Christopherson
2021-11-03 11:59 ` Maciej S. Szmigiero
2021-11-03 14:47 ` Sean Christopherson
2021-11-03 15:38 ` Maciej S. Szmigiero
2021-09-20 21:38 ` [PATCH v5 02/13] KVM: x86: Don't call kvm_mmu_change_mmu_pages() if the count hasn't changed Maciej S. Szmigiero
2021-09-20 21:38 ` [PATCH v5 03/13] KVM: Add "old" memslot parameter to kvm_arch_prepare_memory_region() Maciej S. Szmigiero
2021-09-20 21:38 ` [PATCH v5 04/13] KVM: x86: Move n_memslots_pages recalc " Maciej S. Szmigiero
2021-10-19 22:38 ` Sean Christopherson
2021-10-20 18:41 ` Maciej S. Szmigiero
2021-09-20 21:38 ` [PATCH v5 05/13] KVM: Integrate gfn_to_memslot_approx() into search_memslots() Maciej S. Szmigiero
2021-10-19 23:38 ` Sean Christopherson
2021-10-20 18:41 ` Maciej S. Szmigiero
2021-09-20 21:38 ` [PATCH v5 06/13] KVM: Move WARN on invalid memslot index to update_memslots() Maciej S. Szmigiero
2021-10-19 23:42 ` Sean Christopherson
2021-09-20 21:38 ` [PATCH v5 07/13] KVM: Just resync arch fields when slots_arch_lock gets reacquired Maciej S. Szmigiero
2021-10-19 23:55 ` Sean Christopherson
2021-10-20 18:41 ` Maciej S. Szmigiero
2021-10-20 18:57 ` Sean Christopherson
2021-10-20 18:58 ` Maciej S. Szmigiero
2021-09-20 21:38 ` [PATCH v5 08/13] KVM: Resolve memslot ID via a hash table instead of via a static array Maciej S. Szmigiero
2021-10-20 0:43 ` Sean Christopherson
2021-10-20 18:42 ` Maciej S. Szmigiero
2021-10-20 22:39 ` Sean Christopherson
2021-10-21 14:15 ` Maciej S. Szmigiero
2021-09-20 21:38 ` [PATCH v5 09/13] KVM: Use interval tree to do fast hva lookup in memslots Maciej S. Szmigiero
2021-10-26 18:19 ` Sean Christopherson
2021-10-26 18:46 ` Maciej S. Szmigiero
2021-09-20 21:38 ` [PATCH v5 10/13] KVM: s390: Introduce kvm_s390_get_gfn_end() Maciej S. Szmigiero
2021-09-20 21:38 ` [PATCH v5 11/13] KVM: Keep memslots in tree-based structures instead of array-based ones Maciej S. Szmigiero
2021-10-27 0:36 ` Sean Christopherson
2021-10-27 23:54 ` Sean Christopherson
2021-10-28 22:22 ` Sean Christopherson
2021-09-20 21:39 ` [PATCH v5 12/13] KVM: Optimize gfn lookup in kvm_zap_gfn_range() Maciej S. Szmigiero
2021-10-20 23:47 ` Sean Christopherson
2021-10-21 14:16 ` Maciej S. Szmigiero
2021-10-21 16:30 ` Sean Christopherson
2021-10-21 21:44 ` Maciej S. Szmigiero
2021-09-20 21:39 ` [PATCH v5 13/13] KVM: Optimize overlapping memslots check Maciej S. Szmigiero
2021-10-26 18:59 ` Sean Christopherson
2021-10-27 13:48 ` Maciej S. Szmigiero
2021-10-28 17:53 ` Sean Christopherson [this message]
2021-10-29 16:23 ` Maciej S. Szmigiero
2021-10-30 0:32 ` Sean Christopherson
2021-10-19 22:07 ` [PATCH v5 00/13] KVM: Scalable memslots implementation Sean Christopherson
2021-10-20 18:40 ` Maciej S. Szmigiero
2021-10-20 19:58 ` Sean Christopherson
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=YXrjnSKBhzG7JVLF@google.com \
--to=seanjc@google.com \
--cc=aleksandar.qemu.devel@gmail.com \
--cc=borntraeger@de.ibm.com \
--cc=chenhuacai@kernel.org \
--cc=cohuck@redhat.com \
--cc=david@redhat.com \
--cc=frankja@linux.ibm.com \
--cc=imammedo@redhat.com \
--cc=imbrenda@linux.ibm.com \
--cc=james.morse@arm.com \
--cc=jmattson@google.com \
--cc=joro@8bytes.org \
--cc=julien.thierry.kdev@gmail.com \
--cc=kvm@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=mail@maciej.szmigiero.name \
--cc=maz@kernel.org \
--cc=paulus@ozlabs.org \
--cc=pbonzini@redhat.com \
--cc=suzuki.poulose@arm.com \
--cc=vkuznets@redhat.com \
--cc=wanpengli@tencent.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).