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

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Wanted to get some input and feedback on a limitation we have run into
with the current
iommu_ops architecture regarding attaching (and detaching) devices.

The attach_dev API is defined as:

extern int iommu_attach_device(struct iommu_domain *domain,
                               struct device *dev);

The assumption is that a device targets at most one iommu domain.

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.

One possible question is whether the device is really not one, but
multiple devices.   That's not the case.  It is literally one device with
multiple DMA address space targets. (analagous perhaps in a way
to a device with multiple interrupts?).

An example is a queue manager portal device on our SoCs which is represented
in our device tree as:

                qportal1: qman-portal@4000 {
                        cell-index = <0x1>;
                        compatible = "fsl,p4080-qman-portal", "fsl,qman-portal";
                        reg = <0x4000 0x4000 0x101000 0x1000>;
                        interrupts = <106 0x2 0 0>;
                        fsl,qman-channel-id = <0x1>;
                        fsl,liodn = <0x1 0x2>;
                };

The fsl,liodn property specifies the 2 io device numbers that allow
the distinction of 2 destination address spaces for DMA.

The first liodn allows the device to stash certain frame header
information directly to a CPU's cache.  The second is for normal
frame data.

There is only one "struct device" for this device, and thus we
now have an issue as iommu_attach_device() can't distinguish
which of the 2 address spaces are being configured.

Does anyone have any high level thoughts on how to solve
this problem?

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;

    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);


Regards,
Stuart
--
To unsubscribe from this list: send the line "unsubscribe kvm" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html


[Index of Archives]     [KVM ARM]     [KVM ia64]     [KVM ppc]     [Virtualization Tools]     [Spice Development]     [Libvirt]     [Libvirt Users]     [Linux USB Devel]     [Linux Audio Users]     [Yosemite Questions]     [Linux Kernel]     [Linux SCSI]     [XFree86]
  Powered by Linux