On Fri, May 22, 2026 at 08:24:07PM +0000, David Matlack wrote: > Inherit the ARI Forwarding Enable on preserved bridges and update > pci_dev->ari_enabled accordingly during a Live Update. This ensures that > the preserved devices on the bridge's secondary bus can be identified > with the same expanded 8-bit function number after a Live Update. > > Signed-off-by: David Matlack <[email protected]> > --- > drivers/pci/liveupdate.c | 18 ++++++++++++++++++ > drivers/pci/liveupdate.h | 6 ++++++ > drivers/pci/pci.c | 8 +++++++- > 3 files changed, 31 insertions(+), 1 deletion(-) > > diff --git a/drivers/pci/liveupdate.c b/drivers/pci/liveupdate.c > index a93b7ef065f2..701276ef6cfb 100644 > --- a/drivers/pci/liveupdate.c > +++ b/drivers/pci/liveupdate.c > @@ -128,6 +128,10 @@ > * way after Live Update and ensures that IOMMU groups do not change. Note > * that a device will use its inherited ACS flags for the lifetime of its > * struct pci_dev (i.e. even after pci_liveupdate_finish()). > + * > + * * The PCI core inherits ARI Forwarding Enable on all bridges with > downstream > + * preserved devices to ensure that all preserved devices on the bridge's > + * secondary bus are addressable after the Live Update. > */ > > #define pr_fmt(fmt) "PCI: liveupdate: " fmt > @@ -756,6 +760,20 @@ int pci_liveupdate_enable_acs(struct pci_dev *dev) > return 0; > } > > +int pci_liveupdate_configure_ari(struct pci_dev *dev) > +{ > + u16 val; > + > + guard(rwsem_read)(&pci_liveupdate.rwsem); > + > + if (!dev->liveupdate.incoming) > + return -EINVAL; > + > + pcie_capability_read_word(dev, PCI_EXP_DEVCTL2, &val);
Again, I might be thinking out loud here, but since these are hot-pluggable devices, with some FW / SW running on them, I'm a little worried while assuming the HW registers can be trusted across a kexec. Say, if the bridge experiences a reset (e.g. link drop etc) during the kexec blackout, the PCI_EXP_DEVCTL2 register could revert to its default state, meaning the ARI bit will be 0. In that scenario, pci_liveupdate_configure_ari() will read 0, set bridge->ari_enabled = false, and bypass the pci_configure_ari() logic as well, permanently leaving ARI disabled on the bridge. Any preserved downstream devices with function numbers > 7 will instantly become unaddressable, breaking the Live Update. Even if that's desired it gets hard to identify why the Liveupdate broke. Should ari_enabled be serialized with bridge's pci_ser to ensure we correctly restore / match it in case HW changed it during the kexec? > + dev->ari_enabled = !!(val & PCI_EXP_DEVCTL2_ARI); > + return 0; > +} > + [...] Thanks, Praan
