From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1LBXc7-0003G3-Ac for qemu-devel@nongnu.org; Sat, 13 Dec 2008 11:45:11 -0500 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1LBXc5-0003CQ-5Z for qemu-devel@nongnu.org; Sat, 13 Dec 2008 11:45:10 -0500 Received: from [199.232.76.173] (port=43866 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1LBXc4-0003C8-Tx for qemu-devel@nongnu.org; Sat, 13 Dec 2008 11:45:08 -0500 Received: from yx-out-1718.google.com ([74.125.44.153]:14566) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1LBXc4-0004xf-Iz for qemu-devel@nongnu.org; Sat, 13 Dec 2008 11:45:08 -0500 Received: by yx-out-1718.google.com with SMTP id 3so889395yxi.82 for ; Sat, 13 Dec 2008 08:45:07 -0800 (PST) Message-ID: <4943E68E.3030400@codemonkey.ws> Date: Sat, 13 Dec 2008 10:45:02 -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> In-Reply-To: <49437EC8.6020506@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: >>> >>> I think any API based on a can_dma abstraction is wrong. The >>> write_post_dma thing is equally wrong. >>> >>> The concept of "dma" that you're introducing is not correct. >>> >>> The DMA API should have the following properties: >>> >>> 1) You attempt to map a physical address. This effectively is a >>> lock or pin operation. >>> a) In the process of this, you get a virtual address that you can >>> manipulate. >>> 2) You do your IO to the virtual address >>> 3) You indicate how much of the memory you have dirtied >>> 4) You unmap or unlock that memory region. The virtual address is >>> now no longer valid. >>> >>> 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); >> >> Let me clarify this a bit more. The problem we're trying to address >> today is the encapsulating knowledge of phys_ram_base. We want to >> minimize the amount of code that makes any assumptions about >> phys_ram_base. Your current API still accesses phys_ram_base >> directly in the PCI DMA API. The only real improvement compared to >> the current virtio code is that you properly handle MMIO. This is >> not just about layout but this also includes the fact that in the >> future, guest memory could be discontiguous in QEMU (think memory >> hotplug). > > There are two more problems the dma api solves: > > - 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. > - 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. > 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. Regards, Anthony Liguori