[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Qemu-devel] Re: [RFC PATCH 4/7] ide: IOMMU support
From: |
Joerg Roedel |
Subject: |
Re: [Qemu-devel] Re: [RFC PATCH 4/7] ide: IOMMU support |
Date: |
Thu, 15 Jul 2010 11:22:32 +0200 |
User-agent: |
Mutt/1.5.18 (2008-05-17) |
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
- Re: [Qemu-devel] Re: [RFC PATCH 4/7] ide: IOMMU support, (continued)
- Re: [Qemu-devel] Re: [RFC PATCH 4/7] ide: IOMMU support, Chris Wright, 2010/07/15
- Re: [Qemu-devel] Re: [RFC PATCH 4/7] ide: IOMMU support, Joerg Roedel, 2010/07/15
- Re: [Qemu-devel] Re: [RFC PATCH 4/7] ide: IOMMU support, Anthony Liguori, 2010/07/15
- Re: [Qemu-devel] Re: [RFC PATCH 4/7] ide: IOMMU support, Joerg Roedel, 2010/07/15
- Re: [Qemu-devel] Re: [RFC PATCH 4/7] ide: IOMMU support, Eduard - Gabriel Munteanu, 2010/07/15
- Re: [Qemu-devel] Re: [RFC PATCH 4/7] ide: IOMMU support, Anthony Liguori, 2010/07/15
- Re: [Qemu-devel] Re: [RFC PATCH 4/7] ide: IOMMU support, Paul Brook, 2010/07/15
- Re: [Qemu-devel] Re: [RFC PATCH 4/7] ide: IOMMU support, Anthony Liguori, 2010/07/15
- Re: [Qemu-devel] Re: [RFC PATCH 4/7] ide: IOMMU support, Paul Brook, 2010/07/15
- Re: [Qemu-devel] Re: [RFC PATCH 4/7] ide: IOMMU support, Eduard - Gabriel Munteanu, 2010/07/14
- Re: [Qemu-devel] Re: [RFC PATCH 4/7] ide: IOMMU support,
Joerg Roedel <=
- Re: [Qemu-devel] Re: [RFC PATCH 4/7] ide: IOMMU support, Paul Brook, 2010/07/15
- Re: [Qemu-devel] Re: [RFC PATCH 4/7] ide: IOMMU support, Joerg Roedel, 2010/07/15
- [Qemu-devel] Re: [RFC PATCH 4/7] ide: IOMMU support, Eduard - Gabriel Munteanu, 2010/07/14
- [Qemu-devel] Re: [RFC PATCH 4/7] ide: IOMMU support, Paul Brook, 2010/07/15
[Qemu-devel] [RFC PATCH 7/7] ac97: IOMMU support, Eduard - Gabriel Munteanu, 2010/07/14
[Qemu-devel] [RFC PATCH 6/7] eepro100: IOMMU support, Eduard - Gabriel Munteanu, 2010/07/14
[Qemu-devel] [RFC PATCH 1/7] Generic IOMMU layer, Eduard - Gabriel Munteanu, 2010/07/14