On Thu, Feb 27, 2025 at 11:59:18AM +0800, Xu Yilun wrote: > On Wed, Feb 26, 2025 at 09:12:02AM -0400, Jason Gunthorpe wrote: > > 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 > > Not expecting mmap the MMIO, but I switched to another way. VFIO doesn't > disallow mmap until bind, and if there is mmap on bind, bind failed. > That's my understanding of your comments. That seems reasonable > Another concern is about dma-buf importer (e.g. KVM) mapping the MMIO. > Recall we are working on the VFIO dma-buf solution, on bind/unbind the > MMIO accessibility is being changed and importers should be notified to > remove their mapping beforehand, and rebuild later if possible. > An immediate requirement for Intel TDX is, KVM should remove secure EPT > mapping for MMIO before unbind. dmabuf can do that.. > > > 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 :) > > Could you elaborate more on that? Any locking problem if we implement > bind/unbind outside iommufd. Thanks in advance. You will be unable to access any information iommufd has in the viommu and vdevice objects. So you will not be able to pass a viommu ID or vBDF to the secure world unless you enter through an iommufd path, and use iommufd_get_object() to obtain the required locks. I don't know what the API signatures are for all three platforms to tell if this is a problem or not. Jason
