On 2019-07-02 4:45 p.m., Jason Gunthorpe wrote: > On Fri, Jun 28, 2019 at 01:35:42PM -0600, Logan Gunthorpe wrote: > >>> However, I'd feel more comfortable about that assumption if we had >>> code to support the IOMMU case, and know for sure it doesn't require >>> more info :( >> >> The example I posted *does* support the IOMMU case. That was case (b1) >> in the description. The idea is that pci_p2pdma_dist() returns a >> distance with a high bit set (PCI_P2PDMA_THRU_HOST_BRIDGE) when an IOMMU >> mapping is required and the appropriate flag tells it to call >> dma_map_resource(). This way, it supports both same-segment and >> different-segments without needing any look ups in the map step. > > I mean we actually have some iommu drivers that can setup P2P in real > HW. I'm worried that real IOMMUs will need to have the BDF of the > completer to route completions back to the requester - which we can't > trivially get through this scheme. I've never seen such an IOMMU but I guess, in theory, it could exist. The IOMMUs that setup P2P-like transactions in real hardware make use of dma_map_resource(). There aren't a lot of users of this function (it's actually been broken with the Intel IOMMU until I fixed it recently and I'd expect there are other broken implementations); but, to my knowledge, none of them have needed the BDF of the provider to date. > However, maybe that is just a future problem, and certainly we can see > that with an interval tree or otherwise such a IOMMU could get the > information it needs. Yup, the rule of thumb is to design for the needs we have today not imagined future problems. Logan
