On Fri, Sep 18, 2026 at 08:06:32PM +0000, David Matlack wrote: > Keep the secondary and subordinate bus numbers that the previous kernel > programmed into bridges, rather than assigning new ones, if the previous > kernel preserved any device across a Live Update. Do this even on > architectures that would otherwise always assign bus numbers themselves, > e.g. when pci=assign-busses is passed. > > Preserved devices must be allowed to continue performing memory > transactions across a Live Update, so the kernel cannot change the > fabric topology. Changing the bus numbers of a bridge changes the > RequesterIDs of the devices below it, which would require disabling and > flushing any in-flight memory transactions first. > > Apply the policy globally rather than only to the paths that contain > preserved devices. Bus numbers have to be preserved above a preserved > device anyway, since an upstream bridge cannot expand its window. A > global policy matches the scope of pcibios_assign_all_busses(), and > gives an answer that cannot change part way through the two passes of a > bridge scan. > > Bridges that do not have bus numbers are still assigned new ones, so > hot-adding a bridge keeps working, both during and after a Live Update. > The two-pass bridge scan guarantees such bridges are only assigned bus > numbers above those already claimed by preserved bridges. > > The exception is a bridge that was preserved but comes up without a > valid bus number configuration, e.g. because it was reset during kexec. > Refuse to assign it new bus numbers, since that would silently change > the BDF of every preserved device in its hierarchy. Also refuse to > assign bus numbers to the other bridges on the same bus, since the bus > numbers of the failed bridge can no longer be read from hardware and > handing them out would let an unrelated device inherit the BDF of a > preserved device. > > Require that CONFIG_CARDBUS is not enabled to enable > CONFIG_PCI_LIVEUPDATE since preserving bus numbers on PCI-to-CardBus > bridges requires additional work but is not a priority at the moment. > > Signed-off-by: David Matlack <[email protected]>
Reviewed-by: Pranjal Shrivastava <[email protected]> Thanks, Praan
