From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1LBDpf-0008OU-ER for qemu-devel@nongnu.org; Fri, 12 Dec 2008 14:37:51 -0500 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1LBDpe-0008Nw-30 for qemu-devel@nongnu.org; Fri, 12 Dec 2008 14:37:51 -0500 Received: from [199.232.76.173] (port=41883 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1LBDpd-0008Nm-Tk for qemu-devel@nongnu.org; Fri, 12 Dec 2008 14:37:49 -0500 Received: from mx2.redhat.com ([66.187.237.31]:58072) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1LBDpd-00036g-DC for qemu-devel@nongnu.org; Fri, 12 Dec 2008 14:37:49 -0500 Date: Fri, 12 Dec 2008 20:37:43 +0100 From: Andrea Arcangeli Message-ID: <20081212193743.GC30537@random.random> References: <4942B841.6010900@codemonkey.ws> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4942B841.6010900@codemonkey.ws> Subject: [Qemu-devel] Re: [PATCH 2 of 5] add can_dma/post_dma for direct IO Reply-To: qemu-devel@nongnu.org List-Id: qemu-devel.nongnu.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Anthony Liguori Cc: chrisw@redhat.com, avi@redhat.com, Gerd Hoffmann , kvm@vger.kernel.org, qemu-devel@nongnu.org On Fri, Dec 12, 2008 at 01:15:13PM -0600, Anthony Liguori wrote: > 1) You attempt to map a physical address. This effectively is a lock or > pin operation. lock or pin for what? There's nothing to pin or lock here. Perhaps one day we'll have to lock or pin against something, dunno, then we'll add whatever pin or lock, otherwise why don't we also thread qcow2 while we're at it, sounds more worth it than adding a lock or pin that isn't actually needed. > a) In the process of this, you get a virtual address that you can > manipulate. That's what can_dma does. If it can, it generates a dma address backed by ram it does. But if it can't, it won't. This only works for direct I/O. > 2) You do your IO to the virtual address This is done by dma.c. > 3) You indicate how much of the memory you have dirtied That is done by the post_dma handler called by dma.c. > 4) You unmap or unlock that memory region. The virtual address is now no > longer valid. Again not needed. > This could correspond to a: > > void *cpu_physical_memory_map(target_phys_addr_t addr, ram_addr_t size, int > is_write); > > void cpu_physical_memory_unmap(target_physical_addr_t addr, ram_addr_t > size, void *mapping, int is_dirty); So you mean renaming can_dma to map and post_dma to unmap and not adding any lock/pin at all that would otherwise gratuitously slow it down? I've no idea why you should ever want to call any unmap for reads though... and calling it with your naming conventions, and not invoking it for reads (there's absolutely no good reason to invoke any unmap methods for reads, and it can only hurt at runtime) would be weird in my view.