On Mon, 2026-10-19 at 10:35 +0200, Christian König wrote:
> On 10/16/26 22:26, Karl Mehltretter wrote:
> > On Tue, Feb 17, 2026 at 08:11:34PM -0400, Jason Gunthorpe wrote:
> > > + match_args.attach = attach;
> > > + if (dmabuf->ops->match_mapping) {
> > > + ret = dmabuf->ops->match_mapping(&match_args);
> > > + }
> > > +
> > > attach->dmabuf = dmabuf;
> > > attach->importer_ops = importer_ops;
> > > attach->importer_priv = importer_priv;
> >
> > I may misunderstand the intended contract. match_mapping() runs
> > while the
> > attachment is still zeroed and without dmabuf->resv held.
> >
> > Patch 11's amdgpu callback needs importer_ops and importer_priv, so
> > its XGMI
> > match cannot work here. Patch 12's VFIO callback asserts dmabuf-
> > >resv and
> > reads priv->vdev, which cleanup changes under that lock.
> >
> > Should the core initialize the attachment and hold dmabuf->resv for
> > match_mapping(), or should callbacks avoid attachment and lock-
> > protected
> > state?
>
> Right. This completely misplaced.
>
> The matching can't be done at attachment time, but rather needs to be
> done before creating a mapping while holding the resv lock so that
> the matching decision can't change.
So question is what exactly should the contract be?
Looking at the pcie_p2p negotiation today it looks somewhat like.
1) Importer and exporter agree at attach time what mappings are allowed
pending placement conditions and other attachers.
2) At map-time the mapping is negotiated taking all constraints into
account.
3) The negotiated mapping is valid until an invalidate_mappings()
callback is received.
Following this would allow a re-implementation of pcie_p2p as a mapping
type and would allow a controlled link-severing to send an
invalidate_mappings() notifier and the mappings to be re-negotiated.
Importers requiring an early hint as to what the actual mapping would
look like would need to be prepared to re-consider at map-time, with a
reasonable assumption that the reconsideration and re-mapping would
happen seldom enough.
Thanks,
Thomas
>
> Regards,
> Christian.
>
> >
> > Thanks,
> > Karl
