On 2025-10-27 01:44 PM, Jacob Pan wrote: > On Fri, 17 Oct 2025 17:06:58 -0700 Vipin Sharma <[email protected]> wrote: > > static int vfio_pci_liveupdate_retrieve(struct > > liveupdate_file_handler *handler, u64 data, struct file **file) > > { > > @@ -21,10 +28,17 @@ static int vfio_pci_liveupdate_retrieve(struct > > liveupdate_file_handler *handler, static bool > > vfio_pci_liveupdate_can_preserve(struct liveupdate_file_handler > > *handler, struct file *file) { > > - return -EOPNOTSUPP; > > + struct vfio_device *device = vfio_device_from_file(file); > > + > > + if (!device) > > + return false; > > + > > + guard(mutex)(&device->dev_set->lock); > > + return vfio_device_cdev_opened(device); > > IIUC, vfio_device_cdev_opened(device) will only return true after > vfio_df_ioctl_bind_iommufd(). Where it does: > device->cdev_opened = true; > > Does this imply that devices not bound to an iommufd cannot be > preserved?
Event if being bound to an iommufd is required, it seems wrong to check it in can_preserve(), as the device can just be unbound from the iommufd before preserve(). I think can_preserve() just needs to check if this is a VFIO cdev file, i.e. vfio_device_from_file() returns non-NULL. > > If so, I am confused about your cover letter step #15 > > 15. It makes usual bind iommufd and attach page table calls. > > Does it mean after restoration, we have to bind iommufd again? This is still being discussed. These are the two options currently: - When userspace retrieves the iommufd from LUO after kexec, the kernel will internally restore all VFIO cdevs and bind them to the iommufd in a single step. - Userspace will retrieve the iommufd and cdevs from LUO separately, and then bind each cdev to the iommufd like they were before kexec.
