Re: RFC: iommu_ops -- limitation with current attach_dev() API

[Joerg Roedel <joro@8bytes.org>]

On Tue, Jan 10, 2012 at 11:15:54AM -0600, Stuart Yoder wrote:
> We have devices that are capable of and need to access multiple
> domains.    At the hardware level the device has multiple 'logical
> I/O device numbers'  which is the index into our IOMMU tables.  This
> means the device can target DMA operations to 2 different
> address spaces.

Your IOMMU is a real challenge it seems ;-)

> In some internal discussions here at Freescale, here were some
> of our initial ideas:
> 
>    -in 'struct device' define a new list of hardware/physical DMA 'domains'
>     that represent each address space a device can target:
> 
>          struct list_head        iommu_hw_domain_head;

I think we really should introduce a dev->iommu pointer which can be
used by IOMMU drivers. Your hardware is on the third architecture
needing such a pointer and hiding it in dev->archdata.

>     That list would get populated when the device struct is
>     initialized with an arch specific list of the hardware 'domains'.
> 
>    -define a  new iommu_ops function to add devices with this hardware
>     domain info:
> 
>        extern int iommu_attach_device_ext(struct iommu_domain *domain,
>                                struct device *dev,  void *iommu_hw_domain);

How about just enumerating the device address spaces with an u32 and use
that to assign the domains. Or is an in-kernel descriptor for the
hardware-side really needed? If so, why?


	Joerg