On Wed, Jun 26, 2019 at 12:31:08PM -0600, Logan Gunthorpe wrote: > > we have a hole behind len where we could store flag. Preferably > > optionally based on a P2P or other magic memory types config > > option so that 32-bit systems with 32-bit phys_addr_t actually > > benefit from the smaller and better packing structure. > > That seems sensible. The one thing that's unclear though is how to get > the PCI Bus address when appropriate. Can we pass that in instead of the > phys_addr with an appropriate flag? Or will we need to pass the actual > physical address and then, at the map step, the driver has to some how > lookup the PCI device to figure out the bus offset? I agree with CH, if we go down this path it is a layering violation for the thing injecting bio's into the block stack to know what struct device they egress&dma map on just to be able to do the dma_map up front. So we must be able to go from this new phys_addr_t&flags to some BAR information during dma_map. For instance we could use a small hash table of the upper phys addr bits, or an interval tree, to do the lookup. The bar info would give the exporting struct device and any other info we need to make the iommu mapping. This phys_addr_t seems like a good approach to me as it avoids the struct page overheads and will lets us provide copy from/to bio primitives that could work on BAR memory. I think we can surely use this approach in RDMA as well. Jason
