On Fri, Feb 27, 2026 at 09:32:33AM -0700, Alex Williamson wrote: > 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.
Well, this is a super complex problem overall and it has to start someplace digestible. There are real use cases of PF only devices, like GPUs for example, where this is entirely sufficient even without SRIOV support. I expect a long trickle of series building on an enhacing this mechanism one brick at a time. > 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. Well, I do, and am strongly advocating for this. As all these series show supporting live update in a kernel driver is fiendishly complex and most kernel drivers do more than just some bare minimum to operate a PF for SRIOV. Given we already have PF drivers in userspace and that is working well, lets start there. If people really want to tackle the nasty problems of a kernel side PF driver then they can go do that as a followup. > 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, Probably not without tremendous work to make the PF driver side kexecable. The initial use cases for this don't include VFIO migration, I think you could say people are interested in this significantly because VFIO migration isn't viable in the devices they want to use.. Sure it would be nice, but again, lets focus on the basic simple cases, nothing precludes building more and more complexity into the kernel to preserve more and more state across the kexec down the road. Jason
