[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <fde11cec-d1bd-49be-f129-c69a973d1b3b@arm.com>
Date: Thu, 8 Jul 2021 11:18:45 +0100
From: Robin Murphy <robin.murphy@....com>
To: Joerg Roedel <joro@...tes.org>,
Kai-Heng Feng <kai.heng.feng@...onical.com>
Cc: will@...nel.org,
"open list:AMD IOMMU (AMD-VI)" <iommu@...ts.linux-foundation.org>,
open list <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH] iommu/amd: Enable swiotlb if any device supports iommu v2
and uses identity mapping
On 2021-07-08 10:28, Joerg Roedel wrote:
> On Thu, Jul 08, 2021 at 03:42:32PM +0800, Kai-Heng Feng wrote:
>> @@ -344,6 +344,9 @@ static int iommu_init_device(struct device *dev)
>>
>> iommu = amd_iommu_rlookup_table[dev_data->devid];
>> dev_data->iommu_v2 = iommu->is_iommu_v2;
>> +
>> + if (dev_data->iommu_v2)
>> + swiotlb = 1;
>
> This looks like the big hammer, as it will affect all other systems
> where the AMD GPUs are in their own group.
>
> What is needed here is an explicit check whether a non-iommu-v2 device
> is direct-mapped because it shares a group with the GPU, and only enable
> swiotlb in this case.
Right, it's basically about whether any DMA-limited device might at any
time end up in an IOMMU_DOMAIN_IDENTITY domain. And given the
possibility of device hotplug and the user being silly with the sysfs
interface, I don't think we can categorically determine that at boot time.
Also note that Intel systems are likely to be similarly affected (in
fact intel-iommu doesn't even have the iommu_default_passthough() check
so it's probably even easier to blow up).
Robin.
Powered by blists - more mailing lists