Hi Jason, > Subject: Re: [PATCH v4 1/5] PCI/P2PDMA: Don't enforce ACS check for device > functions of Intel GPUs > > On Thu, Sep 18, 2025 at 06:16:38AM +0000, Kasireddy, Vivek wrote: > > > However, assuming that pci_p2pdma_map_type() did not fail, based on > my > > experiments, the GPU PF is still unable to access the buffer located in VF's > > VRAM portion directly because it is represented using PCI BAR addresses. > > 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.
> > 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? 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. > > > > Do not open code quirks like this in random places, if this device > > > supports some weird ACS behavior and does not include it in the ACS > > > Caps the right place is to supply an ACS quirk in quirks.c so all the > > > code knows about the device behavior, including the iommu grouping. > > Ok, I'll move it to quirks.c. > > 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. > > > On my test system, it looks like the VFs and the PF are put into different > > iommu groups. I am checking with our hardware folks to understand how > this > > is expected to work but does it mean that P2P between PF and VF is not > > supported in my case? > > A special internal path through VRAM is outside the scope of iommu > grouping. The BAR to VRAM Address translation logic is being added to the Xe driver as part of this patch series, so, nothing else needs to be done except a way to enable the exporter(vfio-pci) to share the dmabuf with the PF without having to rely on the outcome of pci_p2pdma_map_type() in this use-case. Thanks, Vivek > > Jason
