From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([140.186.70.92]:36592) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1RQ6eC-0005Kf-UH for qemu-devel@nongnu.org; Mon, 14 Nov 2011 19:13:10 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1RQ6eB-0003Cy-KV for qemu-devel@nongnu.org; Mon, 14 Nov 2011 19:13:08 -0500 Received: from e23smtp05.au.ibm.com ([202.81.31.147]:48399) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1RQ6eA-0003Cq-Vx for qemu-devel@nongnu.org; Mon, 14 Nov 2011 19:13:07 -0500 Received: from /spool/local by e23smtp05.au.ibm.com with IBM ESMTP SMTP Gateway: Authorized Use Only! Violators will be prosecuted for from ; Tue, 15 Nov 2011 00:11:08 +1000 Received: from d23av04.au.ibm.com (d23av04.au.ibm.com [9.190.235.139]) by d23relay03.au.ibm.com (8.13.8/8.13.8/NCO v10.0) with ESMTP id pAF0CuxV3141844 for ; Tue, 15 Nov 2011 11:12:56 +1100 Received: from d23av04.au.ibm.com (loopback [127.0.0.1]) by d23av04.au.ibm.com (8.14.4/8.13.1/NCO v10.0 AVout) with ESMTP id pAF0Ct35009124 for ; Tue, 15 Nov 2011 11:12:56 +1100 Date: Tue, 15 Nov 2011 11:05:05 +1100 From: David Gibson Message-ID: <20111115000505.GA5035@truffala.fritz.box> References: <20111103195452.21259.93021.stgit@bling.home> <184D23435BECB444AB6B9D4630C8EC8302D5FE38@XMB-RCD-303.cisco.com> <1321034647.2682.98.camel@bling.home> <184D23435BECB444AB6B9D4630C8EC8302D603A9@XMB-RCD-303.cisco.com> <1321311540.17169.122.camel@bling.home> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1321311540.17169.122.camel@bling.home> Subject: Re: [Qemu-devel] [RFC PATCH] vfio: VFIO Driver core framework List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Alex Williamson Cc: "Aaron Fabbri (aafabbri)" , aik@au1.ibm.com, kvm@vger.kernel.org, pmac@au1.ibm.com, joerg.roedel@amd.com, konrad.wilk@oracle.com, agraf@suse.de, qemu-devel@nongnu.org, chrisw@sous-sol.org, B08248@freescale.com, iommu@lists.linux-foundation.org, avi@redhat.com, linux-pci@vger.kernel.org, B07421@freescale.com, "Christian Benvenuti (benve)" On Mon, Nov 14, 2011 at 03:59:00PM -0700, Alex Williamson wrote: > On Fri, 2011-11-11 at 16:22 -0600, Christian Benvenuti (benve) wrote: [snip] > > - the user either unmaps one specific mapping or 'all of them'. > > The 'all of them' case would also take care of those cases where > > the user does _not_ keep track of mappings and simply uses > > the "unmap from 0 to ~0" each time. > > > > Because of this you could still provide an exact map/unmap logic > > and allow such "unmap from 0 to ~0" by making the latter a special > > case. > > However, if we want to allow any arbitrary/inexact unmap request, then OK. > > I can't think of any good reasons we shouldn't be more strict. I think > it was primarily just convenient to hit all the corner cases since we > merge all the requests together for tracking and need to be able to > split them back apart. It does feel a little awkward to have a 0/~0 > special case though, but I don't think it's worth adding another ioctl > to handle it. Being strict, or at least enforcing strictness, requires that the infrastructure track all the maps, so that the unmaps can be matching. This is not a natural thing with the data structures you want for all IOMMUs. For example on POWER, the IOMMU (aka TCE table) is a simple 1-level pagetable. One pointer with a couple of permission bits per IOMMU page. Handling oddly overlapping operations on that data structure is natural, enforcing strict matching of maps and unmaps is not and would require extra information to be stored by vfio. On POWER, the IOMMU operations often *are* a hot path, so manipulating those structures would have a real cost, too. -- David Gibson | I'll have my music baroque, and my code david AT gibson.dropbear.id.au | minimalist, thank you. NOT _the_ _other_ | _way_ _around_! http://www.ozlabs.org/~dgibson