Re: Pinned, non-revocable mappings of VRAM: will bad things happen?

["Christian König" <christian.koenig@amd.com>]

On 4/16/26 01:27, Demi Marie Obenour wrote:
> Is it safe to assume that if a dmabuf exporter cannot handle
> non-revocable, pinned importers, it will fail the import?  Or is
> using dma_buf_pin() unsafe if one does not know the exporter?

Neither.

dma_buf_pin() makes sure that the importer doesn't get any invalidation notifications because the exporter moves the backing store of the buffer around for memory management.

But what is still possible is that the exporter is hot removed, in which case the importer should basically terminate it's DMA operation as soon as possible.

GPU drivers usually reject pin requests to VRAM from DMA-buf importers when that isn't restricted by cgroups for example, because that can otherwise easily result in a deny of service.

Amdgpu only recently started to allow pinning into VRAM to support RDMA without ODP (I think it was ODP, but could be that I mixed up the RDMA three letter code for that feature).

> For context, Xen grant tables do not support revocation.  One can ask
> the guest to unmap the grants, but if the guest doesn't obey the only
> recourse is to ungracefully kill it.  They also do not support page
> faults, so the pages must be pinned.  Right now, grant tables don't
> support PCI BAR mappings, but that's fixable.

That sounds like an use case for the DMA-buf pin interface.

> How badly is this going to break with dGPU VRAM, if at all?  I know
> that AMDGPU has a fallback when the BAR isn't mappable.  What about
> other drivers?  Supporting page faults the way KVM does is going to
> be extremely hard, so pinned mappings and DMA transfers are vastly
> preferable.

Well if you only want to share a fixed amount of VRAM then that is pretty much ok.

But when the client VM can trigger pinning on demand without any limitation you can pretty easily have deny of service against the host. That is usually a rather bad idea.

Regards,
Christian.