Re: [PATCH v4 1/5] PCI/P2PDMA: Don't enforce ACS check for device functions of Intel GPUs

[Jason Gunthorpe <jgg@nvidia.com>]

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