From mboxrd@z Thu Jan  1 00:00:00 1970
Received: from [140.186.70.92] (port=47796 helo=eggs.gnu.org)
	by lists.gnu.org with esmtp (Exim 4.43) id 1OZ6mD-000455-J8
	for qemu-devel@nongnu.org; Wed, 14 Jul 2010 14:33:50 -0400
Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.69)
	(envelope-from <joro@8bytes.org>) id 1OZ6mA-0000s4-9u
	for qemu-devel@nongnu.org; Wed, 14 Jul 2010 14:33:49 -0400
Received: from 8bytes.org ([88.198.83.132]:59498)
	by eggs.gnu.org with esmtp (Exim 4.69)
	(envelope-from <joro@8bytes.org>) id 1OZ6mA-0000rm-5O
	for qemu-devel@nongnu.org; Wed, 14 Jul 2010 14:33:46 -0400
Date: Wed, 14 Jul 2010 20:33:43 +0200
From: Joerg Roedel <joro@8bytes.org>
Message-ID: <20100714183343.GB23755@8bytes.org>
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: qemu-devel@nongnu.org, avi@redhat.com, kvm@vger.kernel.org, Eduard - Gabriel Munteanu <eduard.munteanu@linux360.ro>

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.

There are real devices that care very much about an IOMMU. Basically all
devices supporting ATS care about that. So I don't see a problem if the
device emulation code of qemu also cares about present IOMMUs.

> You should be adding a DeviceState argument to cpu_physical_memory_{rw,map}. 
> This should then handle IOMMU translation transparently.

That's not a good idea imho. With an IOMMU the device no longer accesses
cpu physical memory. It accesses device virtual memory. Using
cpu_physical_memory* functions in device code becomes misleading when
the device virtual address space differs from cpu physical. So different
functions for devices make a lot of sense here. Another reason for
seperate functions is that we can extend them later to support emulation
of ATS devices.

> You also need to accomodate the the case where multiple IOMMU are present.

This, indeed, is something transparent to the device. This should be
handled inside the iommu emulation code.

	Joerg