From mboxrd@z Thu Jan  1 00:00:00 1970
Received: from eggs.gnu.org ([208.118.235.92]:50402)
	by lists.gnu.org with esmtp (Exim 4.71)
	(envelope-from <avi@redhat.com>) id 1TMJ5d-0003Z9-Nr
	for qemu-devel@nongnu.org; Thu, 11 Oct 2012 09:46:27 -0400
Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71)
	(envelope-from <avi@redhat.com>) id 1TMJ5T-00072M-GD
	for qemu-devel@nongnu.org; Thu, 11 Oct 2012 09:46:17 -0400
Received: from mx1.redhat.com ([209.132.183.28]:15600)
	by eggs.gnu.org with esmtp (Exim 4.71)
	(envelope-from <avi@redhat.com>) id 1TMJ5T-00072I-88
	for qemu-devel@nongnu.org; Thu, 11 Oct 2012 09:46:07 -0400
Message-ID: <5076CD8F.7030808@redhat.com>
Date: Thu, 11 Oct 2012 15:45:51 +0200
From: Avi Kivity <avi@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>
In-Reply-To: <5076CCAB.5030202@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: Paolo Bonzini <pbonzini@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>

On 10/11/2012 03:42 PM, 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?
> 

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.

-- 
error compiling committee.c: too many arguments to function