Re: [RFC][PATCH 11/12] KVM: introduce new API for getting/switchingdirty bitmaps

[Takuya Yoshikawa]

> > > 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 linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/