DMA-buf gains mapping types beyond scatterlist
A revised series lets exporters pick how buffers are described at pin or map time, aiming at VFIO, vGPU, and private links.
Alistair Popple has posted a second version of Jason Gunthorpe's DMA-buf mapping-types work on the dri-devel list, keeping the framework and scatter-gather conversions from the earlier RFC while moving final type choice to the first pin or map of a buffer.
Since DMA-buf appeared, exporters and importers have exchanged addresses only through scatterlists built on dma_addr_t. That model cannot carry the physical addresses VFIO, IOMMUFD, and KVM need, nor the internal VRAM handles an Xe vGPU path requires when a VF hands a buffer back to its PF, and it forces private interconnects such as XGMI into driver-specific workarounds. The series adds a negotiation step: importers and exporters advertise compatible mapping types at attach time, then the exporter selects one under the reservation lock when the buffer is first pinned or mapped, and the core holds that choice until the exporter invalidates the attachment so unmap and remap cannot bounce the buffer.
Popple says later work will add an iommufd importer type, split PCIe peer-to-peer into its own type, and treat XGMI as exclusive. The series also renames long-standing SGT-only attach, map, and unmap helpers so existing drivers keep a clear path, and it ships KUnit coverage for match rules and the pin/map selection contract.
Automated review from Sashiko flagged several defects, including a possible NULL dereference when dynamic attach is called without importer ops, unsafe use of attachment helpers before null checks, and error paths that clear or leave the selected type in inconsistent ways. Karl Mehltretter reproduced a map-after-pin failure case in which a failed map dropped a type chosen by an earlier successful pin, and suggested the select helper report whether it made a fresh choice so only that choice is undone.