On Thu, Oct 30, 2025 at 7:10 PM David Matlack dmatlack@google.com wrote:
On 2025-10-27 01:44 PM, Jacob Pan wrote:
On Fri, 17 Oct 2025 17:06:58 -0700 Vipin Sharma vipinsh@google.com 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.
+1, can_preserve() must be fast, as it might be called on every single FD that is being preserved, to check if type is correct. So, simply check if "struct file" is cdev via ops check perhaps via and thats it. It should be a very simple operation
If so, I am confused about your cover letter step #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.