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@xxxxxxx> > 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
