Messages in this thread | | | Subject | Re: [RFC 0/8] Copy Offload with Peer-to-Peer PCI Memory | From | Benjamin Herrenschmidt <> | Date | Wed, 19 Apr 2017 11:20:06 +1000 |
| |
On Tue, 2017-04-18 at 15:03 -0600, Jason Gunthorpe wrote: > I don't follow, when does get_dma_ops() return a p2p aware provider? > It has no way to know if the DMA is going to involve p2p, get_dma_ops > is called with the device initiating the DMA. > > So you'd always return the P2P shim on a system that has registered > P2P memory? > > Even so, how does this shim work? dma_ops are not really intended to > be stacked. How would we make unmap work, for instance? What happens > when the underlying iommu dma ops actually natively understands p2p > and doesn't want the shim?
Good point. We only know on a per-page basis ... ugh.
So we really need to change the arch main dma_ops. I'm not opposed to that. What we then need to do is have that main arch dma_map_sg, when it encounters a "device" page, call into a helper attached to the devmap to handle *that page*, providing sufficient context.
That helper wouldn't perform the actual iommu mapping. It would simply return something along the lines of:
- "use that alternate bus address and don't map in the iommu" - "use that alternate bus address and do map in the iommu" - "proceed as normal" - "fail"
What do you think ?
Cheers, Ben.
| |