PCIe host controller behind IOMMU on ARM

[Phil Edworthy]

Hi Will,

On 04 November 2015 15:30, Will wrote:
> On Wed, Nov 04, 2015 at 03:19:13PM +0000, Phil Edworthy wrote:
> > On 04 November 2015 15:02, Liviu wrote:
> > > On Wed, Nov 04, 2015 at 02:48:38PM +0000, Phil Edworthy wrote:
> > > > Sure, though since this is bog standard Intel PCIe ethernet card which works
> > > > fine when the IOMMU is effectively unused, I don’t think there is a problem
> > > > with that.
> > > >
> > > > The driver for the PCIe controller sets up the IOMMU mapping ok when I
> > > > do a test call to dma_alloc_coherent() in the controller's driver. i.e. when I
> > > > do this, it ends up in arm_iommu_alloc_attrs(), which calls
> > > > __iommu_alloc_buffer() and __alloc_iova().
> > > >
> > > > When an endpoint driver allocates and maps a dma coherent buffer it
> > > > also needs to end up in arm_iommu_alloc_attrs(), but it doesn't.
> > >
> > > Why do you think that? Remember that the only thing attached to the
> IOMMU is
> > > the
> > > host controller. The endpoint is on the PCIe bus, which gets a different
> > > translation
> > > that the IOMMU knows nothing about. If it helps you to visualise it better,
> think
> > > of the host controller as another IOMMU device. It's the ops of the host
> > > controller
> > > that should be invoked, not the IOMMU's.
> > Ok, that makes sense. I'll have a think and poke it a bit more...
> 
> Take a look at of_iommu_configure, which is currently lacking support
> for PCI devices. It should be using a variant on the device-tree bindings
> already in use for describing MSI device IDs, so that we can translate
> the RequesterID of the endpoint into an ID that the IOMMU can understand.
Whilst we want to introduce isolation at some point, right now we would like
to use the IOMMU as this PCIe controller only uses a 32-bit AXI address.

Thanks
Phil