Re: [PATCH] iommu: always select INTEL_IOMMU for IRQ_REMAP

[Baolu Lu]

On 3/7/24 11:48 PM, Robin Murphy wrote:
> On 07/03/2024 2:05 pm, Arnd Bergmann wrote:
> > From: Arnd Bergmann <arnd@xxxxxxxx>
> >
> > 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