On Wed, Nov 26, 2025 at 07:35:53PM +0000, David Matlack wrote:
> From: Vipin Sharma <[email protected]>
> static int vfio_pci_liveupdate_retrieve(struct liveupdate_file_op_args *args)
> {
> - return -EOPNOTSUPP;
> + struct vfio_pci_core_device_ser *ser;
> + struct vfio_device *device;
> + struct folio *folio;
> + struct file *file;
> + int ret;
> +
> + folio = kho_restore_folio(args->serialized_data);
> + if (!folio)
> + return -ENOENT;
Should this be consistent with the behavior of pci_flb_retrieve() which panics
on failure? The short circuit failure paths which follow leak the folio,
which seems like a hygiene issue, but the practical significance is moot if
vfio_pci_liveupdate_retrieve() failure is catastrophic anyways?
> +
> + ser = folio_address(folio);
> +
> + device = vfio_find_device(ser, match_device);
> + if (!device)
> + return -ENODEV;
> +
> + /*
> + * During a Live Update userspace retrieves preserved VFIO cdev files by
> + * issuing an ioctl on /dev/liveupdate rather than by opening VFIO
> + * character devices.
> + *
> + * To handle that scenario, this routine simulates opening the VFIO
> + * character device for userspace with an anonymous inode. The returned
> + * file has the same properties as a cdev file (e.g. operations are
> + * blocked until BIND_IOMMUFD is called), aside from the inode
> + * association.
> + */
> + file = anon_inode_getfile_fmode("[vfio-device-liveupdate]",
> + &vfio_device_fops, NULL,
> + O_RDWR, FMODE_PREAD | FMODE_PWRITE);
> +
> + if (IS_ERR(file)) {
> + ret = PTR_ERR(file);
> + goto out;
> + }
> +
> + ret = __vfio_device_fops_cdev_open(device, file);
> + if (ret) {
> + fput(file);
> + goto out;
> + }
> +
> + args->file = file;
> +
> +out:
> + /* Drop the reference from vfio_find_device() */
> + put_device(&device->device);
> +
> + return ret;
> +}
