[Dropped non-kvm members from cc] Marcelo Tosatti <mtosatti@xxxxxxxxxx> wrote: > VGABIOS mode constantly destroys and creates 0xa0000 slot, so > performance is required for KVM_SET_MEM too (it can probably be fixed in > qemu, but older qemu's must be supported). Apart from srcu, I see some problems concerning slot creation/destruction: heavy shadow flush (and extra write protection). Look at __kvm_set_memory_region(). 1. When we invalidate a memory slot, we call kvm_arch_flush_shadow() and zap all shadow pages, not restricted to that slot. /* From this point no new shadow pages pointing to a deleted * memslot will be created. * * validation of sp->gfn happens in: * - gfn_to_hva (kvm_read_guest, gfn_to_pfn) * - kvm_is_visible_gfn (mmu_check_roots) */ kvm_arch_flush_shadow(kvm); 2. When we create(and shift?) a memory slot, we call kvm_arch_flush_shadow() to clear all mmio sptes, again not restricted to that slot. /* * If the new memory slot is created, we need to clear all * mmio sptes. */ if (npages && old.base_gfn != mem->guest_phys_addr >> PAGE_SHIFT) kvm_arch_flush_shadow(kvm); 3. In addition to these, we do write-protect all pages in that slot in kvm_arch_commit_memory_region() every time. For 1: I made a patch to restrict the flush to that slot by using sp->slot_bitmap. (seems working here) For 2: I think we can do the same: not 100% sure yet because I am still struggling with the "mmio spte optimization" code. (really hacky ...) For 3: I think doing both "write protection" and "shadow flush" is unnecessary. BTW do we really need fast slot creation/destruction? Takuya -- To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
