On Wed, Jun 04, 2025 at 02:39:19PM +0800, Xu Yilun wrote: > On Tue, Jun 03, 2025 at 09:08:10AM -0300, Jason Gunthorpe wrote: > > On Tue, Jun 03, 2025 at 11:47:33AM +0800, Xu Yilun wrote: > > > > > VFIO doesn't have enough information, but VFIO needs to know about > > > bound state. So comes the suggestion [1] that the VFIO uAPI, then VFIO > > > reach into iommufd for real bind. > > > > > > And my implementation [2] is: > > > > > > ioctl(vfio_cdev_fd, VFIO_DEVICE_TSM_BIND) > > > -> vfio_iommufd_tsm_bind() > > > -> iommufd_device_tsm_bind() > > > -> iommufd_vdevice_tsm_bind() > > > -> pci_tsm_bind() > > > > This doesn't work, logically you are binding the vdevice, not the > > idevice, the uapi should provide the vdevice id, which VFIO doesn't > > have. > > Yes. Sorry I just too lazy to provide the full API format. > > The original suggestion [1] is to provide vdevice_id in VFIO uAPI. > > [1] https://lore.kernel.org/all/20250515175658.GR382960@xxxxxxxxxx/ > > And here is a piece of the implementation in [2]: > > +struct vfio_pci_tsm_bind { > + __u32 argsz; > + __u32 flags; > + __u32 vdevice_id; > + __u32 pad; > +}; > + > +#define VFIO_DEVICE_TSM_BIND _IO(VFIO_TYPE, VFIO_BASE + 22) I don't want to pass iommufd IDs through vfio as much as possibile, it makes no logical sense. > > If you really need vfio involvement then you need callbacks, I think. > > Only callback is not enough, there are cases that VFIO wants actively > invalidate MMIO, e.g. VFIO_DEVICE_RESET. In that case, VFIO needs > dynamic unbind then invalidate MMIO. We've already talked about reset, Alexeys solution is good it is not a problem. Block FLR on bound devices. Jason
