Marcelo Tosatti wrote:
Why? The pte could have heen replaced (for example, a write access to a cow page).+ 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;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. -- To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
