From: Paolo Bonzini <pbonzini@redhat.com>
To: guangrong.xiao@linux.intel.com
Cc: gleb@kernel.org, mtosatti@redhat.com, kvm@vger.kernel.org,
linux-kernel@vger.kernel.org
Subject: Re: [PATCH 2/9] KVM: MMU: introduce slot_handle_level() and its helper
Date: Thu, 07 May 2015 14:04:34 +0200 [thread overview]
Message-ID: <554B54D2.5020403@redhat.com> (raw)
In-Reply-To: <1430389490-24602-3-git-send-email-guangrong.xiao@linux.intel.com>
On 30/04/2015 12:24, guangrong.xiao@linux.intel.com wrote:
> From: Xiao Guangrong <guangrong.xiao@linux.intel.com>
>
> There are several places walking all rmaps for the memslot so that
> introduce common functions to cleanup the code
>
> Signed-off-by: Xiao Guangrong <guangrong.xiao@linux.intel.com>
> ---
> arch/x86/kvm/mmu.c | 63 ++++++++++++++++++++++++++++++++++++++++++++++++++++++
> 1 file changed, 63 insertions(+)
>
> diff --git a/arch/x86/kvm/mmu.c b/arch/x86/kvm/mmu.c
> index ea3e3e4..75a3459 100644
> --- a/arch/x86/kvm/mmu.c
> +++ b/arch/x86/kvm/mmu.c
> @@ -4410,6 +4410,69 @@ void kvm_mmu_setup(struct kvm_vcpu *vcpu)
> init_kvm_mmu(vcpu);
> }
>
> +/* The return value indicates if tlb flush on all vcpus is needed. */
> +typedef bool (*slot_level_handler) (struct kvm *kvm, unsigned long *rmap);
> +
> +/* The caller should hold mmu-lock before calling this function. */
> +static bool
> +slot_handle_level(struct kvm *kvm, struct kvm_memory_slot *memslot,
> + slot_level_handler fn, int min_level, int max_level,
> + bool lock_flush_tlb)
Why not introduce for_each_slot_rmap first, instead of introducing one
implementation first and then switching to another? It's a small
change to reorder the patches like that. I think we should have three
iterator macros:
#define for_each_rmap_spte(rmap, iter, spte)
#define for_each_slot_rmap(slot, min_level, max_level, iter, rmapp)
#define for_each_slot_rmap_range(slot, iter, min_level, max_level, \
start_gfn, end_gfn, iter, rmapp)
where the last two take care of initializing the walker/iterator in the
first part of the "for".
This way, this function would be introduced immediately as this very
readable code:
struct slot_rmap_iterator iter;
unsigned long *rmapp;
bool flush = false;
for_each_slot_rmap(memslot, min_level, max_level, &iter, rmapp) {
if (*rmapp)
flush |= fn(kvm, rmapp);
if (need_resched() || spin_needbreak(&kvm->mmu_lock)) {
if (flush && lock_flush_tlb) {
kvm_flush_remote_tlbs(kvm);
flush = false;
}
cond_resched_lock(&kvm->mmu_lock);
}
}
/*
* What about adding this here: then callers that pass
* lock_flush_tlb == true need not care about the return
* value!
*/
if (flush && lock_flush_tlb) {
kvm_flush_remote_tlbs(kvm);
flush = false;
}
return flush;
In addition, some of these functions need to be marked always_inline I
think; either slot_handle_level/slot_handle_*_level, or the
iterators/walkers. Can you collect kvm.ko size for both cases?
Thanks,
Paolo
> +{
> + unsigned long last_gfn;
> + bool flush = false;
> + int level;
> +
> + last_gfn = memslot->base_gfn + memslot->npages - 1;
> +
> + for (level = min_level; level <= max_level; ++level) {
> + unsigned long *rmapp;
> + unsigned long last_index, index;
> +
> + rmapp = memslot->arch.rmap[level - PT_PAGE_TABLE_LEVEL];
> + last_index = gfn_to_index(last_gfn, memslot->base_gfn, level);
> +
> + for (index = 0; index <= last_index; ++index, ++rmapp) {
> + if (*rmapp)
> + flush |= fn(kvm, rmapp);
> +
> + if (need_resched() || spin_needbreak(&kvm->mmu_lock)) {
> + if (flush && lock_flush_tlb) {
> + kvm_flush_remote_tlbs(kvm);
> + flush = false;
> + }
> + cond_resched_lock(&kvm->mmu_lock);
> + }
> + }
> + }
> +
> + return flush;
> +}
> +
> +static bool
> +slot_handle_all_level(struct kvm *kvm, struct kvm_memory_slot *memslot,
> + slot_level_handler fn, bool lock_flush_tlb)
> +{
> + return slot_handle_level(kvm, memslot, fn, PT_PAGE_TABLE_LEVEL,
> + PT_PAGE_TABLE_LEVEL + KVM_NR_PAGE_SIZES - 1, lock_flush_tlb);
> +}
> +
> +static bool
> +slot_handle_large_level(struct kvm *kvm, struct kvm_memory_slot *memslot,
> + slot_level_handler fn, bool lock_flush_tlb)
> +{
> + return slot_handle_level(kvm, memslot, fn, PT_PAGE_TABLE_LEVEL + 1,
> + PT_PAGE_TABLE_LEVEL + KVM_NR_PAGE_SIZES - 1, lock_flush_tlb);
> +}
> +
> +static bool
> +slot_handle_leaf(struct kvm *kvm, struct kvm_memory_slot *memslot,
> + slot_level_handler fn, bool lock_flush_tlb)
> +{
> + return slot_handle_level(kvm, memslot, fn, PT_PAGE_TABLE_LEVEL,
> + PT_PAGE_TABLE_LEVEL, lock_flush_tlb);
> +}
> +
> void kvm_mmu_slot_remove_write_access(struct kvm *kvm,
> struct kvm_memory_slot *memslot)
> {
>
next prev parent reply other threads:[~2015-05-07 12:04 UTC|newest]
Thread overview: 29+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-04-30 10:24 [PATCH 0/9] KVM: MTRR fixes and some cleanups guangrong.xiao
2015-04-30 10:24 ` [PATCH 1/9] KVM: MMU: fix decoding cache type from MTRR guangrong.xiao
2015-04-30 10:24 ` [PATCH 2/9] KVM: MMU: introduce slot_handle_level() and its helper guangrong.xiao
2015-05-07 12:04 ` Paolo Bonzini [this message]
2015-05-11 13:00 ` Xiao Guangrong
2015-04-30 10:24 ` [PATCH 3/9] KVM: MMU: use slot_handle_level and its helper to clean up the code guangrong.xiao
2015-04-30 10:24 ` [PATCH 4/9] KVM: MMU: introduce for_each_rmap_spte() guangrong.xiao
2015-04-30 10:24 ` [PATCH 5/9] KVM: MMU: KVM: introduce for_each_slot_rmap guangrong.xiao
2015-04-30 10:24 ` [PATCH 6/9] KVM: MMU: introduce kvm_zap_rmapp guangrong.xiao
2015-04-30 10:24 ` [PATCH 7/9] KVM: MMU: introduce kvm_zap_gfn_range() guangrong.xiao
2015-04-30 10:24 ` [PATCH 8/9] KVM: MMU: fix MTRR update guangrong.xiao
2015-05-06 21:36 ` David Matlack
2015-05-07 1:57 ` Xiao Guangrong
2015-05-07 16:53 ` Paolo Bonzini
2015-05-11 13:02 ` Xiao Guangrong
2015-04-30 10:24 ` [PATCH 9/9] KVM: x86: do not reset mmu if CR0.CD and CR0.NW are changed guangrong.xiao
2015-04-30 10:24 ` [PATCH 0/9] KVM: MTRR fixes and some cleanups guangrong.xiao
2015-04-30 10:24 ` [PATCH 1/9] KVM: MMU: fix decoding cache type from MTRR guangrong.xiao
2015-05-06 21:42 ` David Matlack
2015-05-07 2:07 ` Xiao Guangrong
2015-04-30 10:24 ` [PATCH 2/9] KVM: MMU: introduce slot_handle_level() and its helper guangrong.xiao
2015-04-30 10:24 ` [PATCH 3/9] KVM: MMU: use slot_handle_level and its helper to clean up the code guangrong.xiao
2015-04-30 10:24 ` [PATCH 4/9] KVM: MMU: introduce for_each_rmap_spte() guangrong.xiao
2015-04-30 10:24 ` [PATCH 5/9] KVM: MMU: KVM: introduce for_each_slot_rmap guangrong.xiao
2015-04-30 10:24 ` [PATCH 6/9] KVM: MMU: introduce kvm_zap_rmapp guangrong.xiao
2015-04-30 10:24 ` [PATCH 7/9] KVM: MMU: introduce kvm_zap_gfn_range() guangrong.xiao
2015-04-30 10:24 ` [PATCH 8/9] KVM: MMU: fix MTRR update guangrong.xiao
2015-04-30 10:24 ` [PATCH 9/9] KVM: x86: do not reset mmu if CR0.CD and CR0.NW are changed guangrong.xiao
2015-05-07 16:53 ` [PATCH 0/9] KVM: MTRR fixes and some cleanups Paolo Bonzini
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=554B54D2.5020403@redhat.com \
--to=pbonzini@redhat.com \
--cc=gleb@kernel.org \
--cc=guangrong.xiao@linux.intel.com \
--cc=kvm@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=mtosatti@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 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.