On Thu, 2026-10-22 at 18:20 +1100, Alistair Popple wrote:
On 2026-10-22 at 17:59 +1100, Thomas Hellström thomas.hellstrom@linux.intel.com wrote...
On Wed, 2026-10-21 at 09:37 -0300, Jason Gunthorpe wrote:
On Wed, Oct 21, 2026 at 08:24:40AM +0200, Thomas Hellström wrote:
struct dma_buf_mapping_exp_ops Base type for the per-mapping type exporter provided functions. This would be the map/unmap callbacks. Each mapping type can provide its own functions for map/unmap type operations with optimal type signatures.
Does it make sense to try to land this patch first, plus a conversion of pcie_p2p so we could agree on what the contract should look like?
I think it would be good to focus on this patch as the main 'crux' of the series. The API contract is the main agreement. I'm relucant to merge code that has no users, so it woudl be ebtter to go up to at least through SGT.
I agree about unused code, but wouldn't a pcie_p2p conversion to a mapping type be a valid use-case?
In some ways I think having both sgt and the pcie_p2p conversion is helpful as it demonstrates how different mapping types are used. I agree the important bit is settling on the contract though. Adding a pcie_p2p conversion on top doesn't look too hard though. Thomas would you be ok if I rebased and posted some of your patches[1] adding pcie_p2p on top of the mapping types + SGT conversion v2 I'm getting ready to send to demonstrate usage? Or would you rather do that after I send?
Please go ahead and use them as you wish. That was only a quick mostly AI-generated POC.
Thanks, Thomas
[1] - https://gitlab.freedesktop.org/thomash/xe-vibe/-/commit/7452df0fc858a7dc5cca...
- Alistair
s/mapping/interconnect/? My gut feeling is that "interconnect" best describes what's typically going on, but "mapping" perhaps better describes all cases.
My intention was to cover more than just the phyiscal transport. We do really want to get away from scatterlist, so having PCIe map with scatterlist and PCIe map with <something else> still ends up with two mapping types in the system.
This is why I choose the name over interconnect.
Location of common protocols which typically carry cross- subsystem dependencies? drivers/dma-buf/mapping_types? drivers/dma-buf/interconnects?
I'd encourage people to design more like PCI where the actual *interconnect* has its own home and there is just some minor call outs from dmabuf to help the matching logic.
As discussed previously: Agree on theoretically possible matches at attach time, Match at mapping time and guarantee the match is valid until invalidate_mappings().
I was thinking about this some more, and I'm less sure now.
If I think about mlx5, in a multi-path PCIe configuration, it can move the translation around within a single PCIe path, but it cannot move it to another path without creating disruption for the application. This is a HW limitation in how the internal routing works..
I strongly suspect this will be the norm for any hardware that doesn't rely on decorated page tables to select the IO path..
So, while I agree we should support hardware that can fully change the path on each and every map, we also need to suport hardware that must pin the path during attach.
Probably this points to needing a 'pin' operation for the mapping selection after attach.
+/*
- Match items are generated by the importer using the
DMA_BUF_IMAPPING_*() and
- the exporter using the DMA_BUF_EMAPPING_*() functions.
Each mapping type
- defines its own signature with its own data to make the
match and attachment.
- */
+struct dma_buf_mapping_match {
- const struct dma_buf_mapping_type *type;
- const struct dma_buf_mapping_exp_ops *exp_ops;
- union {
/* Each mapping_type has unique matchparameters here */
- };
Do we really need to add all global mapping types here? Then we'd need something for driver-private mapping types as well.
IIRC it is fixed size up front like this because of how the structure's memory is managed in this design..
If you want a driver private thing then I'd add a 'u64 driver_private[2]' to the union and the driver can cast over it.
But this is the kernel, if you want to add an xe_mapping_type, then just add it. I don't know we need to do driver private things.
I guess it's my wish to separate components. Couldn't this lead to excessive includes and unnecessary dma-buf recompilations when mostly unrelated headers are touched? Except possibly for memory size, core dma-buf shouldn't need to know about this, it's a mapping private thing?
/Thomas
Jason