From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1LBEGL-0007Uh-M3 for qemu-devel@nongnu.org; Fri, 12 Dec 2008 15:05:25 -0500 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1LBEGH-0007Se-SS for qemu-devel@nongnu.org; Fri, 12 Dec 2008 15:05:25 -0500 Received: from [199.232.76.173] (port=35530 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1LBEGH-0007SY-Na for qemu-devel@nongnu.org; Fri, 12 Dec 2008 15:05:21 -0500 Received: from rn-out-0910.google.com ([64.233.170.191]:49545) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1LBEGH-0006db-7w for qemu-devel@nongnu.org; Fri, 12 Dec 2008 15:05:21 -0500 Received: by rn-out-0910.google.com with SMTP id 56so1490538rnw.8 for ; Fri, 12 Dec 2008 12:05:20 -0800 (PST) Message-ID: Date: Fri, 12 Dec 2008 22:05:19 +0200 From: "Blue Swirl" Subject: Re: [Qemu-devel] [PATCH 2 of 5] add can_dma/post_dma for direct IO In-Reply-To: <4942B913.8010306@codemonkey.ws> MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <4942B913.8010306@codemonkey.ws> Reply-To: qemu-devel@nongnu.org List-Id: qemu-devel.nongnu.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: qemu-devel@nongnu.org Cc: chrisw@redhat.com, Gerd Hoffmann , kvm@vger.kernel.org, avi@redhat.com On 12/12/08, Anthony Liguori wrote: > Blue Swirl wrote: > > > On 12/12/08, Andrea Arcangeli wrote: > > > > > > > From: Andrea Arcangeli > > > > > > Add can_dma and post_dma methods needed before/after direct IO to guest > > > physical memory. > > > > > > Signed-off-by: Andrea Arcangeli > > > > > > > > > > > > > > > + /* nonlinear range */ > > > + if (pd_first != pd) > > > + return NULL; > > > > > > > > > > In my tests on Sparc32, IOMMU can map a linear DVMA range to several > > non-linear physical pages, so this case should be handled correctly. > > > > > > I think we should go back to Fabrice's earliest suggestion here. We should > just have a simple map/unmap lock/unlock API for physical memory. That > should be the base API IMHO. Beautiful! > As long the map function goes from guest physical => host virtual, it can > work for everything we care about. > > This is orthogonal to an API dealing with scatter/gather lists and > translation to and from them. So again we tried to solve too many problems at once.