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
