From mboxrd@z Thu Jan 1 00:00:00 1970 From: Joerg Roedel Subject: Re: [Qemu-devel] Re: [RFC PATCH 4/7] ide: IOMMU support Date: Thu, 15 Jul 2010 11:22:32 +0200 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 Cc: qemu-devel@nongnu.org, avi@redhat.com, kvm@vger.kernel.org, Eduard - Gabriel Munteanu To: Paul Brook Return-path: Received: from 8bytes.org ([88.198.83.132]:40627 "EHLO 8bytes.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S932774Ab0GOJWc (ORCPT ); Thu, 15 Jul 2010 05:22:32 -0400 Content-Disposition: inline In-Reply-To: <201007142113.44913.paul@codesourcery.com> Sender: kvm-owner@vger.kernel.org List-ID: 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