From mboxrd@z Thu Jan  1 00:00:00 1970
From: Avi Kivity <avi@redhat.com>
Subject: Re: [RFC] Moving dirty bitmaps to userspace - Double buffering approach
Date: Mon, 15 Mar 2010 10:49:21 +0200
Message-ID: <4B9DF491.5010805@redhat.com>
References: <4B94B3D3.2010801@oss.ntt.co.jp> <20100315083306.GA30179@amt.cnet>
Mime-Version: 1.0
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
Cc: Takuya Yoshikawa <yoshikawa.takuya@oss.ntt.co.jp>,
	kvm@vger.kernel.org
To: Marcelo Tosatti <mtosatti@redhat.com>
Return-path: <kvm-owner@vger.kernel.org>
Received: from mx1.redhat.com ([209.132.183.28]:13821 "EHLO mx1.redhat.com"
	rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP
	id S935787Ab0COIt2 (ORCPT <rfc822;kvm@vger.kernel.org>);
	Mon, 15 Mar 2010 04:49:28 -0400
In-Reply-To: <20100315083306.GA30179@amt.cnet>
Sender: kvm-owner@vger.kernel.org
List-ID: <kvm.vger.kernel.org>

On 03/15/2010 10:33 AM, Marcelo Tosatti wrote:
>
>> Are there any good ways to solve this kind of problems?
>>      
> You can introduce a new get_dirty_log ioctl that passes the address
> of the next bitmap in userspace, and use it (after pinning with
> get_user_pages), instead of vmalloc'ing.
>
>    

No pinning please, put_user_bit() or set_bit_user().

(can be implemented generically using get_user_pages() and 
kmap_atomic(), but x86 should get an optimized implementation)

-- 
Do not meddle in the internals of kernels, for they are subtle and quick to panic.