From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([208.118.235.92]:34728) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1TiSle-0001in-Mt for qemu-devel@nongnu.org; Tue, 11 Dec 2012 11:33:21 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1TiSlY-00052o-Eh for qemu-devel@nongnu.org; Tue, 11 Dec 2012 11:33:14 -0500 Received: from e36.co.us.ibm.com ([32.97.110.154]:57233) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1TiSlY-00052R-92 for qemu-devel@nongnu.org; Tue, 11 Dec 2012 11:33:08 -0500 Received: from /spool/local by e36.co.us.ibm.com with IBM ESMTP SMTP Gateway: Authorized Use Only! Violators will be prosecuted for from ; Tue, 11 Dec 2012 09:33:04 -0700 Received: from d03relay03.boulder.ibm.com (d03relay03.boulder.ibm.com [9.17.195.228]) by d03dlp03.boulder.ibm.com (Postfix) with ESMTP id B31AF19D8048 for ; Tue, 11 Dec 2012 09:33:00 -0700 (MST) Received: from d03av03.boulder.ibm.com (d03av03.boulder.ibm.com [9.17.195.169]) by d03relay03.boulder.ibm.com (8.13.8/8.13.8/NCO v10.0) with ESMTP id qBBGWipS157308 for ; Tue, 11 Dec 2012 09:32:44 -0700 Received: from d03av03.boulder.ibm.com (loopback [127.0.0.1]) by d03av03.boulder.ibm.com (8.14.4/8.13.1/NCO v10.0 AVout) with ESMTP id qBBGWhoj019581 for ; Tue, 11 Dec 2012 09:32:43 -0700 From: Anthony Liguori In-Reply-To: <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> <20121211154258.GA20251@redhat.com> Date: Tue, 11 Dec 2012 10:32:28 -0600 Message-ID: <87d2ygpn1f.fsf@codemonkey.ws> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii 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: "Michael S. Tsirkin" , Stefan Hajnoczi Cc: Kevin Wolf , qemu-devel , Blue Swirl , Khoa Huynh , Stefan Hajnoczi , Paolo Bonzini , Asias He "Michael S. Tsirkin" writes: > 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 ... Let's not lose sight of the forest for the trees here... This whole series is not reusing existing code. That's really the whole point. The point is to take the code (duplication and all) and then do all of the refactoring to use common code in the tree itself. If we want to put this in a hw/staging/ directory, that's fine by me too. Regards, Anthony Liguori > > -- > MST