Re: [Qemu-devel] Re: [RFC PATCH 4/7] ide: IOMMU support

[Eduard - Gabriel Munteanu]

On Wed, Jul 14, 2010 at 09:13:44PM +0100, Paul Brook wrote:

> Well, ok, the function name needs fixing too.  However I think the only thing 
> missing from the current API is that it does not provide a way to determine 
> which device is performing the access.
> 
> Depending how the we decide to handle IOMMU invalidation, it may also be 
> necessary to augment the memory_map API to allow the system to request a 
> mapping be revoked.  However this issue is not specific to the IOMMU 
> implementation. Such bugs are already present on any system that allows 
> dynamic reconfiguration of the address space, e.g. by changing PCI BARs.

Yeah, having a way to alter existing maps would be good. Basically it's
the only place where we truly care about the existence of an IOMMU, and
that's due to AIO.

But it's really tricky to do, unfortunately. I also think having an
abort_doing_io_on_map() kind of notifier would be sufficient. It should
notify back when I/O has been completely stopped.

This should be enough, since we don't expect the results of IDE-like DMA
to be recoverable in case a mapping change occurs, even on real hardware.

> I disagree. ATS should be an independent feature, and is inherently bus 
> specific.  As usual the PCI spec is not publicly available, but based on the 
> AMD IOMMU docs I'd say that ATS is completely independent of memory accesses 
> - 
> the convention being that you trust an ATS capable device to DTRT, and 
> configure the bus IOMMU to apply a flat mapping for accesses from such 
> devices.

ATS is documented in the Hypertransport specs which are publicly
available.

[snip]

> 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.
> 
> 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. 
> 
> 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.
> 
> Paul

Admittedly I could make __iommu_rw() repeateadly call itself instead of
doing cpu_physical_memory_rw(). That's what I actually intended, and it
should handle IOMMU nesting. It's a trivial change to do so.

Note that emulating hardware realistically defeats some performance
purposes. It'd make AIO impossible, if we imagine some sort of message
passing scenario (which would be just like the real thing, but a lot
slower).


        Eduard