From: Bjorn Helgaas <helgaas@kernel.org>
To: Joerg Roedel <joro@8bytes.org>
Cc: Mario Limonciello <mario.limonciello@amd.com>, linux-pci@vger.kernel.org
Subject: Re: does amd_iommu use INTx?
Date: Mon, 25 Mar 2024 16:33:59 -0500 [thread overview]
Message-ID: <20240325213359.GA1435356@bhelgaas> (raw)
In-Reply-To: <ZgEycC1c_d0RTPHW@8bytes.org>
On Mon, Mar 25, 2024 at 09:14:40AM +0100, Joerg Roedel wrote:
> On Fri, Mar 22, 2024 at 06:35:11PM -0500, Bjorn Helgaas wrote:
> > This is probably a stupid question, but does the AMD IOMMU itself ever
> > generate INTx interrupts, i.e., would it assert INTA, INTB, INTC,
> > INTD?
>
> The AMD IOMMU hardware only signals IRQs via MSI, there is no hardware
> using INTx.
It seems that the IOMMU advertises 01h (INTA) in the Interrupt Pin
register, not 00h (doesn't use an interrupt pin). Is that a hardware
defect, or do you mean the hardware is *capable* of using INTA, but
the Linux driver only uses MSI?
If the hardware truly can't use INTx at all, I wonder if we should add
a quirk to override that Interrupt Pin value so we don't bother with
any of the INTx routing stuff.
If INTA doesn't work, advertising it leads to lspci showing misleading
information and pointless searches of _PRT.
> > I'm hoping not, which would probably mean we could just ignore and
> > close bug reports about things like this:
> >
> > pci 0000:00:00.2: can't derive routing for PCI INT A
>
> I hope this is fixed by a recent upstream commit:
>
> commit 0feda94c868d396fac3b3cb14089d2d989a07c72
> Author: Mario Limonciello <mario.limonciello@amd.com>
> Date: Mon Jan 22 17:34:00 2024 -0600
>
> iommu/amd: Mark interrupt as managed
From https://bugzilla.kernel.org/show_bug.cgi?id=212261:
00:00.2 IOMMU: Advanced Micro Devices, Inc. [AMD] Renoir IOMMU
Interrupt: pin A routed to IRQ 25
[ 0.544306] ACPI: PCI Root Bridge [PCI0] (domain 0000 [bus 00-ff])
[ 0.544643] pci 0000:00:00.2: [1022:1631] type 00 class 0x080600
[ 0.567845] pci 0000:00:00.2: AMD-Vi: IOMMU performance counters supported
[ 0.567910] pci 0000:00:00.2: can't derive routing for PCI INT A
[ 0.567912] pci 0000:00:00.2: PCI INT A: not connected
I think 0feda94c868d will make the warnings go away, but I don't think
its commit log is quite right:
According to the PCI spec [1] these routing entries
are only required under PCI root bridges:
The _PRT object is required under all PCI root bridges
The IOMMU is directly connected to the root complex, so there is no
parent bridge to look for a _PRT entry.
We look under the parent *root bridge*, not under a parent Root Port
or PCI-PCI bridge. In this case there should be a _PRT under the PCI0
root bridge, and that's where we look for 00:00.2 INTx information.
I think if a device advertises an INTx pin, the _PRT *should* tell us
how it's routed. If it doesn't, IMHO either the device is defective
(for advertising INTx that it doesn't use) or the firmware is
defective (not telling us via _PRT how it is routed).
Bjorn
parent reply other threads:[~2024-03-25 21:34 UTC|newest]
Thread overview: expand[flat|nested] mbox.gz Atom feed
[parent not found: <ZgEycC1c_d0RTPHW@8bytes.org>]
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=20240325213359.GA1435356@bhelgaas \
--to=helgaas@kernel.org \
--cc=joro@8bytes.org \
--cc=linux-pci@vger.kernel.org \
--cc=mario.limonciello@amd.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