From mboxrd@z Thu Jan  1 00:00:00 1970
Received: from eggs.gnu.org ([208.118.235.92]:44038)
	by lists.gnu.org with esmtp (Exim 4.71)
	(envelope-from <benh@kernel.crashing.org>) id 1TMVGA-00048c-Em
	for qemu-devel@nongnu.org; Thu, 11 Oct 2012 22:45:59 -0400
Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71)
	(envelope-from <benh@kernel.crashing.org>) id 1TMVG9-0008Ps-In
	for qemu-devel@nongnu.org; Thu, 11 Oct 2012 22:45:58 -0400
Received: from gate.crashing.org ([63.228.1.57]:46344)
	by eggs.gnu.org with esmtp (Exim 4.71)
	(envelope-from <benh@kernel.crashing.org>) id 1TMVG9-0008Pm-7E
	for qemu-devel@nongnu.org; Thu, 11 Oct 2012 22:45:57 -0400
Message-ID: <1350009941.20486.133.camel@pasglop>
From: Benjamin Herrenschmidt <benh@kernel.crashing.org>
Date: Fri, 12 Oct 2012 13:45:41 +1100
In-Reply-To: <5076CCAB.5030202@redhat.com>
References: <1349962023-560-1-git-send-email-avi@redhat.com>
	<1349962023-560-4-git-send-email-avi@redhat.com>
	<5076CCAB.5030202@redhat.com>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: 7bit
Mime-Version: 1.0
Subject: Re: [Qemu-devel] [RFC v1 3/7] memory: iommu support
List-Id: <qemu-devel.nongnu.org>
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>
To: Paolo Bonzini <pbonzini@redhat.com>
Cc: "Michael S. Tsirkin" <mst@redhat.com>, qemu-devel@nongnu.org, liu ping fan <qemulist@gmail.com>, Blue Swirl <blauwirbel@gmail.com>, Alex Williamson <alex.williamson@redhat.com>, Avi Kivity <avi@redhat.com>, Anthony Liguori <anthony@codemonkey.ws>, David Gibson <david@gibson.dropbear.id.au>

On Thu, 2012-10-11 at 15:42 +0200, Paolo Bonzini wrote:
> Il 11/10/2012 15:26, Avi Kivity ha scritto:
> > +struct MemoryRegionIOMMUOps {
> > +    /* Returns a TLB entry that contains a given address. */
> > +    IOMMUTLBEntry (*translate)(MemoryRegion *iommu, target_phys_addr_t addr,
> > +                               bool is_write);
> > +};
> 
> Do map/unmap still make sense in this model?  Ben & David, what were
> your plans there?

To keep it under the rug for as long as we could ? :-)

The problem with map and unmap is invalidations. How do you convey to
the devices having done a map that the guest has invalidated a
translation entry.

Especially nasty on PAPR where the invalidation is a hcall which is
assumed to be synchronous.

We have simply not solved the problem for now. The risk due to the
possible access beyond the end of life of a translation is negligible as
long as we are not playing funny mapping tricks with emulated devices
(which we might do with some in the future... but not today) and the
scope of the problem is limited to the guest corrupting itself.

Cheers,
Ben.