On Wed, Feb 26, 2025 at 06:49:18PM +0800, Xu Yilun wrote: > E.g. I don't think VFIO driver would expect its MMIO access suddenly > failed without knowing what happened. What do people expect to happen here anyhow? Do you still intend to mmap any of the MMIO into the hypervisor? No, right? It is all locked down? So perhaps the answer is that the VFIO side has to put the device into CC mode which disables MMAP/etc, then the viommu/vdevice iommufd object can control it. > Back to your concern, I don't think it is a problem. From your patch, > vIOMMU doesn't know the guest BDFn by nature, it is just the user > stores the id in vdevice via iommufd_vdevice_alloc_ioctl(). A proper > VFIO API could also do this work. We don't want duplication though. If the viommu/vdevice/vbdf are owned and lifecycle controlled by iommufd then the operations against them must go through iommufd and through it's locking regime. > > The implementation is basically no difference from: > > + vdev = container_of(iommufd_get_object(ucmd->ictx, cmd->vdevice_id, > + IOMMUFD_OBJ_VDEVICE), > > The real concern is the device owner, VFIO, should initiate the bind. There is a big different, the above has correct locking, the other does not :) Jason
