On Sat, Jan 19, 2019 at 11:46:22AM -0700, Logan Gunthorpe wrote:
> > Instead of having two tiny wrappers I'd just revert
> > 964f2311a6862f1fbcc044d0828ad90030928b7f if we need to pass a real
> > physical address now.
>
> Ok, I can resubmit this with that cleanup. Should I do it in two commits
>
On 2019-01-19 2:40 a.m., Christoph Hellwig wrote:
> Which resources do you plan to map? At least for PCIe P2P adding
> an address translation seems wrong to me.
It's mapping a PCI BAR but not for PCIe P2P. In this case, we are using
the Intel I/OAT DMA engine to copy data from a PCI BAR
On Fri, Jan 18, 2019 at 05:05:59PM -0700, Logan Gunthorpe wrote:
> However, this doesn't create the IOVA entries necessary for addresses
> mapped this way to work when the IOMMU is enabled. Thus, when the
> IOMMU is enabled, drivers relying on dma_map_resource() will trigger
> DMAR errors. We see
Currently the Intel IOMMU uses the default dma_[un]map_resource()
implementations does nothing and simply returns the physical address
unmodified.
However, this doesn't create the IOVA entries necessary for addresses
mapped this way to work when the IOMMU is enabled. Thus, when the
IOMMU is
4 matches
Mail list logo
