On Mon, 03 Dec 2012 16:39:05 -0700 Alex Williamson <alex.williamson@xxxxxxxxxx> wrote: > A couple notes/questions; in the previous version we had a > kvm_arch_flush_shadow() call when we increased the number of slots. > I'm not sure if this is still necessary. I had also made the x86 > specific slot_bitmap dynamically grow as well and switch between a > direct bitmap and indirect pointer to a bitmap. That may have > contributed to needing the flush. I haven't done that yet here > because it seems like an unnecessary complication if we have a max > on the order of 512 or 1024 entries. A bit per slot isn't a lot of > overhead. If we want to go more, maybe we should make it switch. I have a patch set which removes the slot_bitmap in kvm mmu page by using reverse mappings for write protecting a memslot. A bit of concern I still have is the total write protection time for large memslots. But since this approach allows us to control mmu_lock hold time, I think this is a reasonable trade-off. ... and this should be much better than introducing any complication for slot_bitmap handling. Thanks, 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
