From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1LBDrM-0001Kk-0w for qemu-devel@nongnu.org; Fri, 12 Dec 2008 14:39:36 -0500 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1LBDrK-0001KC-Mb for qemu-devel@nongnu.org; Fri, 12 Dec 2008 14:39:35 -0500 Received: from [199.232.76.173] (port=49297 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1LBDrK-0001K9-Ch for qemu-devel@nongnu.org; Fri, 12 Dec 2008 14:39:34 -0500 Received: from an-out-0708.google.com ([209.85.132.249]:65109) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1LBDrI-0003Hn-PR for qemu-devel@nongnu.org; Fri, 12 Dec 2008 14:39:33 -0500 Received: by an-out-0708.google.com with SMTP id c38so772477ana.37 for ; Fri, 12 Dec 2008 11:39:31 -0800 (PST) Message-ID: <4942BDEE.7020003@codemonkey.ws> Date: Fri, 12 Dec 2008 13:39:26 -0600 From: Anthony Liguori MIME-Version: 1.0 References: <4942B841.6010900@codemonkey.ws> In-Reply-To: <4942B841.6010900@codemonkey.ws> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: [Qemu-devel] Re: [PATCH 2 of 5] add can_dma/post_dma for direct IO Reply-To: qemu-devel@nongnu.org List-Id: qemu-devel.nongnu.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Andrea Arcangeli Cc: chrisw@redhat.com, avi@redhat.com, Gerd Hoffmann , kvm@vger.kernel.org, qemu-devel@nongnu.org Anthony Liguori wrote: > Andrea Arcangeli wrote: >> From: Andrea Arcangeli >> >> Add can_dma and post_dma methods needed before/after direct IO to guest >> physical memory. >> > > 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). Or, in the case of Xen, it may not be possible to have all of guest memory mapped at any given time. The API that I propose above limits the knowledge of how to access guest memory to exec.c and makes it very easy to deal with discontiguous or even partially mapped guest memory in QEMU. Any other APIs built around it (like a PCI DMA API) don't have to have any special knowledge about how guest memory is stored. Regards, Anthony Liguori