On Fri, Jun 06, 2025 at 11:40:30PM +0800, Xu Yilun wrote: > On Wed, Jun 04, 2025 at 09:37:47AM -0300, Jason Gunthorpe wrote: > > On Wed, Jun 04, 2025 at 11:47:14AM +1000, Alexey Kardashevskiy wrote: > > > > > If it is the case of killing QEMU - then there is no usespace and > > > then it is a matter of what fd is closed first - VFIO-PCI or > > > IOMMUFD, we could teach IOMMUFD to hold an VFIO-PCI fd to guarantee > > > the order. Thanks, > > > > It is the other way around VFIO holds the iommufd and it always > > destroys first. > > > > We are missing a bit where the vfio destruction of the idevice does > > not clean up the vdevice too. > > Seems there is still problem, the suggested flow is: > > 1. VFIO fops release > 2. vfio_pci_core_close_device() > 3. vfio_df_iommufd_unbind() > 4. iommufd_device_unbind() > 5. iommufd_device_destroy() > 6. iommufd_vdevice_destroy() (not implemented) > 7. iommufd_vdevice_tsm_unbind() > > In step 2, vfio pci does all cleanup, including invalidate MMIO. > In step 7 vdevice does tsm unbind, this is not correct. TSM unbind > should be done before invalidating MMIO. > > TSM unbind should always the first thing to do to release lockdown, > then cleanup physical device configuration. I think you'd have to re-order things so that vfio_df_iommufd_unbind() happens before the mmio invalidate.. And if you can succeed in moving the MMIO mapping to bind/unbind then the invalidate from vfio won't matter. Jason
