Success!
I've implemented a new intel_map_resource (and intel_unmap_resource)
routine which is called by dma_map_resource. As mentioned previously,
the primary job of dma_map_resource/intel_map_resource is to call the
intel iommu internal mapping routine (__intel_map_single) without
translating the pci bar address into a page and then back to a phys addr
as dma_map_page and dma_map_single are doing.
With the new dma_map_resource routine mapping the pci bar address in
ntb_transport_tx_submit, I was still getting the "PTE Write access is
not set" error.
The __intel_map_single routine sets prot based on the DMA direction.
if (dir == DMA_TO_DEVICE || dir == DMA_BIDIRECTIONAL || \
!cap_zlr(iommu->cap))
prot |= DMA_PTE_READ;
if (dir == DMA_FROM_DEVICE || dir == DMA_BIDIRECTIONAL)
prot |= DMA_PTE_WRITE;
I was able to finally succeed in doing the dma transfers over ioat only
when prot has DMA_PTE_WRITE set by setting the direction to either
DMA_FROM_DEVICE or DMA_BIDIRECTIONAL. Any ideas if the prot settings
need to be changed? Are there any bad side effects if I used
DMA_BIDIRECTIONAL?
Given that using the pci bar address as is without getting an iommu
address results in the same "PTE Write access" error, I wonder if there
is some internal 'prot' associated with the non-translated pci bar
address that just needs to be tweaked to include DMA_PTE_WRITE???
Thanks!
On 08/10/2018 10:46 AM, Dave Jiang wrote:
On 08/10/2018 10:15 AM, Logan Gunthorpe wrote:
On 10/08/18 11:01 AM, Dave Jiang wrote:
Or if the BIOS has provided mapping for the Intel NTB device
specifically? Is that a possibility? NTB does go through the IOMMU.
I don't know but if the BIOS is doing it, but that would only at best
work for Intel NTB.... I see no hope in getting the BIOS to map the MW
for a Switchtec NTB device...
Right. I'm just speculating why it may possibly work. But yes, I think
kernel will need appropriate mapping if it's not happening right now.
Hopefully Kit is onto something.
Logan
