Subject: Re: [PATCH 08/11] KVM: MMU: use page track for non-leaf shadow pages
To: Kai Huang <kai.huang@linux.intel.com>, pbonzini@redhat.com
References: <1448907973-36066-1-git-send-email-guangrong.xiao@linux.intel.com>
 <1448907973-36066-9-git-send-email-guangrong.xiao@linux.intel.com>
 <566FC6B8.9010008@linux.intel.com>
Cc: gleb@kernel.org, mtosatti@redhat.com, kvm@vger.kernel.org,
        linux-kernel@vger.kernel.org
From: Xiao Guangrong <guangrong.xiao@linux.intel.com>
Message-ID: <566FD902.4040306@linux.intel.com>
Date: Tue, 15 Dec 2015 17:10:26 +0800
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101
 Thunderbird/38.4.0
MIME-Version: 1.0
In-Reply-To: <566FC6B8.9010008@linux.intel.com>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 7bit
Sender: linux-kernel-owner@vger.kernel.org
Content-Length: 2749
Lines: 62


On 12/15/2015 03:52 PM, Kai Huang wrote:

>>   static bool __mmu_gfn_lpage_is_disallowed(gfn_t gfn, int level,
>> @@ -2140,12 +2150,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);
> I think your modification is good but I am little bit confused here. In account_shadowed, if
> sp->role.level > PT_PAGE_TABLE_LEVEL, the sp->gfn is write protected, and this is reasonable. So why
> write protecting the gfn of PT_PAGE_TABLE_LEVEL here?

Because the shadow page will become 'sync' that means the shadow page will be synced
with the page table in guest. So the shadow page need to be write-protected to avoid
the guest page table is changed when we do the 'sync' thing.

The shadow page need to be write-protected to avoid that guest page table is changed
when we are syncing the shadow page table. See kvm_sync_pages() after doing
rmap_write_protect().

>>   /*
>>    * remove the guest page from the tracking pool which stops the interception
>>    * of corresponding access on that page. It is the opposed operation of
>> @@ -134,20 +160,12 @@ void kvm_page_track_remove_page(struct kvm *kvm, gfn_t gfn,
>>       struct kvm_memory_slot *slot;
>>       int i;
>> -    WARN_ON(!check_mode(mode));
>> -
>>       for (i = 0; i < KVM_ADDRESS_SPACE_NUM; i++) {
>>           slots = __kvm_memslots(kvm, i);
>>           slot = __gfn_to_memslot(slots, gfn);
>>           spin_lock(&kvm->mmu_lock);
>> -        update_gfn_track(slot, gfn, mode, -1);
>> -
>> -        /*
>> -         * allow large page mapping for the tracked page
>> -         * after the tracker is gone.
>> -         */
>> -        kvm_mmu_gfn_allow_lpage(slot, gfn);
>> +        kvm_slot_page_track_remove_page_nolock(kvm, slot, gfn, mode);
> Looks you need to merge this part with patch 1, as you are modifying
> kvm_page_track_{add,remove}_page here, which are introduced in your patch 1.

Indeed, it is better.

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/