From mboxrd@z Thu Jan 1 00:00:00 1970 From: Avi Kivity Subject: Re: [RFC] Moving dirty bitmaps to userspace - Double buffering approach Date: Mon, 08 Mar 2010 14:57:13 +0200 Message-ID: <4B94F429.9030101@redhat.com> References: <4B94B3D3.2010801@oss.ntt.co.jp> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: kvm@vger.kernel.org, Marcelo Tosatti To: Takuya Yoshikawa Return-path: Received: from mx1.redhat.com ([209.132.183.28]:48038 "EHLO mx1.redhat.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751497Ab0CHM5R (ORCPT ); Mon, 8 Mar 2010 07:57:17 -0500 In-Reply-To: <4B94B3D3.2010801@oss.ntt.co.jp> Sender: kvm-owner@vger.kernel.org List-ID: On 03/08/2010 10:22 AM, Takuya Yoshikawa wrote: > Hi, I would like to hear your comments about the following plan: > > Moving dirty bitmaps to userspace > - Double buffering approach > > especially I would be glad if I can hear some advice about how > to keep the compatibility. > > Thanks in advance, > Takuya > > > --- > Overview: > > Last time, I submitted a patch > "make get dirty log ioctl return the first dirty page's position" > http://www.spinics.net/lists/kvm/msg29724.html > and got some new better ideas from Avi. > > As a result, I agreed to try to eliminate the bitmap allocation > done in the x86 KVM every time when we execute get dirty log by > using "double buffering" approach. > > [...] > Although it may be possible to touch the bitmap from the kernel > side without doing kmap, I think kmapping the bitmap is better. > So we may use the following functions paying enough attention to > the preemption control. > - get_user_pages() > - kmap_atomic() Although direct access is more difficult (you need to implement put_user_bit() or similar) I think it is worthwhile. get_user_pages_fast() is fast, but nowhere near as fast as put_user_bit() (or set_bit_user()), which can be just two instructions in the fast path. > > - compatibility issues > > What I am facing now are the compatibility issues. We have to > support both the userspace and kernel side bitmap allocations > to let the current qemu and KVM work properly. > > 1. From the kernel side, we have to care bitmap allocations done in both > the kvm_vm_ioctl_set_memory_region() and kvm_vm_ioctl_get_dirty_log(). One way to handle this is to call do_mmap() from the kernel, so that now the bitmap really lives in user space. This is a bit ugly but I think acceptable. We already do this for KVM_SET_MEMORY_REGION (which was replaced by KVM_SET_USER_MEMORY_REGION, which moved allocation to userspace). > > 2. From the userspace side, we have to check the new api's availability > and determine which way we use, e.g. by using check extension ioctl. > > The most problematic is 1, kernel side. We have to be able to know > by which way current bitmap allocation is being done using flags or > something. In the case of set memory region, we have to judge whether > we allocate a bitmap, and if not we have to register a bitmap later > by another api: set memory region is not restricted to the dirty log > issues and need more care than get dirty log. > > Are there any good ways to solve this kind of problems? I believe that do_mmap() will simplify this. -- error compiling committee.c: too many arguments to function