From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1MbWcU-00084S-OV for qemu-devel@nongnu.org; Thu, 13 Aug 2009 05:29:14 -0400 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1MbWcQ-00080a-29 for qemu-devel@nongnu.org; Thu, 13 Aug 2009 05:29:13 -0400 Received: from [199.232.76.173] (port=58231 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1MbWcP-00080H-PR for qemu-devel@nongnu.org; Thu, 13 Aug 2009 05:29:09 -0400 Received: from mx20.gnu.org ([199.232.41.8]:21861) by monty-python.gnu.org with esmtps (TLS-1.0:RSA_AES_256_CBC_SHA1:32) (Exim 4.60) (envelope-from ) id 1MbWcP-00047S-BC for qemu-devel@nongnu.org; Thu, 13 Aug 2009 05:29:09 -0400 Received: from mx2.redhat.com ([66.187.237.31]) by mx20.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1MbWcO-0004bQ-AN for qemu-devel@nongnu.org; Thu, 13 Aug 2009 05:29:08 -0400 Message-ID: <4A83DCD4.9040705@redhat.com> Date: Thu, 13 Aug 2009 12:28:52 +0300 From: Avi Kivity MIME-Version: 1.0 Subject: Re: [Qemu-devel] Re: [PATCH] qemu/virtio: move features to an inline function References: <20090810194753.GA16803@redhat.com> <4A808437.8040307@codemonkey.ws> <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> In-Reply-To: <20090813061522.GD3029@redhat.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit List-Id: qemu-devel.nongnu.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: "Michael S. Tsirkin" Cc: rusty@rustcorp.com.au, qemu-devel@nongnu.org, virtualization@lists.linux-foundation.org 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 - 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 -- error compiling committee.c: too many arguments to function