v1->v2: Patch 5 and 7 are added based on Paolo's suggestions. Patch 8-10 are new. Patch 1/2/3/4: no change. Patch 5: Needed a bit more work than I had expected. Patch 6: Removed extra comment of v1 (patch 5 made it inappropriate). Patch 7: As expected, many places needed to be converted. Patch 8: This is new, but only a small change. Patch 9: Kind of an RFC (though I have checked it to some extent). Following two places need to be carefully checked: - in kvm_mmu_get_page: "if (!direct)" block after kvm_mmu_alloc_page() - in FNAME(fetch): "if (FNAME(gpte_changed)(vcpu, gw, it.level - 1))" case Patch 10: Trivial cleanup, assuming that patch 9 is correct. In summary: patch 1-7 is the result of updating v1 based on the suggestions. Although patch 5 does not look so nice than expected, this is the most conservative approach, and patch 8-10 try to alleviate the sadness. Takuya Takuya Yoshikawa (10): 01: KVM: x86: MMU: Remove unused parameter of __direct_map() 02: KVM: x86: MMU: Add helper function to clear a bit in unsync child bitmap 03: KVM: x86: MMU: Make mmu_set_spte() return emulate value 04: KVM: x86: MMU: Remove is_rmap_spte() and use is_shadow_present_pte() 05: KVM: x86: MMU: Use for_each_rmap_spte macro instead of pte_list_walk() 06: KVM: x86: MMU: Consolidate WARN_ON/BUG_ON checks for reverse-mapped sptes 07: KVM: x86: MMU: Encapsulate the type of rmap-chain head in a new struct 08: KVM: x86: MMU: Move initialization of parent_ptes out from kvm_mmu_alloc_page() 09: KVM: x86: MMU: Move parent_pte handling from kvm_mmu_get_page() to link_shadow_page() 10: KVM: x86: MMU: Remove unused parameter parent_pte from kvm_mmu_get_page() Documentation/virtual/kvm/mmu.txt | 4 +- arch/x86/include/asm/kvm_host.h | 8 +- arch/x86/kvm/mmu.c | 357 ++++++++++++++++++-------------------- arch/x86/kvm/mmu_audit.c | 15 +- arch/x86/kvm/paging_tmpl.h | 20 +-- 5 files changed, 196 insertions(+), 208 deletions(-) -- 2.1.0 -- 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
