DMA-buf gains mapping types beyond scatterlists
A v2 series adds negotiated buffer mapping types so exporters can hand importers physical addresses, P2P paths, and private interconnects without abusing dma_addr_t.
Linux DMA-buf is gaining a formal mapping-types framework so exporters and importers can negotiate how buffer addresses are exchanged, instead of being locked to scatterlists and dma_addr_t.
Alistair Popple posted the second version of the series, built largely with Jason Gunthorpe. DMA-buf has long used scatterlists as the sole way to pass address information. That model cannot express what several modern users need: VFIO moving to IOMMUFD and KVM wants physical addresses, Intel’s xe vGPU path needs host conversion of a VF DMA-buf into PF VRAM addresses, private links such as XGMI already resort to driver-specific hacks, and future fabrics are looking past the DMA API entirely.
The design lists compatible mapping types at attach time, then lets the exporter pick one concrete type under the reservation lock at the first pin or map. That choice sticks until the exporter invalidates the attachment, so later unmap and remap cycles cannot bounce the buffer or thrash placement.
Scatter-gather table support is retained as a first-class mapping type and existing exporters across DRM, media, heaps, VFIO, RDMA, and other subsystems are converted to it. Drivers that already special-cased peer-to-peer distance checks (Habana, xe, amdgpu, InfiniBand uverbs) express those constraints through the match logic instead of ad-hoc attach hooks. Compatibility shims for the old map/unmap callbacks and attachment fields are then removed.
Follow-on work is planned for an iommufd importer type, a dedicated PCIe P2P type, and turning XGMI into an exclusive mapping. The change is infrastructure rather than a user-visible feature, but it removes a long-standing bottleneck for device passthrough, GPU sharing, and non-DMA interconnects.