From: Paul Brook <paul@codesourcery.com>
To: Joerg Roedel <joro@8bytes.org>
Cc: Eduard - Gabriel Munteanu <eduard.munteanu@linux360.ro>,
qemu-devel@nongnu.org, kvm@vger.kernel.org, avi@redhat.com
Subject: Re: [Qemu-devel] Re: [RFC PATCH 4/7] ide: IOMMU support
Date: Thu, 15 Jul 2010 11:49:20 +0100 [thread overview]
Message-ID: <201007151149.21110.paul@codesourcery.com> (raw)
In-Reply-To: <20100715092231.GE23755@8bytes.org>
> 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.
If the IOMMU is implemented on the card, then it isn't an interesting case.
It's effectively just a complex form of scatter-gather.
If the on-card MMU can delegate pagetable walks to an external device then IMO
that's also an unrelated feature, and requires an additional data channel.
> > 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.
My point still stands. You should not be pushing the IOMMU handling into
device specific code. All you need to do is make the memory access routines
aware of which device caused the access.
The fact that the GART can translate CPU accesses proves my point. If you
have separate code for CPU and devices, then you need to duplicate the GART
handling code.
Paul
next prev parent reply other threads:[~2010-07-15 10:49 UTC|newest]
Thread overview: 42+ messages / expand[flat|nested] mbox.gz Atom feed top
2010-07-14 5:45 [Qemu-devel] [RFC PATCH 0/7] AMD IOMMU emulation patchset Eduard - Gabriel Munteanu
2010-07-14 5:45 ` [Qemu-devel] [RFC PATCH 1/7] Generic IOMMU layer Eduard - Gabriel Munteanu
2010-07-14 6:07 ` malc
2010-07-14 22:47 ` Eduard - Gabriel Munteanu
2010-07-14 5:45 ` [Qemu-devel] [RFC PATCH 2/7] AMD IOMMU emulation Eduard - Gabriel Munteanu
2010-07-14 20:16 ` Paul Brook
2010-07-14 5:45 ` [Qemu-devel] [RFC PATCH 3/7] pci: call IOMMU hooks Eduard - Gabriel Munteanu
2010-07-14 7:37 ` Isaku Yamahata
2010-07-14 22:50 ` Eduard - Gabriel Munteanu
2010-07-14 5:45 ` [Qemu-devel] [RFC PATCH 4/7] ide: IOMMU support Eduard - Gabriel Munteanu
2010-07-14 13:53 ` [Qemu-devel] " Paul Brook
2010-07-14 18:33 ` Joerg Roedel
2010-07-14 20:13 ` Paul Brook
2010-07-14 21:29 ` Anthony Liguori
2010-07-14 22:24 ` Chris Wright
2010-07-15 10:28 ` Paul Brook
2010-07-15 16:52 ` Chris Wright
2010-07-15 17:02 ` Avi Kivity
2010-07-15 17:17 ` Chris Wright
2010-07-15 17:22 ` Avi Kivity
2010-07-15 17:25 ` Chris Wright
2010-07-15 17:27 ` Eduard - Gabriel Munteanu
2010-07-15 17:22 ` Joerg Roedel
2010-07-15 17:14 ` Chris Wright
2010-07-15 9:10 ` Joerg Roedel
2010-07-15 12:45 ` Anthony Liguori
2010-07-15 14:45 ` Joerg Roedel
2010-07-15 16:45 ` Eduard - Gabriel Munteanu
2010-07-15 17:42 ` Anthony Liguori
2010-07-15 10:33 ` Paul Brook
2010-07-15 12:42 ` Anthony Liguori
2010-07-15 14:02 ` Paul Brook
2010-07-14 23:39 ` Eduard - Gabriel Munteanu
2010-07-15 9:22 ` Joerg Roedel
2010-07-15 10:49 ` Paul Brook [this message]
2010-07-15 14:59 ` Joerg Roedel
2010-07-14 23:11 ` Eduard - Gabriel Munteanu
2010-07-15 10:58 ` Paul Brook
2010-07-14 5:45 ` [Qemu-devel] [RFC PATCH 5/7] rtl8139: " Eduard - Gabriel Munteanu
2010-07-14 5:45 ` [Qemu-devel] [RFC PATCH 6/7] eepro100: " Eduard - Gabriel Munteanu
2010-07-14 5:45 ` [Qemu-devel] [RFC PATCH 7/7] ac97: " Eduard - Gabriel Munteanu
2010-07-14 6:09 ` malc
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=201007151149.21110.paul@codesourcery.com \
--to=paul@codesourcery.com \
--cc=avi@redhat.com \
--cc=eduard.munteanu@linux360.ro \
--cc=joro@8bytes.org \
--cc=kvm@vger.kernel.org \
--cc=qemu-devel@nongnu.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).