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

[Jason Gunthorpe <jgg@nvidia.com>]

On Tue, Sep 23, 2025 at 03:28:53PM +0200, Christian König wrote:
> On 23.09.25 15:12, Jason Gunthorpe wrote:
> >> When you want to communicate addresses in a device specific address
> >> space you need a device specific type for that and not abuse
> >> phys_addr_t.
> > 
> > I'm not talking about abusing phys_addr_t, I'm talking about putting a
> > legitimate CPU address in there.
> > 
> > You can argue it is hack in Xe to reverse engineer the VRAM offset
> > from a CPU physical, and I would be sympathetic, but it does allow
> > VFIO to be general not specialized to Xe.
> 
> No, exactly that doesn't work for all use cases. That's why I'm
> pushing back so hard on using phys_addr_t or CPU addresses.
> 
> See the CPU address is only valid temporary because the VF BAR is
> only a window into the device memory.

I know, generally yes.

But there should be no way that a VFIO VF driver in the hypervisor
knows what is currently mapped to the VF's BAR. The only way I can
make sense of what Xe is doing here is if the VF BAR is a static
aperture of the VRAM..

Would be nice to know the details.
 
> What Simona agreed on is exactly what I proposed as well, that you
> get a private interface for exactly that use case.

A "private" interface to exchange phys_addr_t between at least
VFIO/KVM/iommufd - sure no complaint with that.

Jason