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. > 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! If you have a device internal connection then you need special handling between your PF and VF 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? Regards, Christian. > > All they want is either the actual VRAM address or the CPU physical. > > Jason
