Received-SPF: pass (google.com: domain of linux-kernel+bounces-96419-linux.lists.archive=gmail.com@vger.kernel.org designates 2604:1380:45e3:2400::1 as permitted sender) client-ip=2604:1380:45e3:2400::1;
Message-ID: <1b1acbb7-409f-4263-928d-bb73d6c328ab@linux.intel.com>
Date: Fri, 8 Mar 2024 09:05:43 +0800
Precedence: bulk
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Cc: baolu.lu@linux.intel.com, Arnd Bergmann <arnd@arndb.de>,
 Jason Gunthorpe <jgg@ziepe.ca>, Kevin Tian <kevin.tian@intel.com>,
 Ard Biesheuvel <ardb@kernel.org>, Ingo Molnar <mingo@elte.hu>,
 Suresh Siddha <suresh.b.siddha@intel.com>,
 Dan Carpenter <dan.carpenter@linaro.org>,
 Ethan Zhao <haifeng.zhao@linux.intel.com>, iommu@lists.linux.dev,
 linux-kernel@vger.kernel.org
Subject: Re: [PATCH] iommu: always select INTEL_IOMMU for IRQ_REMAP
Content-Language: en-US
To: Robin Murphy <robin.murphy@arm.com>, Arnd Bergmann <arnd@kernel.org>,
 Joerg Roedel <joro@8bytes.org>, Will Deacon <will@kernel.org>
References: <20240307140547.2201713-1-arnd@kernel.org>
 <95554e96-d8b9-4325-aa73-e698b1873a79@arm.com>
From: Baolu Lu <baolu.lu@linux.intel.com>
In-Reply-To: <95554e96-d8b9-4325-aa73-e698b1873a79@arm.com>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit

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