On 12/15/2015 04:43 PM, Kai Huang wrote:

On 12/01/2015 02:26 AM, Xiao Guangrong wrote:
Now, all non-leaf shadow page are page tracked, if gfn is not tracked
there is no non-leaf shadow page of gfn is existed, we can directly
make the shadow page of gfn to unsync

Signed-off-by: Xiao Guangrong <guangrong.x...@linux.intel.com>
  arch/x86/kvm/mmu.c | 26 ++++++++------------------
  1 file changed, 8 insertions(+), 18 deletions(-)

diff --git a/arch/x86/kvm/mmu.c b/arch/x86/kvm/mmu.c
index 5a2ca73..f89e77f 100644
--- a/arch/x86/kvm/mmu.c
+++ b/arch/x86/kvm/mmu.c
@@ -2461,41 +2461,31 @@ static void __kvm_unsync_page(struct kvm_vcpu *vcpu, 
struct kvm_mmu_page *sp)
-static void kvm_unsync_pages(struct kvm_vcpu *vcpu,  gfn_t gfn)
+static bool kvm_unsync_pages(struct kvm_vcpu *vcpu, gfn_t gfn,
+                 bool can_unsync)
      struct kvm_mmu_page *s;
      for_each_gfn_indirect_valid_sp(vcpu->kvm, s, gfn) {
+        if (!can_unsync)
+            return true;
How about moving this right before for_each_gfn_indirect_valid_sp? As 
can_unsync is passed as
parameter, so there's no point checking it several times.

We can not do this. What we are doing here is checking if we have shadow page 
for 'gfn':
a) if no, it can be writable.
b) if yes, check 'can_unsync' to see if these shadow pages can make to be 

Your suggestion can break the point a).

A further thinking is can we move it to mmu_need_write_protect? Passing 
can_unsync as parameter to
kvm_unsync_pages sounds a little bit odd.

          if (s->unsync)
          WARN_ON(s->role.level != PT_PAGE_TABLE_LEVEL);
How about large page mapping? Such as if guest uses 2M mapping and its shadow 
is indirect, does
above WARN_ON still meet? As you removed the PT level check in 

The lager mapping are on the non-leaf shadow pages which can be figured out by
kvm_page_track_check_mode() before we call this function.

To unsubscribe from this list: send the line "unsubscribe kvm" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Reply via email to