linux-kernel - Re: [PATCH] iommu/amd: Mark interrupt as managed

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <de66890b-a42c-4d8b-8079-fcfff0007aeb@amd.com>
Date: Mon, 5 Feb 2024 10:31:47 -0600
From: Mario Limonciello <mario.limonciello@....com>
To: joro@...tes.org, suravee.suthikulpanit@....com, Vasant.Hegde@....com
Cc: will@...nel.org, robin.murphy@....com, iommu@...ts.linux.dev,
 linux-kernel@...r.kernel.org
Subject: Re: [PATCH] iommu/amd: Mark interrupt as managed

On 1/22/2024 17:34, Mario Limonciello wrote:
> On many systems that have an AMD IOMMU the following sequence of
> warnings is observed during bootup.
> 
> ```
> pci 0000:00:00.2  can't derive routing for PCI INT A
> pci 0000:00:00.2: PCI INT A: not connected
> ```
> 
> This series of events happens because of the IOMMU initialization
> sequence order and the lack of _PRT entries for the IOMMU.
> 
> During initialization the IOMMU driver first enables the PCI device
> using pci_enable_device().  This will call acpi_pci_irq_enable()
> which will check if the interrupt is declared in a PCI routing table
> (_PRT) entry. 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. The first warning is emitted
> since no entry could be found in the hierarchy. The second warning is
> then emitted because the interrupt hasn't yet been configured to any
> value.  The pin was configured in pci_read_irq() but the byte in
> PCI_INTERRUPT_LINE return 0xff which means "Unknown".
> 
> After that sequence of events pci_enable_msi() is called and this
> will allocate an interrupt.
> 
> That is both of these warnings are totally harmless because the IOMMU
> uses MSI for interrupts.  To avoid even trying to probe for a _PRT
> entry mark the IOMMU as IRQ managed. This avoids both warnings.
> 
> Link: https://uefi.org/htmlspecs/ACPI_Spec_6_4_html/06_Device_Configuration/Device_Configuration.html?highlight=_prt#prt-pci-routing-table [1]
> Signed-off-by: Mario Limonciello <mario.limonciello@....com>

Hi,

Friendly ping on reviewing this patch.

Thanks,

> ---
>   drivers/iommu/amd/init.c | 3 +++
>   1 file changed, 3 insertions(+)
> 
> diff --git a/drivers/iommu/amd/init.c b/drivers/iommu/amd/init.c
> index c83bd0c2a1c9..40979b0f5250 100644
> --- a/drivers/iommu/amd/init.c
> +++ b/drivers/iommu/amd/init.c
> @@ -2068,6 +2068,9 @@ static int __init iommu_init_pci(struct amd_iommu *iommu)
>   	/* Prevent binding other PCI device drivers to IOMMU devices */
>   	iommu->dev->match_driver = false;
>   
> +	/* ACPI _PRT won't have an IRQ for IOMMU */
> +	iommu->dev->irq_managed = 1;
> +
>   	pci_read_config_dword(iommu->dev, cap_ptr + MMIO_CAP_HDR_OFFSET,
>   			      &iommu->cap);
>   
> 
> base-commit: 75f74f85a42eb294b657f847c33e1bb7921dbec9