From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([208.118.235.92]:51737) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1TiRw7-0007eQ-RH for qemu-devel@nongnu.org; Tue, 11 Dec 2012 10:40:08 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1TiRw0-0005bQ-Fz for qemu-devel@nongnu.org; Tue, 11 Dec 2012 10:39:59 -0500 Received: from mx1.redhat.com ([209.132.183.28]:47702) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1TiRw0-0005aO-6d for qemu-devel@nongnu.org; Tue, 11 Dec 2012 10:39:52 -0500 Date: Tue, 11 Dec 2012 17:42:58 +0200 From: "Michael S. Tsirkin" Message-ID: <20121211154258.GA20251@redhat.com> References: <1355144985-12897-1-git-send-email-stefanha@redhat.com> <1355144985-12897-4-git-send-email-stefanha@redhat.com> <20121211141340.GA18753@redhat.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: Subject: Re: [Qemu-devel] [PATCH v6 03/12] dataplane: add host memory mapping code List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Stefan Hajnoczi Cc: Kevin Wolf , Anthony Liguori , qemu-devel , Blue Swirl , Khoa Huynh , Stefan Hajnoczi , Paolo Bonzini , Asias He On Tue, Dec 11, 2012 at 04:27:49PM +0100, Stefan Hajnoczi wrote: > On Tue, Dec 11, 2012 at 3:13 PM, Michael S. Tsirkin wrote: > > On Mon, Dec 10, 2012 at 02:09:36PM +0100, Stefan Hajnoczi wrote: > >> The data plane thread needs to map guest physical addresses to host > >> pointers. Normally this is done with cpu_physical_memory_map() but the > >> function assumes the global mutex is held. The data plane thread does > >> not touch the global mutex and therefore needs a thread-safe memory > >> mapping mechanism. > >> > >> Hostmem registers a MemoryListener similar to how vhost collects and > >> pushes memory region information into the kernel. There is a > >> fine-grained lock on the regions list which is held during lookup and > >> when installing a new regions list. > > > > Can we export and reuse the vhost code for this? > > I think you will find this advantageous when you add migration > > support down the line. > > And if you find it necessary to use MemoryListener e.g. for performance > > reasons, then vhost will likely benefit too. > > It's technically possible and not hard to do but it prevents > integrating deeper with core QEMU as the memory API becomes > thread-safe. > > There are two ways to implement dirty logging: > 1. The vhost log approach which syncs dirty information periodically. > 2. A cheap thread-safe way to mark dirty outside the global mutex, > i.e. a thread-safe memory_region_set_dirty(). You don't normally want to dirty the whole region, you want to do this to individual pages. > If we can get thread-safe guest memory load/store in QEMU then #2 is > included. We can switch to using hw/virtio.c instead of > hw/dataplane/vring.c, we get dirty logging for free, we can drop > hostmem.c completely, etc. > > Stefan So why not reuse existing code? If you drop it later it won't matter what you used ... -- MST