On Thu, 2026-10-22 at 08:52 -0300, Jason Gunthorpe wrote:
> 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.
That sounds like detaching and reattaching with a different set of
options. Would that be a fit?
/Thomas
>
> > 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
