On Mon, Sep 22, 2025 at 06:59:10AM +0000, Kasireddy, Vivek wrote: > > You can't translate a dma_addr_t to anything in the Xe PF driver > > anyhow, once it goes through the IOMMU the necessary information is lost. > Well, I already tested this path (via IOMMU, with your earlier vfio-pci + > dmabuf patch that used dma_map_resource() and also with Leon's latest > version) and found that I could still do the translation in the Xe PF driver > after first calling iommu_iova_to_phys().
I would NAK any driver doing something so hacky. You are approaching this completely wrong to abuse things like this. > that there are no memory copies and the CPU is not involved. And, I don't see > any other way to do this because I don't believe the exporter can provide a > DMA address that the importer can use directly without any translation, which > seems unavoidable in this case. This is sadly how dmabuf is designed, please talk to Christain to figure out how to exchage the right kind of address. > use-case. And, I sincerely hope that it will work, otherwise I don't see > any viable path forward for what I am trying to do other than using this > quirk and translation. You will not get a quirk. > PCIe fabric). Isn't that one of the main ideas behind using quirks -- to > address hardware limitations? This is not a hardware limitation. You are using DMABUF wrong, writing hacks into the PF driver and then trying to make up a fake ACS quirk :( Jason
