From: Hans de Goede <hansg@kernel.org>
To: Lukas Wunner <lukas@wunner.de>, David Airlie <airlied@redhat.com>,
Bjorn Helgaas <helgaas@kernel.org>
Cc: Ben Hutchings <ben@decadent.org.uk>,
Joerg Roedel <joro@8bytes.org>,
Suravee Suthikulpanit <suravee.suthikulpanit@amd.com>,
Andi Kleen <ak@linux.intel.com>, Ahmed Salem <x0rw3ll@gmail.com>,
Borislav Petkov <bp@alien8.de>,
Thomas Gleixner <tglx@linutronix.de>,
dri-devel@lists.freedesktop.org, iommu@lists.linux.dev,
linux-pci@vger.kernel.org
Subject: Re: [PATCH v2] agp/amd64: Check AGP Capability before binding to unsupported devices
Date: Thu, 3 Jul 2025 10:46:12 +0200 [thread overview]
Message-ID: <81db2fce-34db-46e7-8c68-bc4cb1a03d25@kernel.org> (raw)
In-Reply-To: <b29e7fbfc6d146f947603d0ebaef44cbd2f0d754.1751468802.git.lukas@wunner.de>
Hi Lukas,
On 2-Jul-25 5:15 PM, Lukas Wunner wrote:
> Since commit 172efbb40333 ("AGP: Try unsupported AGP chipsets on x86-64
> by default"), the AGP driver for AMD Opteron/Athlon64 CPUs has attempted
> to bind to any PCI device possessing an AGP Capability.
>
> Commit 6fd024893911 ("amd64-agp: Probe unknown AGP devices the right
> way") subsequently reworked the driver to perform a bind attempt to
> any PCI device (regardless of AGP Capability) and reject a device in
> the driver's ->probe() hook if it lacks the AGP Capability.
>
> On modern CPUs exposing an AMD IOMMU, this subtle change results in an
> annoying message with KERN_CRIT severity:
>
> pci 0000:00:00.2: Resources present before probing
>
> The message is emitted by the driver core prior to invoking a driver's
> ->probe() hook. The check for an AGP Capability in the ->probe() hook
> happens too late to prevent the message.
>
> The message has appeared only recently with commit 3be5fa236649 (Revert
> "iommu/amd: Prevent binding other PCI drivers to IOMMU PCI devices").
> Prior to the commit, no driver could bind to AMD IOMMUs.
>
> The reason for the message is that an MSI is requested early on for the
> AMD IOMMU, which results in a call from msi_sysfs_create_group() to
> devm_device_add_group(). A devres resource is thus attached to the
> driver-less AMD IOMMU, which is normally not allowed, but presumably
> cannot be avoided because requesting the MSI from a regular PCI driver
> might be too late.
>
> Avoid the message by once again checking for an AGP Capability *before*
> binding to an unsupported device. Achieve that by way of the PCI core's
> dynid functionality.
>
> pci_add_dynid() can fail only with -ENOMEM (on allocation failure) or
> -EINVAL (on bus_to_subsys() failure). It doesn't seem worth the extra
> code to propagate those error codes out of the for_each_pci_dev() loop,
> so simply error out with -ENODEV if there was no successful bind attempt.
> In the -ENOMEM case, a splat is emitted anyway, and the -EINVAL case can
> never happen because it requires failure of bus_register(&pci_bus_type),
> in which case there's no driver probing of PCI devices.
>
> Hans has voiced a preference to no longer probe unsupported devices by
> default (i.e. set agp_try_unsupported = 0). In fact, the help text for
> CONFIG_AGP_AMD64 pretends this to be the default. Alternatively, he
> proposes probing only devices with PCI_CLASS_BRIDGE_HOST. However these
> approaches risk regressing users who depend on the existing behavior.
>
> Fixes: 3be5fa236649 (Revert "iommu/amd: Prevent binding other PCI drivers to IOMMU PCI devices")
> Reported-by: Fedor Pchelkin <pchelkin@ispras.ru>
> Closes: https://lore.kernel.org/r/wpoivftgshz5b5aovxbkxl6ivvquinukqfvb5z6yi4mv7d25ew@edtzr2p74ckg/
> Reported-by: Hans de Goede <hansg@kernel.org>
> Closes: https://lore.kernel.org/r/20250625112411.4123-1-hansg@kernel.org/
> Signed-off-by: Lukas Wunner <lukas@wunner.de>
> ---
> Changes v1 -> v2:
> * Use pci_add_dynid() to bind only to devices with AGP Capability
> (based on a suggestion from Ben).
> * Rephrase commit message to hopefully explain the history more accurately.
> Explain why resources are attached to the driver-less AMD IOMMU
> (requested by Ben).
> * Acknowledge Hans as reporter.
Thank you for the new version.
I can confirm that this fixes the issue for me and the code also looks
good to me:
Tested-by: Hans de Goede <hansg@kernel.org>
Reviewed-by: Hans de Goede <hansg@kernel.org>
Regards,
Hans
> drivers/char/agp/amd64-agp.c | 16 ++++++++--------
> 1 file changed, 8 insertions(+), 8 deletions(-)
>
> diff --git a/drivers/char/agp/amd64-agp.c b/drivers/char/agp/amd64-agp.c
> index bf490967241a..2505df1f4e69 100644
> --- a/drivers/char/agp/amd64-agp.c
> +++ b/drivers/char/agp/amd64-agp.c
> @@ -720,11 +720,6 @@ static const struct pci_device_id agp_amd64_pci_table[] = {
>
> MODULE_DEVICE_TABLE(pci, agp_amd64_pci_table);
>
> -static const struct pci_device_id agp_amd64_pci_promisc_table[] = {
> - { PCI_DEVICE_CLASS(0, 0) },
> - { }
> -};
> -
> static DEFINE_SIMPLE_DEV_PM_OPS(agp_amd64_pm_ops, NULL, agp_amd64_resume);
>
> static struct pci_driver agp_amd64_pci_driver = {
> @@ -739,6 +734,7 @@ static struct pci_driver agp_amd64_pci_driver = {
> /* Not static due to IOMMU code calling it early. */
> int __init agp_amd64_init(void)
> {
> + struct pci_dev *pdev = NULL;
> int err = 0;
>
> if (agp_off)
> @@ -767,9 +763,13 @@ int __init agp_amd64_init(void)
> }
>
> /* Look for any AGP bridge */
> - agp_amd64_pci_driver.id_table = agp_amd64_pci_promisc_table;
> - err = driver_attach(&agp_amd64_pci_driver.driver);
> - if (err == 0 && agp_bridges_found == 0) {
> + for_each_pci_dev(pdev)
> + if (pci_find_capability(pdev, PCI_CAP_ID_AGP))
> + pci_add_dynid(&agp_amd64_pci_driver,
> + pdev->vendor, pdev->device,
> + pdev->subsystem_vendor,
> + pdev->subsystem_device, 0, 0, 0);
> + if (agp_bridges_found == 0) {
> pci_unregister_driver(&agp_amd64_pci_driver);
> err = -ENODEV;
> }
next prev parent reply other threads:[~2025-07-03 8:46 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-07-02 15:15 [PATCH v2] agp/amd64: Check AGP Capability before binding to unsupported devices Lukas Wunner
2025-07-03 8:46 ` Hans de Goede [this message]
2025-07-03 19:29 ` Andi Kleen
2025-07-07 12:53 ` Hans de Goede
2025-07-07 13:58 ` Lukas Wunner
2025-07-17 23:40 ` Bjorn Helgaas
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=81db2fce-34db-46e7-8c68-bc4cb1a03d25@kernel.org \
--to=hansg@kernel.org \
--cc=airlied@redhat.com \
--cc=ak@linux.intel.com \
--cc=ben@decadent.org.uk \
--cc=bp@alien8.de \
--cc=dri-devel@lists.freedesktop.org \
--cc=helgaas@kernel.org \
--cc=iommu@lists.linux.dev \
--cc=joro@8bytes.org \
--cc=linux-pci@vger.kernel.org \
--cc=lukas@wunner.de \
--cc=suravee.suthikulpanit@amd.com \
--cc=tglx@linutronix.de \
--cc=x0rw3ll@gmail.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).