Re: [PATCH] drm/amdgpu: Gate VFCT bus fallback on pci=realloc

[Bjorn Helgaas <helgaas@kernel.org>]

On Thu, Oct 15, 2026 at 03:25:17PM -0500, Mario Limonciello wrote:
> On 10/15/26 14:48, Bjorn Helgaas wrote:
> > [+cc Alex, Ilpo, Lukas, linux-acpi]
> > 
> > On Thu, Oct 15, 2026 at 07:48:42AM -0500, Mario Limonciello wrote:
> > > The soft filter system introduced by commit 11c141672045f ("drm/amdgpu:
> > > Fix VFCT bus number matching with soft filter") has a deficiency that
> > > it won't work when there are multiple GPUs of the exact same model.
> > > 
> > > As it was introduced specifically to help the case of pci=realloc, gate
> > > it to only run when that's in use.
> > > 
> > > Fixes: 11c141672045f ("drm/amdgpu: Fix VFCT bus number matching with soft filter")
> > > Reported-by: Reza Nikzad Chaleshori <rezanikzadch@gmail.com>
> > > Closes: https://lore.kernel.org/amd-gfx/20261014080523.186533-1-rezanikzadch@gmail.com/
> > > Signed-off-by: Mario Limonciello <mario.limonciello@amd.com>
> > > ---
> > >   drivers/gpu/drm/amd/amdgpu/amdgpu_bios.c | 15 ++++++++-------
> > >   drivers/pci/setup-bus.c                  |  5 +++++
> > >   include/linux/pci.h                      |  1 +
> > >   3 files changed, 14 insertions(+), 7 deletions(-)
> > > 
> > > diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_bios.c b/drivers/gpu/drm/amd/amdgpu/amdgpu_bios.c
> > > index 08ed1eb695586..75af9a59671ae 100644
> > > --- a/drivers/gpu/drm/amd/amdgpu/amdgpu_bios.c
> > > +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_bios.c
> > > @@ -384,12 +384,10 @@ static bool amdgpu_read_disabled_bios(struct amdgpu_device *adev)
> > >    * @vhdr: VFCT image header to check
> > >    *
> > >    * VFCT entries contain the PCI bus number as recorded during BIOS POST.
> > > - * On systems where the kernel renumbers PCI buses (e.g. pci=realloc or
> > > - * resource conflicts), the runtime bus number may differ from the POST
> > > - * value.  Match by device identity (vendor + device + function) and use
> > > - * the bus number as a preference: exact bus match is preferred, but when
> > > - * the bus numbers disagree we accept the entry if the device identity
> > > - * matches.
> > > + * On systems where the user requested PCI resource reallocation, the
> > > + * runtime bus number may differ from the POST value. Match by device
> > > + * identity (vendor + device + function), but only treat the bus number as
> > > + * a preference when pci=realloc was explicitly requested.
> > 
> > This is a generic problem, isn't it?
> > 
> > I think any table from firmware that has PCI bus numbers in it could
> > trip over issues like this.  Seems like we need a more generic
> > solution.
> 
> Yeah; it's a generic issue which was triggered by pci=realloc which is why I
> did a soft filter in 11c141672045f.
> 
> But this causes problems when you have two (or more) of the exact same
> device.  You might match the wrong thing.
> 
> > >    *
> > >    * Returns: 0 on match, -ENODEV on no match
> > >    */
> > > @@ -409,7 +407,10 @@ static int amdgpu_acpi_vfct_match(struct amdgpu_device *adev,
> > >   	if (vhdr->PCIBus == adev->pdev->bus->number)
> > >   		return 0;
> > > -	/* Bus mismatch but device identity matches (PCI renumbering case) */
> > > +	/* Allow bus renumbering only when the user requested pci=realloc. */
> > > +	if (!pci_realloc_enabled_by_user())
> > > +		return -ENODEV;
> > > +
> > >   	dev_notice(adev->dev,
> > >   		   "VFCT bus number mismatch: table %u != runtime %u, matching by device identity (vendor 0x%04x device 0x%04x)\n",
> > >   		   vhdr->PCIBus, adev->pdev->bus->number,
> > > diff --git a/drivers/pci/setup-bus.c b/drivers/pci/setup-bus.c
> > > index ed16ef7c26fa7..d9450585082c0 100644
> > > --- a/drivers/pci/setup-bus.c
> > > +++ b/drivers/pci/setup-bus.c
> > > @@ -1799,6 +1799,11 @@ static bool pci_realloc_enabled(enum enable_type enable)
> > >   	return enable >= user_enabled;
> > >   }
> > > +bool pci_realloc_enabled_by_user(void)
> > > +{
> > > +	return pci_realloc_enable == user_enabled;
> > > +}
> > 
> > I don't like this.  I think the same bus renumbering can happen in the
> > "auto_enabled" case, and I don't think we set pci_realloc_enable in
> > that case.
> > 
> > But more generally, I think ultimately the PCI core should be able to
> > reassign bus numbers arbitrarily to accommodate hotplugs (given the
> > appropriate driver support to tolerate that, of course).
> 
> Could we keep track of the original perhaps?  Then drivers can know
> what it was reassigned from?

I think the only thing that can change is the bus number, and saving
the original bus number in a struct pci_bus or similar might be
practical?