Re: [Qemu-devel] PCI iommu issues

[Benjamin Herrenschmidt <benh@kernel.crashing.org>]

On Sat, 2015-01-31 at 15:42 +0100, Knut Omang wrote:

> I agree with you that they are two distinct problems, with perhaps a 
> 3rd problem of how to generalize this to other devices than PCI devices?
> 
> Right now the 
> handling of requester IDs across bridges seems very rudimentary in the
> QEMU model, and as you indicate, it is perhaps not necessary to emulate
> all details of broken switches etc, but maybe we need some kind of
> requester ID translation function (similar to pci_bridge_map_irq()) that
> a bridge can choose to implement, where the default is the unit
> translation?

That could work.

> Wrt. handling solving the original issue of IOMMU support for devices on
> secondary buses (and beyond?) My approach in the patch above is just to
> pass a PCIDevice pointer instead of PCIBus* + devfn, eg:
> 
> -typedef AddressSpace *(*PCIIOMMUFunc)(PCIBus *, void *, int);
> +typedef AddressSpace *(*PCIIOMMUFunc)(PCIDevice *, void *);

This is something I was going to suggest :-)

> For the current Intel Iommu implementation, that seems to work fine as
> no additional logic is need to "propagate" the enumeration, as accurate
> IDs can be found via the device pointer.

Agreed.

>  The current API leaves the task
> of maintaining multiple address spaces for each IOMMU implementation,
> maybe a more explicit notion of an IOMMU group similar to the way it is
> used by VFIO is more close to how a common denominator of hardware
> works? Adding Alex as well, as he might have more insight into the
> details of different IOMMU implementations from his VFIO work.

I would first make it work, let more than one implementation be written,
and only then, see what can be factored. 

As for non-PCI, I wouldn't worry too much yet, ie, I don't see a point
in delaying fixing broken PCI IOMMUs for an hypothetical generic layer
than may or may not work or take a year in the making.

As for Michael feedback, well, if we feel we can hack all the way to the
core DMA functions, I would have gone further and not attached address
spaces to devices permanently like we do ... the address spaces are
really the domains, so to mimmic the HW properly, ideally we would
capture the bus number on config space, and lazily resolve the address
space on each DMA ... We can invalidate the cached pointer when cfg
space is written or when the iommu invalidates its cache, but it's more
work and it could be difficult with vfio...

Also it makes it harder to use a memory region as child of the address
space that we enable/disable to deal with the operations of the bus
master enable bit (but then the way we do that prevents us from
implementing broken devices that ignore that bit :-)

Cheers,
Ben.

> Knut
> 
> > > Cheers,
> > > Ben.
> > > 
> > > 
> > 
>