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 <[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.
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
