From: David Matlack <dmatlack@google.com>
To: Ben Gardon <bgardon@google.com>
Cc: linux-kernel@vger.kernel.org, kvm@vger.kernel.org,
Paolo Bonzini <pbonzini@redhat.com>, Peter Xu <peterx@redhat.com>,
Sean Christopherson <seanjc@google.com>,
Vipin Sharma <vipinsh@google.com>
Subject: Re: [PATCH 6/7] KVM: x86/MMU: Move rmap zap operations to rmap.c
Date: Fri, 9 Dec 2022 14:44:46 -0800 [thread overview]
Message-ID: <Y5O6XiJSjGmpMl3R@google.com> (raw)
In-Reply-To: <20221206173601.549281-7-bgardon@google.com>
On Tue, Dec 06, 2022 at 05:36:00PM +0000, Ben Gardon wrote:
> Move the various rmap zap functions to rmap.c. These functions are less
> "pure" rmap operations in that they also contain some SPTE manipulation,
> however they're mostly about rmap / pte list manipulation.
>
> No functional change intended.
>
> Signed-off-by: Ben Gardon <bgardon@google.com>
> ---
[...]
> -static void kvm_zap_one_rmap_spte(struct kvm *kvm,
> - struct kvm_rmap_head *rmap_head, u64 *sptep)
> -{
> - mmu_spte_clear_track_bits(kvm, sptep);
> - pte_list_remove(sptep, rmap_head);
> -}
> -
> -/* Return true if at least one SPTE was zapped, false otherwise */
> -static bool kvm_zap_all_rmap_sptes(struct kvm *kvm,
> - struct kvm_rmap_head *rmap_head)
> -{
> - struct pte_list_desc *desc, *next;
> - int i;
> -
> - if (!rmap_head->val)
> - return false;
> -
> - if (!(rmap_head->val & 1)) {
> - mmu_spte_clear_track_bits(kvm, (u64 *)rmap_head->val);
> - goto out;
> - }
> -
> - desc = (struct pte_list_desc *)(rmap_head->val & ~1ul);
> -
> - for (; desc; desc = next) {
> - for (i = 0; i < desc->spte_count; i++)
> - mmu_spte_clear_track_bits(kvm, desc->sptes[i]);
> - next = desc->more;
> - free_pte_list_desc(desc);
> - }
> -out:
> - /* rmap_head is meaningless now, remember to reset it */
> - rmap_head->val = 0;
> - return true;
> -}
I don't like moving the rmap zap functions into rmap.c, because they are
more mmu.c functions, as you note in the commit description. e.g. It's
odd to have kvm_zap_all_rmap_sptes() in rmap.c but not, say
__rmap_clear_dirty().
I get your point though that kvm_zap_all_rmap_sptes() has to know
intimate details of the pte_list_desc structure. It would be nice to
keep those details isolated to rmap.c.
What about keeping the zap functions mmu.c and just provide a better API
for kvm_zap_all_rmap_sptes() to process the rmap entries?
e.g.
mmu.c:
static bool kvm_zap_all_rmap_sptes(struct kvm *kvm,
struct kvm_rmap_head *rmap_head)
{
struct rmap_iterator iter;
bool flush = false;
u64 *sptep;
for_each_rmap_spte(rmap_head, &iter, sptep) {
mmu_spte_clear_track_bits(kvm, sptep);
flush = true;
}
pte_list_free_all(rmap_head); // <-- implemented in rmap.c
return flush;
}
This should be about as efficient as the current approach (same big-O
notation at least) and maintain the separation of pte_list_desc
internals in rmap.c.
next prev parent reply other threads:[~2022-12-09 22:44 UTC|newest]
Thread overview: 21+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-12-06 17:35 [PATCH 0/7] KVM: x86/MMU: Factor rmap operations out of mmu.c Ben Gardon
2022-12-06 17:35 ` [PATCH 1/7] KVM: x86/MMU: Move pte_list operations to rmap.c Ben Gardon
2022-12-07 22:58 ` Vipin Sharma
2022-12-14 0:11 ` Ben Gardon
2022-12-09 22:22 ` David Matlack
2022-12-14 0:07 ` Ben Gardon
2022-12-06 17:35 ` [PATCH 2/7] KVM: x86/MMU: Move rmap_iterator to rmap.h Ben Gardon
2022-12-09 23:04 ` David Matlack
2022-12-14 0:12 ` Ben Gardon
2022-12-14 0:59 ` Sean Christopherson
2022-12-14 17:53 ` Ben Gardon
2022-12-15 0:34 ` Sean Christopherson
2022-12-06 17:35 ` [PATCH 3/7] KVM: x86/MMU: Move gfn_to_rmap() to rmap.c Ben Gardon
2022-12-09 23:32 ` David Matlack
2022-12-06 17:35 ` [PATCH 4/7] KVM: x86/MMU: Move rmap_can_add() and rmap_remove() " Ben Gardon
2022-12-06 17:35 ` [PATCH 5/7] KVM: x86/MMU: Move the rmap walk iterator out of mmu.c Ben Gardon
2022-12-06 17:36 ` [PATCH 6/7] KVM: x86/MMU: Move rmap zap operations to rmap.c Ben Gardon
2022-12-09 22:44 ` David Matlack [this message]
2022-12-06 17:36 ` [PATCH 7/7] KVM: x86/MMU: Move rmap_add() " Ben Gardon
2022-12-09 23:27 ` David Matlack
2022-12-09 23:14 ` [PATCH 0/7] KVM: x86/MMU: Factor rmap operations out of mmu.c David Matlack
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=Y5O6XiJSjGmpMl3R@google.com \
--to=dmatlack@google.com \
--cc=bgardon@google.com \
--cc=kvm@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=pbonzini@redhat.com \
--cc=peterx@redhat.com \
--cc=seanjc@google.com \
--cc=vipinsh@google.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