From bb6c690a4341ebd45b4dd1396ffab0f51d00628a Mon Sep 17 00:00:00 2001 From: Xiao Guangrong Date: Tue, 4 Dec 2012 07:17:11 +0800 Subject: [PATCH] --- yaml --- r: 343560 b: refs/heads/master c: c21934632549910188fb5cf40e79033f27a0741b h: refs/heads/master v: v3 --- [refs] | 2 +- trunk/arch/x86/kvm/mmu.c | 16 ++++++++++++---- 2 files changed, 13 insertions(+), 5 deletions(-) diff --git a/[refs] b/[refs] index 1439335c73ae..3d33cb35704f 100644 --- a/[refs] +++ b/[refs] @@ -1,2 +1,2 @@ --- -refs/heads/master: 66f7b72e117180d0007e7a65b8dc5bd1c8126e3b +refs/heads/master: c21934632549910188fb5cf40e79033f27a0741b diff --git a/trunk/arch/x86/kvm/mmu.c b/trunk/arch/x86/kvm/mmu.c index b875a9ed9b8e..01d7c2ad05f5 100644 --- a/trunk/arch/x86/kvm/mmu.c +++ b/trunk/arch/x86/kvm/mmu.c @@ -2382,12 +2382,20 @@ static int set_spte(struct kvm_vcpu *vcpu, u64 *sptep, || (!vcpu->arch.mmu.direct_map && write_fault && !is_write_protection(vcpu) && !user_fault)) { + /* + * There are two cases: + * - the one is other vcpu creates new sp in the window + * between mapping_level() and acquiring mmu-lock. + * - the another case is the new sp is created by itself + * (page-fault path) when guest uses the target gfn as + * its page table. + * Both of these cases can be fixed by allowing guest to + * retry the access, it will refault, then we can establish + * the mapping by using small page. + */ if (level > PT_PAGE_TABLE_LEVEL && - has_wrprotected_page(vcpu->kvm, gfn, level)) { - ret = 1; - drop_spte(vcpu->kvm, sptep); + has_wrprotected_page(vcpu->kvm, gfn, level)) goto done; - } spte |= PT_WRITABLE_MASK | SPTE_MMU_WRITEABLE;