On Fri, Jan 10, 2025 at 08:24:22PM +0100, Simona Vetter wrote:
On Thu, Jan 09, 2025 at 01:56:02AM +0800, Xu Yilun wrote:
- iommufd and kvm are both using CPU addresses without DMA. No
exporter mapping is possible
We have customers using both KVM and XEN with DMA-buf, so I can clearly confirm that this isn't true.
Today they are mmaping the dma-buf into a VMA and then using KVM's follow_pfn() flow to extract the CPU pfn from the PTE. Any mmapable dma-buf must have a CPU PFN.
Yes, the final target for KVM is still the CPU PFN, just with the help of CPU mapping table.
I also found the xen gntdev-dmabuf is calculating pfn from mapped sgt.
See the comment, it's ok because it's a fake device with fake iommu and the xen code has special knowledge to peek behind the curtain.
/* * Now convert sgt to array of gfns without accessing underlying pages. * It is not allowed to access the underlying struct page of an sg table * exported by DMA-buf, but since we deal with special Xen dma device here * (not a normal physical one) look at the dma addresses in the sg table * and then calculate gfns directly from them. */ for_each_sgtable_dma_page(sgt, &sg_iter, 0) { dma_addr_t addr = sg_page_iter_dma_address(&sg_iter); unsigned long pfn = bfn_to_pfn(XEN_PFN_DOWN(dma_to_phys(dev, addr)));
*barf*
Can we please all agree that is a horrible abuse of the DMA API and lets not point it as some acceptable "solution"? KVM and iommufd do not have fake struct devices with fake iommus.
Jason