Re: [RFC][PATCH 11/12] KVM: introduce new API for getting/switching dirty bitmaps
|[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]|
One alternative would be: KVM_SWITCH_DIRTY_LOG passing the address of a bitmap. If the active bitmap was clean, it returns 0, no switch performed. If the active bitmap was dirty, the kernel switches to the new bitmap and returns 1. And the responsability of cleaning the new bitmap could also be left for userspace.That is a beautiful approach but we can do that only when we give up using GET api. I follow you and Avi's advice about that kind of maintenance policy! What do you think?If you introduce a switch ioctl that frees the bitmap vmalloc'ed by the current set_memory_region (if its not freed already), after pointing the memslot to the user supplied one, it should be fine?
You mean switching from vmalloc'ed(not do_mmap'ed) one to user supplied one? It may be possible but makes things really complicated in my view: until some point we use set_bit, and then use set_bit_user, etc. IMO: - # of slots is limited and the size of dirty_bitmap_old pointer is not problematic. - Both user side and kernel side need not allocate buffers every time and once paired buffers are registered, we will reuse the buffers until user side orders to stop logging. - We have a tiny advantage if we need not copy_from_user to get a bitmap address for switch ioctl. => So I think having two __user bitmaps is not a bad thing. -- To unsubscribe from this list: send the line "unsubscribe kvm-ia64" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html