[Intel-gfx] [PATCH] drm/i915: Use per device iommu check

Lu Baolu baolu.lu at linux.intel.com
Wed Nov 10 07:25:58 UTC 2021


On 2021/11/10 1:35, Tvrtko Ursulin wrote:
> 
> On 09/11/2021 17:19, Lucas De Marchi wrote:
>> On Tue, Nov 09, 2021 at 12:17:59PM +0000, Tvrtko Ursulin wrote:
>>> From: Tvrtko Ursulin <tvrtko.ursulin at intel.com>
>>>
>>> On igfx + dgfx setups, it appears that intel_iommu=igfx_off option only
>>> disables the igfx iommu. Stop relying on global intel_iommu_gfx_mapped
>>> and probe presence of iommu domain per device to accurately reflect its
>>> status.
>>
>> nice, I was just starting to look into thus but for another reason: we
>> are adding support for other archs, like aarch64, and the global from 
>> here
>> was a problem
> 
> Yes I realized the other iommu angle as well. To do this properly we 
> need to sort the intel_vtd_active call sites into at least two buckets - 
> which are truly about VT-d and which are just IOMMU.
> 
> For instance the THP decision in i915_gemfs.co would be "are we behind 
> any iommu". Some other call sites are possibly only about the bugs in 
> the igfx iommu. Not sure if there is a third bucket for any potential 
> differences between igfx iommu and other Intel iommu in case of dgfx.
> 
> I'd like to hear from Baolu as well to confirm if intel_iommu driver is 
> handling igfx + dgfx correctly in respect to the two global variables I 
> mention in the commit message.

I strongly agree that the drivers should call the IOMMU interface
directly for portability. For Intel graphic driver, we have two issues:

#1) driver asks vt-d driver for identity map with intel_iommu=igfx_off.
#2) driver query the status with a global intel_iommu_gfx_mapped.

We need to solve these two problems step by step. This patch is
definitely a good start point.

Best regards,
baolu


More information about the Intel-gfx mailing list