On Wed, Sep 16, 2026 at 11:58 AM Pratyush Yadav <[email protected]> wrote: > > On Wed, Sep 16 2026, David Matlack wrote: > > > On Wed, Sep 16, 2026 at 11:25 AM Pratyush Yadav <[email protected]> wrote: > >> > >> On Wed, Sep 16 2026, David Matlack wrote: > >> > >> > On Tue, Sep 15, 2026 at 8:31 PM Zhu Yanjun <[email protected]> wrote: > >> >> 在 2026/7/28 15:09, David Matlack 写道: > >> > > >> >> > CONFIG_64BIT is now required to enable CONFIG_PCI_LIVEUPDATE so that > >> >> > the > >> >> > domain and bdf can be guaranteed to fit in an unsigned long and be > >> >> > used > >> >> > as the xarray key. > >> > > >> >> > diff --git a/drivers/pci/Kconfig b/drivers/pci/Kconfig > >> >> > index 3781e2b5f095..8af20f558086 100644 > >> >> > --- a/drivers/pci/Kconfig > >> >> > +++ b/drivers/pci/Kconfig > >> >> > @@ -273,7 +273,7 @@ config VGA_ARB_MAX_GPUS > >> >> > > >> >> > config PCI_LIVEUPDATE > >> >> > bool "PCI Live Update Support" > >> >> > - depends on PCI && LIVEUPDATE > >> >> > + depends on PCI && LIVEUPDATE && 64BIT > >> >> > >> >> One question about adding 64BIT to the dependency: > >> >> > >> >> As I understand it, enabling CONFIG_64BIT essentially means that we are > >> >> building a 64-bit kernel, and a 32-bit architecture cannot normally > >> >> enable CONFIG_64BIT. > >> >> > >> >> If that is the case, would depends on 64BIT be necessary here? Or is PCI > >> >> Live Update already inherently restricted to 64-bit architectures by the > >> >> existing LIVEUPDATE/architecture configuration, so that this dependency > >> >> would be redundant? > >> >> > >> >> If this problem has already discussed, I am very sorry about this. > >> > > >> > The necessity is that the PCI core needs to store more than 32-bits in > >> > the unsigned long xarray key (see the snippet above). The dependency > >> > on CONFIG_64BIT ensures that unsigned long is big enough. We could > >> > probably remove the dependency but I would rather wait until someone > >> > with a 32-bit build has a real use-case for using PCI_LIVEUPDATE > >> > before putting any effort into it. > >> > >> KHO or live update themselves don't support 32-bit platforms and there > >> are no plans to do so either. So I don't think you even need to have a > >> dependency on 64BIT in PCI_LIVEUPDATE. Only 64 bit architectures define > >> ARCH_SUPPORTS_KEXEC_HANDOVER, so PCI_LIVEUPDATE and others indirectly > >> inherit the dependency. > >> > >> If you'd like to be extra safe, then probably you should add a > >> dependency to 64BIT in KEXEC_HANDOVER directly. Though I think that can > >> be a separate patch independent from this series. > > > > It should be in both places then. PCI_LIVEUPDATE explicitly requires > > 64BIT for its own use of unsigned long, so it should have an explicit > > dependency. If KEXEC_HANDOVER requires 64-bit for its own specific > > purposes, then it should have an explicit Kconfig dependency as well. > > That way if and when someone wants to add 32-bit support we know > > exactly which configs need to add support. > > Well, I don't think we are ever adding 32-bit support. Most 32-bit > support in the kernel is being deprecated or removed, so I really don't > think it makes much sense to extend KHO/live update to 32-bit > architectures. > > But anyway, if you'd like to explicitly mark PCI as needing 64-bit, that > sounds fine too in the very very unlikely event we do add 32-bit > support.
Agree we will probably never add support for 32-bit to KEXEC_HANDOVER and PCI_LIVEUPDATE. But I do prefer explicitly documenting the dependency. It costs nothing and makes the 64-bit requirement crystal clear, just in case someone tries to do something crazy :)
