On Tue, Sep 23, 2025 at 02:45:10PM +0200, Christian König wrote: > On 23.09.25 14:15, Jason Gunthorpe wrote: > > On Tue, Sep 23, 2025 at 09:52:04AM +0200, Christian König wrote: > >> For example the ISP driver part of amdgpu provides the V4L2 > >> interface and when we interchange a DMA-buf with it we recognize that > >> it is actually the same device we work with. > > > > One of the issues here is the mis-use of dma_map_resource() to create > > dma_addr_t for PCI devices. This was never correct. > > That is not a mis-use at all but rather exactly what > dma_map_resource() was created for.
No, it isn't this is a misunderstanding. It was created for SOC resources only. I think HCH made this clear a number of times. > If dma_map_resource() is not ACS aware than we should add that. It can't be fixed with the API it has. See how the new VFIO patches are working to understand the proposal. > > We have many cases now where a dma_addr_t is not the appropriate way > > to exchange addressing information from importer/exporter and we need > > more flexibility. > > > > I also consider the KVM and iommufd use cases that must have a > > phys_addr_t in this statement. > > Abusing phys_addr_t is also the completely wrong approach in that moment. > > When you want to communicate addresses in a device specific address > space you need a device specific type for that and not abuse > phys_addr_t. I'm not talking about abusing phys_addr_t, I'm talking about putting a legitimate CPU address in there. You can argue it is hack in Xe to reverse engineer the VRAM offset from a CPU physical, and I would be sympathetic, but it does allow VFIO to be general not specialized to Xe. > The real question is where does the VFIO gets the necessary > information which parts of the BAR to expose? It needs a varaint driver that understands to reach into the PF parent and extract this information. There is a healthy amount of annoyance to building something like this. > > From this thread I think if VFIO had the negotiated option to export a > > CPU phys_addr_t then the Xe PF driver can reliably convert that to a > > VRAM offset. > > > > We need to add a CPU phys_addr_t option for VFIO to iommufd and KVM > > anyhow, those cases can't use dma_addr_t. > > Clear NAK to using CPU phys_addr_t. This is just a horrible idea. We already talked about this, Simona agreed, we need to get phys_addr_t optionally out of VFIO's dmabuf for a few importers. We cannot use dma_addr_t. Jason
