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]

Date: Mon, 12 Feb 2024 16:54:31 +0530
From: Vasant Hegde <vasant.hegde@....com>
To: Mario Limonciello <mario.limonciello@....com>, joro@...tes.org,
 suravee.suthikulpanit@....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/23/2024 5:04 AM, 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>

Patch looks good to me.

Reviewed-by: Vasant Hegde <vasant.hegde@....com>

-Vasant

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