On Tue, 2013-10-08 at 10:47 -0600, Bjorn Helgaas wrote: > On Thu, Oct 3, 2013 at 11:19 PM, Bhushan Bharat-R65777 > <r65...@freescale.com> wrote: > > >> I don't know enough about VFIO to understand why these new interfaces are > >> needed. Is this the first VFIO IOMMU driver? I see > >> vfio_iommu_spapr_tce.c and > >> vfio_iommu_type1.c but I don't know if they're comparable to the Freescale > >> PAMU. > >> Do other VFIO IOMMU implementations support MSI? If so, do they handle the > >> problem of mapping the MSI regions in a different way? > > > > PAMU is an aperture type of IOMMU while other are paging type, So they are > > completely different from what PAMU is and handle that differently. > > This is not an explanation or a justification for adding new > interfaces. I still have no idea what an "aperture type IOMMU" is, > other than that it is "different." But I see that Alex is working on > this issue with you in a different thread, so I'm sure you guys will > sort it out.
PAMU is a very constrained IOMMU that cannot do arbitrary page mappings. Due to these constraints, we cannot map the MSI I/O page at its normal address while also mapping RAM at the address we want. The address we can map it at depends on the addresses of other mappings, so it can't be hidden in the IOMMU driver -- the user needs to be in control. Another difference is that (if I understand correctly) PCs handle MSIs specially, via interrupt remapping, rather than being translated as a normal memory access through the IOMMU. -Scott _______________________________________________ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
