On Thu, 26 Feb 2026 00:28:28 +0000 David Matlack <[email protected]> wrote: > > > +static int pci_flb_preserve(struct liveupdate_flb_op_args *args) > > > +{ > > > + struct pci_dev *dev = NULL; > > > + int max_nr_devices = 0; > > > + struct pci_ser *ser; > > > + unsigned long size; > > > + > > > + for_each_pci_dev(dev) > > > + max_nr_devices++; > > > > How is this protected against hotplug? > > Pranjal raised this as well. Here was my reply: > > . Yes, it's possible to run out space to preserve devices if devices are > . hot-plugged and then preserved. But I think it's better to defer > . handling such a use-case exists (unless you see an obvious simple > . solution). So far I am not seeing preserving hot-plugged devices > . across Live Update as a high priority use-case to support. > > I am going to add a comment here in the next revision to clarify that. > I will also add a comment clarifying why this code doesn't bother to > account for VFs created after this call (preserving VFs are explicitly > disallowed to be preserved in this patch since they require additional > support).
TBH, without SR-IOV support and some examples of in-kernel PF preservation in support of vfio-pci VFs, it seems like this only supports a very niche use case. I expect the majority of vfio-pci devices are VFs and I don't think we want to present a solution where the requirement is to move the PF driver to userspace. It's not clear, for example, how we can have vfio-pci variant drivers relying on in-kernel channels to PF drivers to support migration in this model. Thanks, Alex
