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

[Christian König]

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.
> As an example, for a H100 GPU with 80 GB of VRAM and a 4 KB system page
> size: we would need ~20 million entries, and with each 'struct page' as
> 64 bytes in size, this would amount to extra ~1.2 GB of RAM tax.

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.

For example we have MMIO doorbells which are exported between devices to signal to firmware that a certain event is done and follow up processing can start.

Using the struct page based approach to manage the lifetime of such exports would completely break such use cases.

> At this point, the series does not introduce any change on the
> exporter side and that is a good thing. No?

I need something like a free month to wrap my head around all that stuff again, but from the DMA-buf side the last patch set I've seen looked pretty straight forward.

So yes that no exporter or framework changes are necessary are definitely a good thing.

Regards,
Christian.