Re: [PATCH v7 01/12] PCI: liveupdate: Set up FLB handler for the PCI core

David Matlack <[email protected]> Mon, 27 Jul 2026 13:06:04 -0700
Newsgroups org.infradead.lists.kexec,org.kernel.vger.linux-doc,org.kernel.vger.linux-kernel,org.kernel.vger.linux-pci,org.kvack.linux-mm
Message-ID <CALzav=d1u5fuOgodeGKiFKPhMOx5xrdvgOeNqWfj-C7ZRG-EdQ@mail.gmail.com>
On Mon, Jul 27, 2026 at 12:27 PM Bjorn Helgaas <[email protected]> wrote:
>
> On Mon, Jul 27, 2026 at 10:40:52AM -0700, David Matlack wrote:
> > On Thu, Jul 23, 2026 at 3:21 PM Bjorn Helgaas <[email protected]> wrote:
> > > On Fri, Jul 10, 2026 at 09:26:04PM +0000, David Matlack wrote:
> > > > Set up a File-Lifecycle-Bound (FLB) handler for the PCI core to enable
> > > > it to participate in the preservation of PCI devices across Live Update.
> > > > Essentially, this commit enables the PCI core to allocate a struct
> > > > (struct pci_ser) and preserve it across a Live Update whenever at least
> > > > one device is preserved.
> > > > ...
> > >
> > > > +#define pr_fmt(fmt) "PCI: " KBUILD_BASENAME ": " fmt
> > >
> > > Is KBUILD_BASENAME buying us something important here?  Just from
> > > code-reading perspective, it's more work because without some digging
> > > I don't know what it will end up looking like in a dmesg log.
> > >
> > > > +static void pci_flb_unpreserve(struct liveupdate_flb_op_args *args)
> > > > +{
> > > > +     struct pci_flb_outgoing *outgoing = args->obj;
> > > > +
> > > > +     WARN_ON(outgoing->ser->nr_devices);
> > > > +     kho_block_set_destroy(&outgoing->block_set);
> > > > +     kho_unpreserve_free(outgoing->ser);
> > > > +     kfree(outgoing);
> > > > +     pr_debug("Unpreserved struct pci_ser\n");
> > >
> > > If this pr_debug() is useful, maybe it should include an address and
> > > there should be a corresponding pr_debug() on the preserve side so we
> > > could find things in a crashdump?
> > >
> > > > +int pci_liveupdate_register_flb(struct liveupdate_file_handler *fh)
> > > > +{
> > > > +     pr_debug("Registering file handler \"%s\"\n", fh->compatible);
> > >
> > > Is fh->compatible enough to identify a driver?
> >
> > Not necessarily. VFIO could theoretically have one file handler that
> > handles all the vfio-pci variant drivers. But I suspect we'll end up
> > with 1 fh per driver in practice.
> >
> > Are you thinking about how we can ensure devices are bound to
> > compatible drivers after Live Update?
>
> No, I don't understand enough to worry about things like that.  I'm
> just wondering if there's enough info in the message to be useful,
> since fh->compatible is the only text that's variable.  Same reason I
> asked about the "Unpreserved struct pci_ser" message above.  E.g., if
> a user reports these messages, will we need more information to debug
> it, or is the message itself enough?

Ah ok. From that perspective, I think this be sufficient to confirm
that VFIO has registered it's file handler for devices bound to
vfio-pci, which is all this log needs to do IMO.