On Tue, 2012-12-04 at 23:48 +0900, Takuya Yoshikawa wrote: > 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. Great! A bi-modal bitmap would be rather ugly, so I look forward to your patches to remove it entirely ;) Thanks, Alex -- 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
