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
