[LSF/MM/BPF TOPIC] dmabuf backed read/write

[Jason Gunthorpe]

On Mon, Feb 09, 2026 at 11:13:42AM +0100, Christian König wrote:
> On 2/9/26 10:54, Kanchan Joshi wrote:
> > On 2/6/2026 8:50 PM, Jason Gunthorpe wrote:
> >>> I'm actually curious, is there a way to somehow create a
> >>> MEMORY_DEVICE_PCI_P2PDMA mapping out of a random dma-buf?
> >> No. The driver owning the P2P MMIO has to do this during its probe and
> >> then it has to provide a VMA with normal pages so GUP works. This is
> >> usally not hard on the exporting driver side.
> >>
> >> It costs some memory but then everything works naturally in the IO
> >> stack.
> >>
> >> Your project is interesting and would be a nice improvement, but I
> >> also don't entirely understand why you are bothering when the P2PDMA
> >> solution is already fully there ready to go... Is something preventing
> >> you from creating the P2PDMA pages for your exporting driver?
> > 
> > The exporter driver may have opted out of the P2PDMA struct page path
> > (MEMORY_DEVICE_PCI_P2PDMA route). This maybe a design choice to avoid
> > the system RAM overhead.

Currently you have to pay this tax to use the block stack.

It is certainly bad on x86, but for example 64k page size ARM pays
only 83MB, for the same configuration.

> That is a good argumentation, but the killer argument for DMA-buf to
> not use pages (or folios) is that the exported resource is sometimes
> not even memory.

I don't think anyone is saying that all DMA-buf must use pages, just
that if you want to use the MMIO with the *block stack* then a page
based approach already exists and is already being used. Usually
through VMAs.

I'm aware of all the downsides, but this proposal doesn't explain
which ones are motivating the work. Is the lack of pre-registration or
the tax the main motivation?

Jason