Re: [PATCH v7 00/12] PCI: liveupdate: PCI core support for Live Update

[David Matlack <dmatlack@google.com>]

On 2026-07-10 09:26 PM, David Matlack wrote:
> This series can be found on GitHub:
> 
>   https://github.com/dmatlack/linux/tree/liveupdate/pci/base/v7
> 
> This series introduces initial support in the PCI core for Live Update,
> enabling drivers to preserve PCI devices across a kexec-based kernel
> update without interrupting the device. This functionality is critical
> for minimizing downtime in environments where PCI devices (e.g., those
> assigned to VMs via VFIO) must continue operating or maintain state
> across a host kernel upgrade.
> 
> Specifically, this series allows preserved PCI devices to perform
> uninterrupted memory transactions (DMA) to/from system memory across a
> Live Update. These devices can be behind a bridge but must not be VFs.
> Support for P2P and VF preservation will be addressed in future series.

> David Matlack (12):
>   PCI: liveupdate: Set up FLB handler for the PCI core
>   PCI: liveupdate: Track outgoing preserved PCI devices
>   PCI: liveupdate: Track incoming preserved PCI devices
>   PCI: liveupdate: Document driver binding responsibilities
>   PCI: liveupdate: Keep bus numbers constant during Live Update
>   PCI: liveupdate: Auto-preserve upstream bridges across Live Update
>   PCI: Refactor matching logic for pci_dev_acs_ops
>   PCI: liveupdate: Inherit ACS flags in incoming preserved devices
>   PCI: liveupdate: Inherit ARI Forwarding Enable on preserved bridges
>   PCI: liveupdate: Freeze preservation status during shutdown
>   PCI: liveupdate: Do not disable bus mastering on preserved devices
>     during kexec
>   Documentation: PCI: Add documentation for Live Update
> 
>  Documentation/PCI/index.rst                   |   1 +
>  Documentation/PCI/liveupdate.rst              |  29 +
>  .../admin-guide/kernel-parameters.txt         |   6 +-
>  Documentation/core-api/liveupdate.rst         |   5 +
>  MAINTAINERS                                   |  15 +
>  drivers/pci/Kconfig                           |  15 +
>  drivers/pci/Makefile                          |   1 +
>  drivers/pci/liveupdate.c                      | 910 ++++++++++++++++++
>  drivers/pci/liveupdate.h                      |  68 ++
>  drivers/pci/pci-driver.c                      |   9 +-
>  drivers/pci/pci.c                             |  14 +-
>  drivers/pci/pci.h                             |   5 +
>  drivers/pci/probe.c                           |  22 +-
>  drivers/pci/quirks.c                          |  58 +-
>  include/linux/kho/abi/pci.h                   |  59 ++
>  include/linux/pci.h                           |   4 +
>  include/linux/pci_liveupdate.h                |  77 ++
>  17 files changed, 1260 insertions(+), 38 deletions(-)
>  create mode 100644 Documentation/PCI/liveupdate.rst
>  create mode 100644 drivers/pci/liveupdate.c
>  create mode 100644 drivers/pci/liveupdate.h
>  create mode 100644 include/linux/kho/abi/pci.h
>  create mode 100644 include/linux/pci_liveupdate.h

Bjorn,

Do you have a preference of whether to merge this series through
liveupdate.git or pci.git once it's ready? (Mike Rapoport asked if we
could make a decision on the merge plan.)

I am leaning toward liveupdate.git:

 1. There are some LUO core changes around how FLBs are refcounted in
    the next branch of liveupdate.git that this series depends on.

 2. We had previously agreed that the files covered by the PCI LIVE
    UPDATE maintainer entry would be merged through the liveupdate.git
    tree (which is the majority of this series), so this would be
    following that process.

    PCI LIVE UPDATE
    ...
    T:     git git://git.kernel.org/pub/scm/linux/kernel/git/liveupdate/linux.git
    F:     Documentation/PCI/liveupdate.rst
    F:     drivers/pci/liveupdate.c
    F:     drivers/pci/liveupdate.h
    F:     include/linux/kho/abi/pci.h
    F:     include/linux/pci_liveupdate.h

But if you prefer landing the initial series in pci.git I think we can
expose a stable branch in liveupdate.git to handle (1).

What would be your preference?