From mboxrd@z Thu Jan 1 00:00:00 1970 From: Takuya Yoshikawa Date: Wed, 12 May 2010 05:59:58 +0000 Subject: Re: [RFC][PATCH 11/12] KVM: introduce new API for getting/switching Message-Id: <4BEA44B8.7050409@oss.ntt.co.jp> List-Id: References: <20100504220821.d68bde57.takuya.yoshikawa@gmail.com> In-Reply-To: <20100504220821.d68bde57.takuya.yoshikawa@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit To: kvm-ia64@vger.kernel.org >>> 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.