Hi Jason,
> Subject: Re: [PATCH v4 1/5] PCI/P2PDMA: Don't enforce ACS check for device
> functions of Intel GPUs
>
> 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.
>
> The use of the VF's BAR in this series is an ugly hack.
IIUC, it is a common practice among GPU drivers including Xe and Amdgpu
to never expose VRAM Addresses and instead have BAR addresses as DMA
addresses when exporting dmabufs to other devices. Here is the relevant code
snippet in Xe:
phys_addr_t phys = cursor.start +
xe_vram_region_io_start(tile->mem.vram);
size_t size = min_t(u64, cursor.size, SZ_2G);
dma_addr_t addr;
addr = dma_map_resource(dev, phys, size, dir,
DMA_ATTR_SKIP_CPU_SYNC);
And, here is the one in amdgpu:
for_each_sgtable_sg((*sgt), sg, i) {
phys_addr_t phys = cursor.start + adev->gmc.aper_base;
unsigned long size = min(cursor.size,
AMDGPU_MAX_SG_SEGMENT_SIZE);
dma_addr_t addr;
addr = dma_map_resource(dev, phys, size, dir,
DMA_ATTR_SKIP_CPU_SYNC);
And, AFAICS, most of these drivers don't see use the BAR addresses directly
if they import a dmabuf that they exported earlier and instead do this:
if (dma_buf->ops == &xe_dmabuf_ops) {
obj = dma_buf->priv;
if (obj->dev == dev &&
!XE_TEST_ONLY(test && test->force_different_devices)) {
/*
* Importing dmabuf exported from out own gem increases
* refcount on gem itself instead of f_count of dmabuf.
*/
drm_gem_object_get(obj);
return obj;
}
}
>The PF never actually uses the VF BAR
That's because the PF can't use it directly, most likely due to hardware
limitations.
>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.
>
> All they want is either the actual VRAM address or the CPU physical.
The problem here is that the CPU physical (aka BAR Address) is only
usable by the CPU. Since the GPU PF only understands VRAM addresses,
the current exporter (vfio-pci) or any VF/VFIO variant driver cannot provide
the VRAM addresses that the GPU PF can use directly because they do not
have access to the provisioning data.
However, it is possible that if vfio-pci or a VF/VFIO variant driver had access
to the VF's provisioning data, then it might be able to create a dmabuf with
VRAM addresses that the PF can use directly. But I am not sure if exposing
provisioning data to VFIO drivers is ok from a security standpoint or not.
Thanks,
Vivek
>
> Jason
