From mboxrd@z Thu Jan 1 00:00:00 1970 From: Anthony Liguori Subject: Re: [PATCH 2 of 5] add can_dma/post_dma for direct IO Date: Fri, 12 Dec 2008 14:09:10 -0600 Message-ID: <4942C4E6.7080806@codemonkey.ws> References: <4942B841.6010900@codemonkey.ws> <20081212193743.GC30537@random.random> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Gerd Hoffmann , qemu-devel@nongnu.org, kvm@vger.kernel.org, avi@redhat.com, chrisw@redhat.com To: Andrea Arcangeli Return-path: Received: from yx-out-2324.google.com ([74.125.44.28]:54223 "EHLO yx-out-2324.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751267AbYLLUJQ (ORCPT ); Fri, 12 Dec 2008 15:09:16 -0500 Received: by yx-out-2324.google.com with SMTP id 8so757740yxm.1 for ; Fri, 12 Dec 2008 12:09:15 -0800 (PST) In-Reply-To: <20081212193743.GC30537@random.random> Sender: kvm-owner@vger.kernel.org List-ID: Andrea Arcangeli wrote: > 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. > Please try to understand what people are suggesting to you. I have no idea why you bring up threading qcow2. This is not a topic that hasn't been discussed at great length before. You didn't even fix any of the comments people made against the series since the last time you posted it. >> 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. > No, can_dma does two things in one. It checks to see if there physical region is MMIO, and it returns phys_ram_base + PA otherwise. This is not helpful though in the general case. It's not an API that extends well for things like memory hotplug, etc. If we're not building APIs for the future, what's the point of this exercise in the first place? virtio already has the bits to do zero-copy memory transfers. Regards, Anthony Liguori From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1LBEK5-0000bM-PB for qemu-devel@nongnu.org; Fri, 12 Dec 2008 15:09:17 -0500 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1LBEK4-0000af-Oi for qemu-devel@nongnu.org; Fri, 12 Dec 2008 15:09:17 -0500 Received: from [199.232.76.173] (port=55796 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1LBEK4-0000aZ-KN for qemu-devel@nongnu.org; Fri, 12 Dec 2008 15:09:16 -0500 Received: from yx-out-1718.google.com ([74.125.44.158]:24629) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1LBEK4-00071m-8W for qemu-devel@nongnu.org; Fri, 12 Dec 2008 15:09:16 -0500 Received: by yx-out-1718.google.com with SMTP id 3so746921yxi.82 for ; Fri, 12 Dec 2008 12:09:15 -0800 (PST) Message-ID: <4942C4E6.7080806@codemonkey.ws> Date: Fri, 12 Dec 2008 14:09:10 -0600 From: Anthony Liguori MIME-Version: 1.0 References: <4942B841.6010900@codemonkey.ws> <20081212193743.GC30537@random.random> In-Reply-To: <20081212193743.GC30537@random.random> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit 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: Andrea Arcangeli Cc: chrisw@redhat.com, avi@redhat.com, Gerd Hoffmann , kvm@vger.kernel.org, qemu-devel@nongnu.org Andrea Arcangeli wrote: > 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. > Please try to understand what people are suggesting to you. I have no idea why you bring up threading qcow2. This is not a topic that hasn't been discussed at great length before. You didn't even fix any of the comments people made against the series since the last time you posted it. >> 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. > No, can_dma does two things in one. It checks to see if there physical region is MMIO, and it returns phys_ram_base + PA otherwise. This is not helpful though in the general case. It's not an API that extends well for things like memory hotplug, etc. If we're not building APIs for the future, what's the point of this exercise in the first place? virtio already has the bits to do zero-copy memory transfers. Regards, Anthony Liguori