From mboxrd@z Thu Jan 1 00:00:00 1970 From: Anthony Liguori Subject: Re: [Qemu-devel] Re: [PATCH 2 of 5] add can_dma/post_dma for direct IO Date: Sun, 14 Dec 2008 20:09:39 -0600 Message-ID: <4945BC63.1080600@codemonkey.ws> References: <49456337.4000000@redhat.com> <494591F7.3080002@codemonkey.ws> <200812150057.10162.paul@codesourcery.com> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: qemu-devel@nongnu.org, Avi Kivity , Andrea Arcangeli , chrisw@redhat.com, kvm@vger.kernel.org, Gerd Hoffmann To: Paul Brook Return-path: Received: from yw-out-2324.google.com ([74.125.46.30]:11579 "EHLO yw-out-2324.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751436AbYLOCJp (ORCPT ); Sun, 14 Dec 2008 21:09:45 -0500 Received: by yw-out-2324.google.com with SMTP id 9so1030110ywe.1 for ; Sun, 14 Dec 2008 18:09:43 -0800 (PST) In-Reply-To: <200812150057.10162.paul@codesourcery.com> Sender: kvm-owner@vger.kernel.org List-ID: Paul Brook wrote: >>> That's pointless; cirrus for example has 8MB of mmio while a >>> cpu-to-vram blit is in progress, and some random device we'll add >>> tomorrow could easily introduce more. Our APIs shouldn't depend on >>> properties of emulated hardware, at least as much as possible. >>> >> One way to think of what I'm suggesting, is that if for every >> cpu_register_physical_memory call for MMIO, we allocated a buffer, then >> whenever map() was called on MMIO, we would return that already >> allocated buffer. The overhead is fixed and honestly relatively small. >> Much smaller than dma.c proposes. >> > > I Wouldn't be surprised if some machines had a large memory mapped IO space. > Most of it might not be actively used, but once you start considering 64-bit > machines on 32-bit hosts these allocations would become problematic. > At some level, any DMA API would fall apart here. Certain IO operations simply cannot be split (such as network send). If you pass don't pass a flag to the map function that says you can handle partial results, you must cope with map() returning NULL (by dropping the packet). Since MMIO space is something we control as we implement device emulation, we can assert that this isn't a problem today, and then deal with that particular special case when we come to it. Regards, Anthony Liguori