From mboxrd@z Thu Jan  1 00:00:00 1970
Received: from [140.186.70.92] (port=54710 helo=eggs.gnu.org)
	by lists.gnu.org with esmtp (Exim 4.43) id 1OZB7X-0002Ud-5u
	for qemu-devel@nongnu.org; Wed, 14 Jul 2010 19:12:07 -0400
Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.69)
	(envelope-from <edgmnt@gmail.com>) id 1OZB7W-000763-3l
	for qemu-devel@nongnu.org; Wed, 14 Jul 2010 19:12:07 -0400
Received: from mail-bw0-f45.google.com ([209.85.214.45]:53448)
	by eggs.gnu.org with esmtp (Exim 4.69)
	(envelope-from <edgmnt@gmail.com>) id 1OZB7V-00075v-UE
	for qemu-devel@nongnu.org; Wed, 14 Jul 2010 19:12:06 -0400
Received: by bwz19 with SMTP id 19so290264bwz.4
	for <qemu-devel@nongnu.org>; Wed, 14 Jul 2010 16:12:05 -0700 (PDT)
Sender: Eduard - Gabriel Munteanu <edgmnt@gmail.com>
Date: Thu, 15 Jul 2010 02:11:00 +0300
From: Eduard - Gabriel Munteanu <eduard.munteanu@linux360.ro>
Message-ID: <20100714231100.GC7065@localhost>
References: <1279086307-9596-1-git-send-email-eduard.munteanu@linux360.ro>
	<1279086307-9596-5-git-send-email-eduard.munteanu@linux360.ro>
	<201007141453.06131.paul@codesourcery.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <201007141453.06131.paul@codesourcery.com>
Subject: [Qemu-devel] Re: [RFC PATCH 4/7] ide: IOMMU support
List-Id: qemu-devel.nongnu.org
List-Unsubscribe: <http://lists.nongnu.org/mailman/listinfo/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: <http://lists.nongnu.org/mailman/listinfo/qemu-devel>,
	<mailto:qemu-devel-request@nongnu.org?subject=subscribe>
To: Paul Brook <paul@codesourcery.com>
Cc: joro@8bytes.org, avi@redhat.com, kvm@vger.kernel.org, qemu-devel@nongnu.org

On Wed, Jul 14, 2010 at 02:53:03PM +0100, Paul Brook wrote:
> > Memory accesses must go through the IOMMU layer.
> 
> No. Devices should not know or care whether an IOMMU is present.

They don't really care. iommu_get() et al. are convenience functions
which can and do return NULL when there's no IOMMU and device code can
pass that NULL around without checking. I could've probably made the r/w
functions take only the DeviceState in addition to normal args, but
wanted to avoid looking up the related structures on each I/O operation.

> You should be adding a DeviceState argument to cpu_physical_memory_{rw,map}. 
> This should then handle IOMMU translation transparently.
> 
> You also need to accomodate the the case where multiple IOMMU are present.
> 
> Paul

We don't assume there's a single IOMMU in the generic layer. The
callbacks within 'struct iommu' could very well dispatch the request to
one of multiple, coexisting IOMMUs.


	Eduard