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 11:22:16 +0200 Message-ID: <49437EC8.6020506@redhat.com> References: <4942B841.6010900@codemonkey.ws> <4942BDEE.7020003@codemonkey.ws> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed 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]:32778 "EHLO mx2.redhat.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751925AbYLMJWL (ORCPT ); Sat, 13 Dec 2008 04:22:11 -0500 In-Reply-To: <4942BDEE.7020003@codemonkey.ws> Sender: kvm-owner@vger.kernel.org List-ID: 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.