From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1MbX0T-00042b-WD for qemu-devel@nongnu.org; Thu, 13 Aug 2009 05:54:02 -0400 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1MbX0P-0003zv-4D for qemu-devel@nongnu.org; Thu, 13 Aug 2009 05:54:01 -0400 Received: from [199.232.76.173] (port=56608 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1MbX0O-0003zn-VK for qemu-devel@nongnu.org; Thu, 13 Aug 2009 05:53:56 -0400 Received: from mx2.redhat.com ([66.187.237.31]:36812) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1MbX0O-00017N-1A for qemu-devel@nongnu.org; Thu, 13 Aug 2009 05:53:56 -0400 Date: Thu, 13 Aug 2009 12:51:54 +0300 From: "Michael S. Tsirkin" Subject: Re: [Qemu-devel] Re: [PATCH] qemu/virtio: move features to an inline function Message-ID: <20090813095154.GA4769@redhat.com> References: <20090810221940.GB17099@redhat.com> <4A80A0A1.2020905@codemonkey.ws> <20090811084807.GA3029@redhat.com> <4A816EEB.4070707@codemonkey.ws> <20090811134331.GA22661@redhat.com> <4A819780.4040002@codemonkey.ws> <20090811162537.GA25705@redhat.com> <4A83157C.9040009@codemonkey.ws> <20090813061522.GD3029@redhat.com> <4A83DCD4.9040705@redhat.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4A83DCD4.9040705@redhat.com> List-Id: qemu-devel.nongnu.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Avi Kivity Cc: rusty@rustcorp.com.au, qemu-devel@nongnu.org, virtualization@lists.linux-foundation.org On Thu, Aug 13, 2009 at 12:28:52PM +0300, Avi Kivity wrote: > On 08/13/2009 09:15 AM, Michael S. Tsirkin wrote: >> >>> I wonder though if mmu notifiers can be used to make it transparent... >>> >> >> Maybe they can, but that decision belongs to KVM. >> Avi, what do you think? >> >> > > I don't see how mmu notifiers help. You can use mmu notifiers to sync > an external mmu to the linux pagetables, but that's not the case here. > > I see the following options: > > - mprotect() guest memory, trap faults, mprotect() back > > Will work, but exceedingly slowly and wastefully I think this is what Anthony had in mind. > - add a generic user visible dirty bit tracking based on linux ptes > > A lot of work, not sure if useful beyond kvm > > - implement vhost dirty bit tracking > > Not too difficult; not sure if it's worth the effort though > > - reuse the kvm dirty bitmap > > Not too difficult but introduces tight coupling between vhost and kvm > which might slow down development > > - drop to userspace for live migration > > Reuse qemu code, lose some performance This is what I planned. Note that ability to drop to userspace is required for non-MSI mode, anyway. > -- > error compiling committee.c: too many arguments to function