From: Paolo Bonzini <pbonzini@redhat.com>
To: Xiao Guangrong <guangrong.xiao@linux.intel.com>
Cc: gleb@kernel.org, mtosatti@redhat.com, kvm@vger.kernel.org,
linux-kernel@vger.kernel.org, kai.huang@linux.intel.com,
jike.song@intel.com
Subject: Re: [PATCH 09/11] KVM: MMU: use page track for non-leaf shadow pages
Date: Mon, 29 Feb 2016 16:22:14 +0100 [thread overview]
Message-ID: <56D46226.5060605@redhat.com> (raw)
In-Reply-To: <1456307476-46398-10-git-send-email-guangrong.xiao@linux.intel.com>
On 24/02/2016 10:51, Xiao Guangrong wrote:
> non-leaf shadow pages are always write protected, it can be the user
> of page track
>
> Signed-off-by: Xiao Guangrong <guangrong.xiao@linux.intel.com>
> ---
> arch/x86/kvm/mmu.c | 26 +++++++++++++++++++++-----
> 1 file changed, 21 insertions(+), 5 deletions(-)
>
> diff --git a/arch/x86/kvm/mmu.c b/arch/x86/kvm/mmu.c
> index 58c067d..74684b2 100644
> --- a/arch/x86/kvm/mmu.c
> +++ b/arch/x86/kvm/mmu.c
> @@ -806,11 +806,17 @@ static void account_shadowed(struct kvm *kvm, struct kvm_mmu_page *sp)
> struct kvm_memory_slot *slot;
> gfn_t gfn;
>
> + kvm->arch.indirect_shadow_pages++;
> gfn = sp->gfn;
> slots = kvm_memslots_for_spte_role(kvm, sp->role);
> slot = __gfn_to_memslot(slots, gfn);
> +
> + /* the non-leaf shadow pages are keeping readonly. */
> + if (sp->role.level > PT_PAGE_TABLE_LEVEL)
> + return kvm_slot_page_track_add_page(kvm, slot, gfn,
> + KVM_PAGE_TRACK_WRITE);
> +
> kvm_mmu_gfn_disallow_lpage(slot, gfn);
> - kvm->arch.indirect_shadow_pages++;
> }
>
> static void unaccount_shadowed(struct kvm *kvm, struct kvm_mmu_page *sp)
> @@ -819,11 +825,15 @@ static void unaccount_shadowed(struct kvm *kvm, struct kvm_mmu_page *sp)
> struct kvm_memory_slot *slot;
> gfn_t gfn;
>
> + kvm->arch.indirect_shadow_pages--;
> gfn = sp->gfn;
> slots = kvm_memslots_for_spte_role(kvm, sp->role);
> slot = __gfn_to_memslot(slots, gfn);
> + if (sp->role.level > PT_PAGE_TABLE_LEVEL)
> + return kvm_slot_page_track_remove_page(kvm, slot, gfn,
> + KVM_PAGE_TRACK_WRITE);
> +
> kvm_mmu_gfn_allow_lpage(slot, gfn);
> - kvm->arch.indirect_shadow_pages--;
> }
>
> static bool __mmu_gfn_lpage_is_disallowed(gfn_t gfn, int level,
> @@ -2132,12 +2142,18 @@ static struct kvm_mmu_page *kvm_mmu_get_page(struct kvm_vcpu *vcpu,
> hlist_add_head(&sp->hash_link,
> &vcpu->kvm->arch.mmu_page_hash[kvm_page_table_hashfn(gfn)]);
> if (!direct) {
> - if (rmap_write_protect(vcpu, gfn))
> + /*
> + * we should do write protection before syncing pages
> + * otherwise the content of the synced shadow page may
> + * be inconsistent with guest page table.
> + */
> + account_shadowed(vcpu->kvm, sp);
> +
> + if (level == PT_PAGE_TABLE_LEVEL &&
> + rmap_write_protect(vcpu, gfn))
> kvm_flush_remote_tlbs(vcpu->kvm);
> if (level > PT_PAGE_TABLE_LEVEL && need_sync)
> kvm_sync_pages(vcpu, gfn);
> -
> - account_shadowed(vcpu->kvm, sp);
> }
> sp->mmu_valid_gen = vcpu->kvm->arch.mmu_valid_gen;
> clear_page(sp->spt);
>
Hi,
I'm applying this series with just a very simple change on top of this patch:
diff --git a/arch/x86/kvm/mmu.c b/arch/x86/kvm/mmu.c
index 74684b2b7e69..fe03d2a1d4d3 100644
--- a/arch/x86/kvm/mmu.c
+++ b/arch/x86/kvm/mmu.c
@@ -2148,10 +2148,10 @@ static struct kvm_mmu_page *kvm_mmu_get_page(struct kvm_vcpu *vcpu,
* be inconsistent with guest page table.
*/
account_shadowed(vcpu->kvm, sp);
-
if (level == PT_PAGE_TABLE_LEVEL &&
rmap_write_protect(vcpu, gfn))
kvm_flush_remote_tlbs(vcpu->kvm);
+
if (level > PT_PAGE_TABLE_LEVEL && need_sync)
kvm_sync_pages(vcpu, gfn);
}
Yes, it's just moving around an empty line. :)
Paolo
next prev parent reply other threads:[~2016-02-29 15:22 UTC|newest]
Thread overview: 14+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-02-24 9:51 [PATCH v4 00/11] KVM: x86: track guest page access Xiao Guangrong
2016-02-24 9:51 ` [PATCH 01/11] KVM: MMU: rename has_wrprotected_page to mmu_gfn_lpage_is_disallowed Xiao Guangrong
2016-02-24 9:51 ` [PATCH 02/11] KVM: MMU: introduce kvm_mmu_gfn_{allow,disallow}_lpage Xiao Guangrong
2016-02-24 9:51 ` [PATCH 03/11] KVM: MMU: introduce kvm_mmu_slot_gfn_write_protect Xiao Guangrong
2016-02-24 9:51 ` [PATCH 04/11] KVM: page track: add the framework of guest page tracking Xiao Guangrong
2016-02-24 9:51 ` [PATCH 05/11] KVM: page track: introduce kvm_slot_page_track_{add,remove}_page Xiao Guangrong
2016-02-24 9:51 ` [PATCH 06/11] KVM: MMU: let page fault handler be aware tracked page Xiao Guangrong
2016-02-24 9:51 ` [PATCH 07/11] KVM: MMU: clear write-flooding on the fast path of " Xiao Guangrong
2016-02-24 9:51 ` [PATCH 08/11] KVM: page track: add notifier support Xiao Guangrong
2016-02-24 9:51 ` [PATCH 09/11] KVM: MMU: use page track for non-leaf shadow pages Xiao Guangrong
2016-02-29 15:22 ` Paolo Bonzini [this message]
2016-02-24 9:51 ` [PATCH 10/11] KVM: MMU: simplify mmu_need_write_protect Xiao Guangrong
2016-02-24 9:51 ` [PATCH 11/11] KVM: MMU: apply page track notifier Xiao Guangrong
2016-02-24 13:42 ` [PATCH v4 00/11] KVM: x86: track guest page access 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=56D46226.5060605@redhat.com \
--to=pbonzini@redhat.com \
--cc=gleb@kernel.org \
--cc=guangrong.xiao@linux.intel.com \
--cc=jike.song@intel.com \
--cc=kai.huang@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.