From mboxrd@z Thu Jan  1 00:00:00 1970
From: Benjamin Herrenschmidt <benh@kernel.crashing.org>
Subject: Re: [RFC PATCH] vfio: VFIO Driver core framework
Date: Tue, 15 Nov 2011 11:49:29 +1100
Message-ID: <1321318169.21206.72.camel@pasglop>
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>
	<20111115000505.GA5035@truffala.fritz.box>
Mime-Version: 1.0
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: 7bit
Cc: "Aaron Fabbri
	\(aafabbri\)" <aafabbri@cisco.com>, aik@au1.ibm.com, kvm@vger.kernel.org,
	pmac@au1.ibm.com, joerg.roedel@amd.com, konrad.wilk@oracle.com,
	agraf@suse.de, iommu@lists.linux-foundation.org,
	qemu-devel@nongnu.org, chrisw@sous-sol.org, B08248@freescale.com,
	Alex Williamson <alex.williamson@redhat.com>, avi@redhat.com,
	linux-pci@vger.kernel.org, B07421@freescale.com, "Christian Benvenuti
	\(benve\)" <benve@cisco.com>
To: David Gibson <dwg@au1.ibm.com>
Return-path: <qemu-devel-bounces+gceq-qemu-devel=gmane.org@nongnu.org>
In-Reply-To: <20111115000505.GA5035@truffala.fritz.box>
List-Unsubscribe: <https://lists.nongnu.org/mailman/options/qemu-devel>,
	<mailto:qemu-devel-request@nongnu.org?subject=unsubscribe>
List-Archive: <http://lists.nongnu.org/archive/html/qemu-devel>
List-Post: <mailto:qemu-devel@nongnu.org>
List-Help: <mailto:qemu-devel-request@nongnu.org?subject=help>
List-Subscribe: <https://lists.nongnu.org/mailman/listinfo/qemu-devel>,
	<mailto:qemu-devel-request@nongnu.org?subject=subscribe>
Errors-To: qemu-devel-bounces+gceq-qemu-devel=gmane.org@nongnu.org
Sender: qemu-devel-bounces+gceq-qemu-devel=gmane.org@nongnu.org
List-Id: kvm.vger.kernel.org

On Tue, 2011-11-15 at 11:05 +1100, David Gibson wrote:
> 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. 

In fact they are a very hot path even. There's no way we can afford the
cost of tracking per page mapping/unmapping (other than bumping the page
count on a page that's currently mapped or via some debug-only feature).

Cheers,
Ben.