[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 dri-devel
mailing list