linux-kernel - Re: [PATCH] iommu: always select INTEL_IOMMU for IRQ

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: <95554e96-d8b9-4325-aa73-e698b1873a79@arm.com>
Date: Thu, 7 Mar 2024 15:48:31 +0000
From: Robin Murphy <robin.murphy@....com>
To: Arnd Bergmann <arnd@...nel.org>, Joerg Roedel <joro@...tes.org>,
 Will Deacon <will@...nel.org>
Cc: Arnd Bergmann <arnd@...db.de>, Jason Gunthorpe <jgg@...pe.ca>,
 Kevin Tian <kevin.tian@...el.com>, Lu Baolu <baolu.lu@...ux.intel.com>,
 Ard Biesheuvel <ardb@...nel.org>, Ingo Molnar <mingo@...e.hu>,
 Suresh Siddha <suresh.b.siddha@...el.com>,
 Dan Carpenter <dan.carpenter@...aro.org>,
 Ethan Zhao <haifeng.zhao@...ux.intel.com>, iommu@...ts.linux.dev,
 linux-kernel@...r.kernel.org
Subject: Re: [PATCH] iommu: always select INTEL_IOMMU for IRQ_REMAP

On 07/03/2024 2:05 pm, Arnd Bergmann wrote:
> From: Arnd Bergmann <arnd@...db.de>
> 
> CONFIG_INTR_REMAP was originally split out of the intel iommu code to be
> shared by IRQ_REMAP. This recently broke again because the IRQ_REMAP
> code calls the global device_rbtree_find() function that is unavailable
> for builds without INTEL_IOMMU:
> 
> x86_64-linux-ld: vmlinux.o: in function `qi_submit_sync':
> (.text+0x10771e0): undefined reference to `device_rbtree_find'
> 
> It seems that the intel iommu code now contains a lot of generic helper
> functions that are not specific to intel, such as alloc_pgtable_page(),
> iommu_flush_write_buffer(), domain_attach_iommu() etc, so presumably
> it is not x86 specific any more.

No, it's still all very much Intel-specific, which in fact means it is 
just recently now x86-specific since IA-64 has departed.

Historically it's always been the case that building IRQ remapping 
support on its own without IOMMU_API was supported, and for a while we 
even had the awkward iommu_device_set_ops() wrapper and various other 
indirections and stubs in the core API solely to make it work. IMO the 
underlying issue here is that there have never been very clear lines of 
separation between the ACPI DMAR code, the IOMMU API driver, and the IRQ 
remapping driver, so unless the whole design could be improved to make 
it harder to break, it probably is time to start asking the question of 
whether anyone actually cares about this config combination any more.

Thanks,
Robin.

> Fix the build failure for now by just selectin INTEL_IOMMU by the
> code that relies on it. It might be helpful to split out all the
> functions without an intel_iommu_* prefix into a helper library
> to avoid including the x86 specific bits on non-x86, but that could
> be a follow-up.
> 
> Fixes: d3f138106b4b ("iommu: Rename the DMAR and INTR_REMAP config options")
> Fixes: 80a9b50c0b9e ("iommu/vt-d: Improve ITE fault handling if target device isn't present")
> Signed-off-by: Arnd Bergmann <arnd@...db.de>
> ---
> Not sure about this one, I just ran across the build regression and
> wasn't sure if the intel-iommu functions are meant to be generic
> or just misnamed. The patch description assumes the former, if that
> is wrong, it needs a different explanation or a different fix.
> ---
>   drivers/iommu/Kconfig | 1 +
>   1 file changed, 1 insertion(+)
> 
> diff --git a/drivers/iommu/Kconfig b/drivers/iommu/Kconfig
> index df156f0a1a17..da5339bdb7e7 100644
> --- a/drivers/iommu/Kconfig
> +++ b/drivers/iommu/Kconfig
> @@ -196,6 +196,7 @@ config IRQ_REMAP
>   	bool "Support for Interrupt Remapping"
>   	depends on X86_64 && X86_IO_APIC && PCI_MSI && ACPI
>   	select DMAR_TABLE
> +	select INTEL_IOMMU
>   	help
>   	  Supports Interrupt remapping for IO-APIC and MSI devices.
>   	  To use x2apic mode in the CPU's which support x2APIC enhancements or