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

[Jason Gunthorpe <jgg@nvidia.com>]

On Mon, Sep 22, 2025 at 02:25:15PM +0200, Christian König wrote:
> On 22.09.25 14:20, Jason Gunthorpe wrote:
> > On Mon, Sep 22, 2025 at 01:22:49PM +0200, Christian König wrote:
> > 
> >> Well what exactly is happening here? You have a PF assigned to the
> >> host and a VF passed through to a guest, correct?
> >>
> >> And now the PF (from the host side) wants to access a BAR of the VF?
> > 
> > Not quite.
> > 
> > It is a GPU so it has a pool of VRAM. The PF can access all VRAM and
> > the VF can access some VRAM.
> > 
> > They want to get a DMABUF handle for a bit of the VF's reachable VRAM
> > that the PF can import and use through it's own funciton.
> 
> Yeah, where's the problem? We do that all the time.

Well this is the problem:

> > The use of the VF's BAR in this series is an ugly hack. The PF never
> > actually uses the VF BAR, it just hackily converts the dma_addr_t back
> > to CPU physical and figures out where it is in the VRAM pool and then
> > uses a PF centric address for it.
> 
> Oh my, please absolutely don't do that!

Great.

> If you have a device internal connection then you need special
> handling between your PF and VF driver.

Generic VFIO can't do something like that, so they would need to make
a special variant VFIO driver.

> But I still don't have the full picture of who is using what here,
> e.g. who is providing the DMA-buf handle and who is using it?

Generic VFIO is the exporer, the xe driver is the importer.

Jason