On Thu, Oct 22, 2026 at 09:25:55AM +0200, Thomas Hellström wrote:
Attachment could also scan existing attachments to preferentially pick matching mapping_types that are compatible with existing attachments, thus avoiding invalidation where possible.
Current design appears to be that attach only determines the set of theoretically possible mapping types, disregarding other attachments. Taking other attachments into account is also problematic because the dma-resv lock is not held.
Stating my restriction in a different way, the attach may start with {ualink, pcie} as options. Then we do the first map and select ualink.
Then we get an invalidation and do a second map. Here we need a way to change the mapping type options to {ualink}.
The exporter would have to make the memory visible on ualink to succeed the map.
Looking at current GPU drivers, what you describe above is typically done at pin() time, but if some importers want an early very likely decision on what mapping_type to use, one could introduce a separate function that match the mapping_types, but that would be very similar to the map() function but without returning a sgt/mapping, or a pin() without actually pinning. One could reuse the invalidate_mappings() callback to indicate the mapping type is no longer valid?
I don't know that anyone needs a very early decision, but mlx5 certainly needs something like the above flow..
Jason