Marcelo Tosatti wrote: > >>> + /* >>> + * Largepage creation is susceptible to a upper-level >>> + * table to be shadowed and write-protected in the >>> + * area being mapped. If that is the case, invalidate >>> + * the entry and let the instruction fault again >>> + * and use 4K mappings. >>> + */ >>> + if (largepage) { >>> + spte = shadow_trap_nonpresent_pte; >>> + kvm_x86_ops->tlb_flush(vcpu); >>> + goto unshadowed; >>> + } >>> >>> >> Would it not repeat exactly the same code path? Or is this just for the >> case of the pte_update path? >> > > The problem is if the instruction writing to one of the roots can't be > emulated. > > kvm_mmu_unprotect_page() does not know about largepages, so it will zap > a gfn inside the large page frame, but not the large translation itself. > > And zapping the gfn brings the shadowed page count in large area to > zero, allowing has_wrprotected_page() to succeed. Endless unfixable > write faults. > >
I don't follow. Can you describe the scenario in more detail? The state of the guest and shadow page tables, and what actually happens? Setting spte to a nonpresent pte seems to violate the rmap btw; rmap always expects a valid pte pointing at the page. -- Any sufficiently difficult bug is indistinguishable from a feature. ------------------------------------------------------------------------- This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/ _______________________________________________ kvm-devel mailing list kvm-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/kvm-devel