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

[Jason Gunthorpe <jgg@nvidia.com>]

On Fri, Sep 19, 2025 at 06:22:45AM +0000, Kasireddy, Vivek wrote:
> > In this case messing with ACS is completely wrong. If the intention is
> > to convay a some kind of "private" address representing the physical
> > VRAM then you need to use a DMABUF mechanism to do that, not deliver a
> > P2P address that the other side cannot access.

> I think using a PCI BAR Address works just fine in this case because the Xe
> driver bound to PF on the Host can easily determine that it belongs to one
> of the VFs and translate it into VRAM Address.

That isn't how the P2P or ACS mechansim works in Linux, it is about
the actual address used for DMA.

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. This is a fundamentally broken design to dma map something and
then try to reverse engineer the dma_addr_t back to something with
meaning.

> > Christian told me dmabuf has such a private address mechanism, so
> > please figure out a way to use it..
>
> Even if such as a mechanism exists, we still need a way to prevent
> pci_p2pdma_map_type() from failing when invoked by the exporter (vfio-pci).
> Does it make sense to move this quirk into the exporter?

When you export a private address through dmabuf the VFIO exporter
will not call p2pdma paths when generating it.

> Also, AFAICS, translating BAR Address to VRAM Address can only be
> done by the Xe driver bound to PF because it has access to provisioning
> data. In other words, vfio-pci would not be able to share any other
> address other than the BAR Address because it wouldn't know how to
> translate it to VRAM Address.

If you have a vfio varient driver then the VF vfio driver could call
the Xe driver to create a suitable dmabuf using the private
addressing. This is probably what is required here if this is what you
are trying to do.

> > No, don't, it is completely wrong to mess with ACS flags for the
> > problem you are trying to solve.

> But I am not messing with any ACS flags here. I am just adding a quirk to
> sidestep the ACS enforcement check given that the PF to VF access does
> not involve the PCIe fabric in this case.

Which is completely wrong. These are all based on fabric capability,
not based on code in drivers to wrongly "translate" the dma_addr_t.

Jason