Re: [PATCH v4 01/11] PCI: liveupdate: Set up FLB handler for the PCI core

[Pasha Tatashin <pasha.tatashin@soleen.com>]

On 04-27 23:59, David Matlack wrote:
> On 2026-04-24 01:29 PM, Pasha Tatashin wrote:
> > On 04-24 14:33, Pratyush Yadav wrote:
> > > Hi David,
> > > 
> > > On Thu, Apr 23 2026, David Matlack wrote:
> > > [...]
> > > > diff --git a/MAINTAINERS b/MAINTAINERS
> > > > index c9b7b6f9828e..94af31837375 100644
> > > > --- a/MAINTAINERS
> > > > +++ b/MAINTAINERS
> > > > @@ -20555,6 +20555,18 @@ L:	linux-pci@vger.kernel.org
> > > >  S:	Supported
> > > >  F:	Documentation/PCI/pci-error-recovery.rst
> > > >  
> > > > +PCI LIVE UPDATE
> > > > +M:	Bjorn Helgaas <bhelgaas@google.com>
> > > > +M:	David Matlack <dmatlack@google.com>
> > > > +L:	linux-pci@vger.kernel.org
> > > > +S:	Supported
> > > > +Q:	https://patchwork.kernel.org/project/linux-pci/list/
> > > > +B:	https://bugzilla.kernel.org
> > > > +C:	irc://irc.oftc.net/linux-pci
> > > > +T:	git git://git.kernel.org/pub/scm/linux/kernel/git/pci/pci.git
> > > > +F:	drivers/pci/liveupdate.c
> > > > +F:	include/linux/kho/abi/pci.h
> > > > +
> > > 
> > > Can we please also add these files under the "LIVE UPDATE" entry. The
> > > code here concerns both live update and PCI.
> 
> Covering that intersection of Live Update and PCI was exactly my
> intention with introducing this new PCI LIVE UPDATE entry. This ensures
> we have maintenance coverage with knowledge of that intersection.
> 
> > > We can figure out the
> > > maintenance details as we go along, but I think the live update
> > > maintainers should at least get all the patches for PCI live update.
> 
> Would adding kexec@ here be sufficient or do you want to be CC'd
> directly?
> 
> If you want to be CC'd directly do you think makes more sense to add the
> Live Update maintainers as Reviewers under PCI LIVE UPDATE, or add
> drivers/pci/liveupdate.c under LIVE UPDATE?
> 
> > > 
> > > Perhaps also add the kexec list here? We plan to use it to maintain the
> > > LUO patches, and adding it will make sure we get the patches in case
> > > someone updates the file list here but forgets to update it in the LIVE
> > > UPDATE entry.
> > 
> > +1
> > 
> > These files should also be added to the Live Update entry, and the kexec
> > mailing list should be included.
> > 
> > Changes specific to Live Update should be routed through the
> > liveupdate/linux.git tree, while generic PCI changes should go through
> > pci/pci.git. In either case, if liveupdate.c or abi/pci.h are modified,
> > acks are required from the Live Update group.
> 
> Do you want to merge changes to drivers/pci/liveupdate.c through the
> live update tree or PCI tree? We should probably decide now. I was
> assuming the PCI tree since its part of PCI core.
> 
> As we project this out there are going to be users of the Live Update
> API across different parts of the kernel: PCI core, IOMMU core, IOMMU
> drivers, VFIO core, VFIO PCI drivers, and KVM. I don't think it will
> scale to take all that code through the live update tree.

All Live-Update-specific changes should go through the liveupdate tree. 
The liveupdate tree is the only Linux tree that will cover full Live 
Update regression testing, and it contains reviewers and maintainers who 
know the details of the Live Update process, its lifecycle, and its 
requirements.

The request we are hearing from other subsystem maintainers is that they 
want to make sure Live Update is isolated enough not to make their lives 
harder. This means reducing the number of conflicts, the maintenance 
burden, and testing responsibilities.

Therefore, the "PCI LIVE UPDATE" entry should specify you as a 
maintainer, "kexec@lists.infradead.org" as the list to which all LU 
changes should be CC'd, and "liveupdate/linux.git" as the git tree 
against which changes should be applied.

It should also include "linux-pci@vger.kernel.org" so the PCI 
maintainers are CC'd. In case there are larger changes that touch core 
PCI and liveupdate.c/abi, we can ACK them, ensuring we are aware of 
incoming conflicts during the current or next merge cycle.

It should also specify the members of LU group so we can stage the 
changes.

This is the way we agreed to handle kexec changes: Baoquan He is the 
maintainer, and without his Reviewed-by tag, we won't take changes to 
kexec. This is the approach we follow with MM for KHO changes to 
memblock and memfd preservation, as well as the upcoming 
hugetlb/guestmemfd preservation. 

This is also the approach we should continue using when adding LUO 
support to other components like PCI, VFIO, IOMMU, and KVM. It keeps 
life easier for the core component maintainers and ensures we do not 
regress LU by staging everything in the same tree and sending LU merge 
requests from a single tree.

Pasha