From mboxrd@z Thu Jan 1 00:00:00 1970 From: Avi Kivity Subject: Re: [Qemu-devel] Re: [PATCH 2 of 5] add can_dma/post_dma for direct IO Date: Sat, 13 Dec 2008 21:48:12 +0200 Message-ID: <4944117C.6030404@redhat.com> References: <4942B841.6010900@codemonkey.ws> <4942BDEE.7020003@codemonkey.ws> <49437EC8.6020506@redhat.com> <4943E68E.3030400@codemonkey.ws> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: qemu-devel@nongnu.org, Andrea Arcangeli , chrisw@redhat.com, Gerd Hoffmann , kvm@vger.kernel.org To: Anthony Liguori Return-path: Received: from mx2.redhat.com ([66.187.237.31]:39825 "EHLO mx2.redhat.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1750919AbYLMTsX (ORCPT ); Sat, 13 Dec 2008 14:48:23 -0500 In-Reply-To: <4943E68E.3030400@codemonkey.ws> Sender: kvm-owner@vger.kernel.org List-ID: Anthony Liguori wrote: >> >> - DMA into mmio regions; this requires bouncing > > The map() API I proposed above should do bouncing to MMIO regions. To > deal with unbounded allocation, you can simply fail when the mapping > allocation has reached some high limit. Calling code needs to cope > with the fact that map'ing may succeed or fail. 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. dma.c _is_ a map/unmap api, except it doesn't expose the mapped data, which allows it to control scheduling as well as be easier to use. > >> - DMA with an associated transform (xor, byteswap); also requires >> bouncing > > At this layer of the API, this is unnecessary. At the PCI layer, you > would need to handle this and I'd suggest taking the same approach as > above. I agree to _map()/_unmap(), but it's not a solution by itself. > >> In turn, bouncing requires splitting large requests to avoid >> unbounded memory allocation. >> >> While I think _map/_unmap is an improvement over can_dma(), this API >> can't handle bounded bouncing, and so a separate layer (dma.c) is >> still necessary. > > I think it can handled bounded bouncing fine. It's a matter of > ensuring the bounce buffer max is sufficiently large and ensuring that > any client code can cope with map failures. In fact, there probably > needs to be a notifiers API that is invoked whenever an unmap() > happens so that if an asynchronous request is waiting because of a map > failure, it can be notified as to when it should try again. Right, but who would it notify? We need some place that can deal with this, and it isn't _map()/_unmap(), and it isn't ide.c or scsi.c. -- Do not meddle in the internals of kernels, for they are subtle and quick to panic. From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1LBaTQ-00056S-Vo for qemu-devel@nongnu.org; Sat, 13 Dec 2008 14:48:25 -0500 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1LBaTP-00056F-Rg for qemu-devel@nongnu.org; Sat, 13 Dec 2008 14:48:24 -0500 Received: from [199.232.76.173] (port=44308 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1LBaTP-00056C-MV for qemu-devel@nongnu.org; Sat, 13 Dec 2008 14:48:23 -0500 Received: from mx2.redhat.com ([66.187.237.31]:53007) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1LBaTP-0000Td-4j for qemu-devel@nongnu.org; Sat, 13 Dec 2008 14:48:23 -0500 Message-ID: <4944117C.6030404@redhat.com> Date: Sat, 13 Dec 2008 21:48:12 +0200 From: Avi Kivity 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> In-Reply-To: <4943E68E.3030400@codemonkey.ws> Content-Type: text/plain; charset=ISO-8859-1 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: Anthony Liguori Cc: Andrea Arcangeli , chrisw@redhat.com, qemu-devel@nongnu.org, kvm@vger.kernel.org, Gerd Hoffmann Anthony Liguori wrote: >> >> - DMA into mmio regions; this requires bouncing > > The map() API I proposed above should do bouncing to MMIO regions. To > deal with unbounded allocation, you can simply fail when the mapping > allocation has reached some high limit. Calling code needs to cope > with the fact that map'ing may succeed or fail. 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. dma.c _is_ a map/unmap api, except it doesn't expose the mapped data, which allows it to control scheduling as well as be easier to use. > >> - DMA with an associated transform (xor, byteswap); also requires >> bouncing > > At this layer of the API, this is unnecessary. At the PCI layer, you > would need to handle this and I'd suggest taking the same approach as > above. I agree to _map()/_unmap(), but it's not a solution by itself. > >> In turn, bouncing requires splitting large requests to avoid >> unbounded memory allocation. >> >> While I think _map/_unmap is an improvement over can_dma(), this API >> can't handle bounded bouncing, and so a separate layer (dma.c) is >> still necessary. > > I think it can handled bounded bouncing fine. It's a matter of > ensuring the bounce buffer max is sufficiently large and ensuring that > any client code can cope with map failures. In fact, there probably > needs to be a notifiers API that is invoked whenever an unmap() > happens so that if an asynchronous request is waiting because of a map > failure, it can be notified as to when it should try again. Right, but who would it notify? We need some place that can deal with this, and it isn't _map()/_unmap(), and it isn't ide.c or scsi.c. -- Do not meddle in the internals of kernels, for they are subtle and quick to panic.