On 2026-09-16 07:18 PM, Bjorn Helgaas wrote: > On Fri, Sep 11, 2026 at 05:00:10PM +0000, David Matlack wrote: > > On 2026-09-10 06:51 PM, Bjorn Helgaas wrote: > > > On Tue, Jul 28, 2026 at 10:10:00PM +0000, David Matlack wrote: > > > > When a PCI device is preserved across a Live Update, all of its upstream > > > > bridges up to the root port must also be preserved. This enables the PCI > > > > core and any drivers bound to the bridges to manage bridges correctly > > > > across a Live Update. > > > > > > > > Notably, this will be used in subsequent commits to ensure that > > > > preserved devices can continue performing memory transactions without a > > > > disruption or change in routing. > > > > > > > > To preserve bridges, the PCI core tracks the number of downstream > > > > devices preserved under each bridge using a reference count in struct > > > > pci_dev_ser. This allows a bridge to remain preserved until all its > > > > downstream preserved devices are unpreserved or finish their > > > > participation in the Live Update. > > > > > > This seems to hint that we're going to allow bridge reconfiguration in > > > some cases, e.g., for hot-adds. The simplest case is "leave config of > > > all bridges the same", and I thought that was what the previous patch > > > commit log said. > > > > > > What's the benefit added by this patch? > > > > It is used in the following patches: > > > > PCI: liveupdate: Adopt ACS controls in incoming preserved devices > > PCI: liveupdate: Adopt ARI Forwarding Enable on preserved bridges > > PCI: liveupdate: Do not disable bus mastering on preserved devices during > > kexec > > > > to preserve certain configuration on bridges that have downstream > > endpoints that are being preserved. To support P2PDMA we will also have > > to preserve bridge memory windows (future series). > > > > If we are ok with applying those policies to all bridges on the system > > whenever one or more endpoints anywhere on the system are being > > preserved, then I agree we don't need this patch. But I thought it would > > be cleaner to track things per-device. > > Yes, I agree tracking it per-device is good. I was looking for a > traversal upstream to increment refcounts on bridges, and I guess that > happens via for_each_pci_dev_in_path() in pci_liveupdate_preserve(). > > The actual refcount still confuses me a bit (see > https://lore.kernel.org/all/20260917000723.GA992337@bhelgaas). Maybe > it would help if pci_liveupdate_preserve_device() alloc the dev_ser > *first* (right after all the bail-out checks)? I wonder if the > refcount increment could then happen in exactly one place, separated > from the one-time dev_ser housekeeping? E.g., something like: > > if (!dev->liveupdate.outgoing) { > dev_ser = pci_flb_alloc_dev_ser(outgoing); > ... > dev->liveupdate.outgoing = dev_ser; > } > > dev->liveupdate.outgoing->refcount++;
Ack, will fix
