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

[Pranjal Shrivastava <praan@google.com>]

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@google.com>
> ---
>  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