From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from [140.186.70.92] (port=44879 helo=eggs.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1OZKeI-0000Z4-Q4 for qemu-devel@nongnu.org; Thu, 15 Jul 2010 05:22:35 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.69) (envelope-from ) id 1OZKeH-0000Yt-PZ for qemu-devel@nongnu.org; Thu, 15 Jul 2010 05:22:34 -0400 Received: from 8bytes.org ([88.198.83.132]:58094) by eggs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1OZKeH-0000Yk-J4 for qemu-devel@nongnu.org; Thu, 15 Jul 2010 05:22:33 -0400 Date: Thu, 15 Jul 2010 11:22:32 +0200 From: Joerg Roedel Subject: Re: [Qemu-devel] Re: [RFC PATCH 4/7] ide: IOMMU support Message-ID: <20100715092231.GE23755@8bytes.org> References: <1279086307-9596-1-git-send-email-eduard.munteanu@linux360.ro> <201007141453.06131.paul@codesourcery.com> <20100714183343.GB23755@8bytes.org> <201007142113.44913.paul@codesourcery.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <201007142113.44913.paul@codesourcery.com> List-Id: qemu-devel.nongnu.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Paul Brook Cc: Eduard - Gabriel Munteanu , qemu-devel@nongnu.org, kvm@vger.kernel.org, avi@redhat.com On Wed, Jul 14, 2010 at 09:13:44PM +0100, Paul Brook wrote: > A device performs a memory access on its local bus. It has no knowledge of how > that access is routed to its destination. The device should not be aware of > any IOMMUs, in the same way that it doesn't know whether it happens to be > accessing RAM or memory mapped peripherals on another device. Right. > Each IOMMU is fundamentally part of a bus bridge. For example the bridge > between a PCI bus and the system bus. It provides a address mapping from one > bus to another. An IOMMU is not necessarily part of a bus bridge. By concept an IOMMU can also be implemented on a plugin-card translating only that card. Real implementations that I am aware of always implement the IOMMU in the PCI root bridge, though. > There should be no direct interaction between an IOMMU and a device (ignoring > ATS, which is effectively a separate data channel). Everything should be done > via the cpu_phsycial_memory_* code. Likewise on a system with multiple nested > IOMMUs there should be no direct interatcion between these. > cpu_physical_memory_* should walk the device/bus tree to determine where the > access terminates, applying mappings appropriately. Thats the point where I disagree. I think there should be a seperate set of functions independent from cpu_physical_memory_* to handle device memory accesses. This would keep the changes small and non-intrusive. Beside that, real memory controlers can also handle cpu memory accesses different from device memory accesses. The AMD northbridge GART uses this to decide whether it needs to remap a request or not. The GART can be configured to translate cpu and device accesses seperatly. Joerg