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
