Thread (25 messages) 25 messages, 7 authors, 2016-11-06

Re: [PATCH 0/3] iopmem : A block device for PCIe memory

From: Haggai Eran <hidden>
Date: 2016-10-26 08:40:13
Also in: linux-mm, linux-rdma, lkml, nvdimm

On 10/19/2016 6:51 AM, Dan Williams wrote:
On Tue, Oct 18, 2016 at 2:42 PM, Stephen Bates [off-list ref] wrote:
quoted
1. Address Translation. Suggestions have been made that in certain
architectures and topologies the dma_addr_t passed to the DMA master
in a peer-2-peer transfer will not correctly route to the IO memory
intended. However in our testing to date we have not seen this to be
an issue, even in systems with IOMMUs and PCIe switches. It is our
understanding that an IOMMU only maps system memory and would not
interfere with device memory regions.
I'm not sure that's the case. I think it works because with ZONE_DEVICE,
the iommu driver will simply treat a dma_map_page call as any other PFN,
and create a mapping as it does for any memory page.
quoted
(It certainly has no opportunity
to do so if the transfer gets routed through a switch).
It can still go through the IOMMU if you enable ACS upstream forwarding.
There may still be platforms where peer-to-peer cycles are routed up
through the root bridge and then back down to target device, but we
can address that when / if it happens.
I agree.
I wonder if we could (ab)use a
software-defined 'pasid' as the requester id for a peer-to-peer
mapping that needs address translation.
Why would you need that? Isn't it enough to map the peer-to-peer
addresses correctly in the iommu driver?

Haggai
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help