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
[email protected]
https://lists.sourceforge.net/lists/listinfo/kvm-devel
