On 23.09.25 15:38, Jason Gunthorpe wrote: > 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.
Yeah, that's why i asked how VFIO gets the information which parts of the it's BAR should be part of the DMA-buf? That would be really interesting to know. Regards, Christian. > >> 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
