Re: large page support for kvm

[Avi Kivity <avi@qumranet.com>]

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/