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" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
