Hi, > This is because of the fundamental concept of DMA-buf that the exporter > needs to setup mappings (both CPU page tables as well as stuff like IOMMU). > When the guest exports something it would mean that you give the guest > control over the IOMMU and/or host page tables. And that is not something > you can do as far as I can see. Correct. > You can only export stuff the other way around so that the host is providing > the memory and the guest is consuming it. If I understand it correctly > that's exactly what Gerd is suggesting here. It can also work the other way around (guest allocating and host consuming). That is just an implementation detail. The /important/ thing is that the driver which exports the dma-buf (and thus handles the mappings) must be aware of the virtualization so it can properly coordinate things with the host side. So vdmabuf allocating and exporting dma-bufs works. But vdmabuf importing dma-bufs doesn't because you can't ask the exporter to create *host* mappings as Christian outlined above. Sure, you can try to sidestep the exporter, fish the list of pages out of the scatter list and run with that. That will explode as soon as you meet a dma-buf which is not backed by pages in the first place. And even for page-backed dma-bufs you can run into trouble, for example due to mapping pages with the wrong caching attributes. Alternatively you can double-buffer and copy data from the imported dma-buf to some host-shared memory, but I guess you don't want that for performance reasons ... take care, Gerd _______________________________________________ dri-devel mailing list dri-devel@xxxxxxxxxxxxxxxxxxxxx https://lists.freedesktop.org/mailman/listinfo/dri-devel
