Re: [PATCH v8 06/12] PCI: liveupdate: Auto-preserve upstream bridges across Live Update
From: Bjorn Helgaas
Date: Wed Sep 16 2026 - 20:21:07 EST
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++;