From mboxrd@z Thu Jan 1 00:00:00 1970 From: Avi Kivity Subject: Re: [PATCH RFC 4/5] KVM: add new members to the memory slot for double buffering of bitmaps Date: Sun, 11 Apr 2010 20:15:52 +0300 Message-ID: <4BC203C8.9010201@redhat.com> References: <20100409182732.857de4db.yoshikawa.takuya@oss.ntt.co.jp> <20100409183555.18a64dc7.yoshikawa.takuya@oss.ntt.co.jp> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: mtosatti@redhat.com, kvm@vger.kernel.org, fernando@oss.ntt.co.jp To: Takuya Yoshikawa Return-path: Received: from mx1.redhat.com ([209.132.183.28]:45200 "EHLO mx1.redhat.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752233Ab0DKRP6 (ORCPT ); Sun, 11 Apr 2010 13:15:58 -0400 In-Reply-To: <20100409183555.18a64dc7.yoshikawa.takuya@oss.ntt.co.jp> Sender: kvm-owner@vger.kernel.org List-ID: On 04/09/2010 12:35 PM, Takuya Yoshikawa wrote: > Currently, x86 vmalloc()s a dirty bitmap every time when we swich > to the next dirty bitmap. To avoid this, we use the double buffering > technique: we also move the bitmaps to userspace, so that extra > bitmaps will not use the precious kernel resource. > > This idea is based on Avi's suggestion. > > Please fold this into the next patch. Introducing new data members without their users is hard to follow. > #define KVM_MAX_VCPUS 64 > #define KVM_MEMORY_SLOTS 32 > /* memory slots that does not exposed to userspace */ > diff --git a/include/linux/kvm_host.h b/include/linux/kvm_host.h > index dd6bcf4..07092d6 100644 > --- a/include/linux/kvm_host.h > +++ b/include/linux/kvm_host.h > @@ -110,7 +110,13 @@ struct kvm_memory_slot { > unsigned long npages; > unsigned long flags; > unsigned long *rmap; > +#ifndef __KVM_HAVE_USER_DIRTYBITMAP > unsigned long *dirty_bitmap; > +#else > + unsigned long __user *dirty_bitmap; > + unsigned long __user *dirty_bitmap_old; > + bool is_dirty; > +#endif > And, if we make set_user_bit() generic, we don't need the ifdefs. -- I have a truly marvellous patch that fixes the bug which this signature is too narrow to contain.