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: 23+ 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-06 22:00 ` kernel test robot
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-28 7:37 ` kernel test robot
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 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.