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] [day] [month] [year] [list]

Message-ID: <1b1acbb7-409f-4263-928d-bb73d6c328ab@linux.intel.com>
Date: Fri, 8 Mar 2024 09:05:43 +0800
From: Baolu Lu <baolu.lu@...ux.intel.com>
To: Robin Murphy <robin.murphy@....com>, Arnd Bergmann <arnd@...nel.org>,
 Joerg Roedel <joro@...tes.org>, Will Deacon <will@...nel.org>
Cc: baolu.lu@...ux.intel.com, Arnd Bergmann <arnd@...db.de>,
 Jason Gunthorpe <jgg@...pe.ca>, Kevin Tian <kevin.tian@...el.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 3/7/24 11:48 PM, Robin Murphy wrote:
> 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.

IOMMU in passthrough mode + interrupt remapping might be a reasonable
alternative to no IOMMU API + interrupt remapping.

Best regards,
baolu