Re: [PATCH v6 09/12] PCI: liveupdate: Inherit ARI Forwarding Enable on preserved bridges

From: Jason Gunthorpe

Date: Mon Jun 08 2026 - 14:21:15 EST


On Mon, Jun 08, 2026 at 11:33:07AM +0000, Pranjal Shrivastava wrote:
> 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 <dmatlack@xxxxxxxxxx>
> > ---
> > 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.

This does seem like something to be concerned about, but realistically
I think if you get a PCIe error I'm not sure the incoming kernel is
equipped to handle it at all :\

Just resuming the driver is going to fail too, I don't know how VFIO
can learn and forward the event, and so on..

But maybe it is worth being a little more defensive here

Jason