From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1LBwMd-000376-9H for qemu-devel@nongnu.org; Sun, 14 Dec 2008 14:10:51 -0500 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1LBwMc-00036i-DB for qemu-devel@nongnu.org; Sun, 14 Dec 2008 14:10:50 -0500 Received: from [199.232.76.173] (port=52340 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1LBwMc-00036f-6y for qemu-devel@nongnu.org; Sun, 14 Dec 2008 14:10:50 -0500 Received: from yw-out-1718.google.com ([74.125.46.157]:3205) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1LBwMb-0006XO-SG for qemu-devel@nongnu.org; Sun, 14 Dec 2008 14:10:50 -0500 Received: by yw-out-1718.google.com with SMTP id 6so1079118ywa.82 for ; Sun, 14 Dec 2008 11:10:48 -0800 (PST) Message-ID: <49455A33.207@codemonkey.ws> Date: Sun, 14 Dec 2008 13:10:43 -0600 From: Anthony Liguori MIME-Version: 1.0 Subject: Re: [Qemu-devel] Re: [PATCH 2 of 5] add can_dma/post_dma for direct IO References: <4942B841.6010900@codemonkey.ws> <4942BDEE.7020003@codemonkey.ws> <49437EC8.6020506@redhat.com> <4943E68E.3030400@codemonkey.ws> <4944117C.6030404@redhat.com> <49442410.7020608@codemonkey.ws> <4944A1B5.5080300@redhat.com> In-Reply-To: <4944A1B5.5080300@redhat.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Reply-To: qemu-devel@nongnu.org List-Id: qemu-devel.nongnu.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Avi Kivity Cc: Andrea Arcangeli , chrisw@redhat.com, qemu-devel@nongnu.org, kvm@vger.kernel.org, Gerd Hoffmann Avi Kivity wrote: > Anthony Liguori wrote: >>> >>> There are N users of this code, all of which would need to cope with >>> the >>> failure. Or there could be one user (dma.c) which handles the failure >>> and the bouncing. >>> >> >> N should be small long term. It should only be for places that would >> interact directly with CPU memory. This would be the PCI BUS, the >> ISA BUS, some speciality devices, and possibly virtio (although you >> could argue it should go through the PCI BUS). > > Fine, then let's rename it pci-dma.c. Better, but then it should be part of pci.c. I've thought quite a bit about it, and I'm becoming less convinced that this sort of API is going to be helpful. I was thinking that we need to make one minor change to the map API I proposed. It should return a mapped size as an output parameter and take a flag as to whether partial mappings can be handled. The effect would be that you never bounce to RAM which means that you can also quite accurately determine the maximum amount of bouncing (it should be proportional to the amount of MMIO memory that's registered). For virtio, I think the only change that we would make it to replace the existing bouncing code with calls to map()/unmap() for each scatter/gather array. You may need to cope with a scatter/gather list that is larger than the inputted vector but that's easy. This means you always map complete requests which is where I think it fundamentally differs from what you propose. However, this is safe because you should be able to guarantee that you can always bounce the MMIO memory at least once. The only place where you could run into trouble is if the same MMIO page is mapped multiple times in a single scatter/gather. You could, in theory, attempt to cache MMIO bouncing but that's probably unnecessary. So virtio would not need this dma API. I think the same is true about IDE/SCSI. I think we can built code that relies on being able to completely map a scatter/gather list as long as we make the map function sufficiently smart. As long as our bounce pool is as large as the registered MMIO memory, we can always be safe is we're sufficiently clever. Xen is a more difficult case but I'm perfectly willing to punt that to them to figure out. Regards, Anthony Liguori