From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1LBQhR-00055O-Fj for qemu-devel@nongnu.org; Sat, 13 Dec 2008 04:22:13 -0500 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1LBQhO-00055C-ON for qemu-devel@nongnu.org; Sat, 13 Dec 2008 04:22:13 -0500 Received: from [199.232.76.173] (port=43034 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1LBQhO-000559-IX for qemu-devel@nongnu.org; Sat, 13 Dec 2008 04:22:10 -0500 Received: from mx2.redhat.com ([66.187.237.31]:34824) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1LBQhO-0007YL-47 for qemu-devel@nongnu.org; Sat, 13 Dec 2008 04:22:10 -0500 Message-ID: <49437EC8.6020506@redhat.com> Date: Sat, 13 Dec 2008 11:22:16 +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> In-Reply-To: <4942BDEE.7020003@codemonkey.ws> 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: Anthony Liguori Cc: Andrea Arcangeli , chrisw@redhat.com, qemu-devel@nongnu.org, kvm@vger.kernel.org, Gerd Hoffmann 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 - DMA with an associated transform (xor, byteswap); also requires bouncing 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 have a truly marvellous patch that fixes the bug which this signature is too narrow to contain.