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.