Re: [patch 3/3] KVM: MMU: prepopulate the shadow on invlpg

[Avi Kivity <avi@redhat.com>]

Marcelo Tosatti wrote:
>>> +		sw->pte_gpa = (sp->gfn << PAGE_SHIFT);
>>> +		sw->pte_gpa += (sptep - sp->spt) * sizeof(pt_element_t);
>>> +
>>> +		if (is_shadow_present_pte(*sptep)) {
>>>  			rmap_remove(vcpu->kvm, sptep);
>>> +			sw->pte_gpa = -1;
>>>   
>>>       
>> Why?  The pte could have heen replaced (for example, a write access to a  
>> cow page).
>>     
>
> Well look-aheads on address space teardown will be useless. OTOH the
> guest pte read cost is minimal compared to an exit.
>   

Don't understand.  We will incur an exit if a pte is replaced and 
invlpg'ed due to a copy-on-write (do guests actually execute invlpg 
after a cow? I don't think they have to).

What is the downside?  A pagetable teardown that does not involve 
zeroing the page?  I don't think we'll see invlpg on that path, more 
likely a complete tlb flush.

> Whatever you prefer. Learning guest behaviour as suggested earlier would 
> be optimal, but simple is good.
>   

We're way past simple.  We can reclaim some of the complexity by always 
doing unsync, and dropping emulation and kvm_mmu_set_pte(), but need to 
make sure we don't regress on performance.  I think Windows does a pde 
write on context switch, which will add a vmexit, but Windows 
applications are not too context switch intensive AFAIK.

-- 
I have a truly marvellous patch that fixes the bug which this
signature is too narrow to contain.