On 06/28/2010 12:40 PM, Xiao Guangrong wrote:
Avi Kivity wrote:for_each_gfn_indirect_valid_sp(vcpu->kvm, s, gfn, node) { + if (!can_unsync) + return 1; +What if the page is already unsync? We don't need write protection in this case.Avi, The reason is when we sync children sps, we write-protected for all sps first, list relevant code: | static void mmu_sync_children(...) | { | ...... | for_each_sp(pages, sp, parents, i) | protected |= rmap_write_protect(vcpu->kvm, sp->gfn);<==== A | | if (protected) | kvm_flush_remote_tlbs(vcpu->kvm); | | for_each_sp(pages, sp, parents, i) { | kvm_sync_page(vcpu, sp,&invalid_list);<==== B | mmu_pages_clear_parents(&parents); | } | ...... |} For example: SP1.pte[0] = P SP2.gfn's pfn = P [SP1.pte[0] = SP2.gfn's pfn] At A point, SP1.gfn and SP2.gfn are write-protected. At B point, if sync SP1 first, while it's synced. it will detect SP1.pte[0].gfn only has one unsync-sp, that is SP2, so it will mapping it writable, then we sync SP2, we will set SP2 to sync page. The final result is: SP2 is the sync page but SP2.gfn is writable.
I think I see. So, after A, the pages are write protected, but are still marked as unsync. In B, we're testing SP2->unsync, which we plan to sync soon, but haven't yet. So the test for s->unsync is incorrect.
So the patch is right. Thanks for the explanation. Please update the changelog to note that sp->unsync is not reliable during resync, this is tricky stuff.
-- error compiling committee.c: too many arguments to function -- To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
