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

Avi Kivity
2008-10-31T19:58:09Z

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.