From mboxrd@z Thu Jan  1 00:00:00 1970
Received: from eggs.gnu.org ([208.118.235.92]:58843)
	by lists.gnu.org with esmtp (Exim 4.71)
	(envelope-from <pbonzini@redhat.com>) id 1TMJDS-0008NM-SI
	for qemu-devel@nongnu.org; Thu, 11 Oct 2012 09:54:28 -0400
Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71)
	(envelope-from <pbonzini@redhat.com>) id 1TMJDJ-00011h-4Q
	for qemu-devel@nongnu.org; Thu, 11 Oct 2012 09:54:22 -0400
Received: from mx1.redhat.com ([209.132.183.28]:14878)
	by eggs.gnu.org with esmtp (Exim 4.71)
	(envelope-from <pbonzini@redhat.com>) id 1TMJDI-00011c-SD
	for qemu-devel@nongnu.org; Thu, 11 Oct 2012 09:54:13 -0400
Message-ID: <5076CF7B.3030101@redhat.com>
Date: Thu, 11 Oct 2012 15:54:03 +0200
From: Paolo Bonzini <pbonzini@redhat.com>
MIME-Version: 1.0
References: <1349962023-560-1-git-send-email-avi@redhat.com>
	<1349962023-560-4-git-send-email-avi@redhat.com>
	<5076CCAB.5030202@redhat.com> <5076CD8F.7030808@redhat.com>
In-Reply-To: <5076CD8F.7030808@redhat.com>
Content-Type: text/plain; charset=ISO-8859-15
Content-Transfer-Encoding: 7bit
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: Avi Kivity <avi@redhat.com>
Cc: "Michael S. Tsirkin" <mst@redhat.com>, liu ping fan <qemulist@gmail.com>, qemu-devel@nongnu.org, Blue Swirl <blauwirbel@gmail.com>, Alex Williamson <alex.williamson@redhat.com>, Anthony Liguori <anthony@codemonkey.ws>, David Gibson <david@gibson.dropbear.id.au>

Il 11/10/2012 15:45, 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?
>> > 
> Map/unmap is supported via address_space_map(), which calls
> ->translate().  I don't see how a lower-level map/unmap helps, unless
> the hardware supplies such a function.

Yep, it's just the map/unmap callbacks that are not supported anymore,
but nobody uses that feature of DMAContext yet.

Paolo