From: Robin Murphy <robin.murphy@arm.com>
To: Kai-Heng Feng <kai.heng.feng@canonical.com>
Cc: "open list:AMD IOMMU \(AMD-VI\)"
<iommu@lists.linux-foundation.org>,
will@kernel.org, open list <linux-kernel@vger.kernel.org>
Subject: Re: [PATCH] iommu/amd: Enable swiotlb if any device supports iommu v2 and uses identity mapping
Date: Thu, 8 Jul 2021 15:43:42 +0100 [thread overview]
Message-ID: <f3bdedcb-5602-cbca-7df1-019e8b8c4217@arm.com> (raw)
In-Reply-To: <CAAd53p40RcG0oeYr9QAKMjYRtyq7he=d_b_a39n4Rt5JSVScRQ@mail.gmail.com>
On 2021-07-08 14:57, Kai-Heng Feng wrote:
> On Thu, Jul 8, 2021 at 6:18 PM Robin Murphy <robin.murphy@arm.com> wrote:
>>
>> 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).
>
> swiotlb is enabled by pci_swiotlb_detect_4gb() and intel-iommu doesn't
> disable it.
Oh, right... I did say I found this dance hard to follow. Clearly I
shouldn't have trusted what I thought I remembered from looking at it
yesterday :)
Also not helped by the fact that it sets iommu_detected which *does*
disable SWIOTLB, but only on IA-64.
> I wonder if we can take the same approach in amd-iommu?
Certainly if there's a precedent for leaving SWIOTLB enabled even if it
*might* be redundant, that seems like the easiest option (it's what we
do on arm64 too, but then we have system topologies where some devices
may not be behind IOMMUs even when others are). More fun would be to try
to bring it up at the first sign of IOMMU_DOMAIN_IDENTITY if it was
disabled previously, but I don't have the highest hope of that being
practical.
Robin.
_______________________________________________
iommu mailing list
iommu@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/iommu
next prev parent reply other threads:[~2021-07-08 14:43 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-07-08 7:42 [PATCH] iommu/amd: Enable swiotlb if any device supports iommu v2 and uses identity mapping Kai-Heng Feng
2021-07-08 9:28 ` Joerg Roedel
2021-07-08 10:18 ` Robin Murphy
2021-07-08 13:57 ` Kai-Heng Feng
2021-07-08 14:43 ` Robin Murphy [this message]
2021-07-13 23:57 ` Konrad Rzeszutek Wilk
2021-07-14 4:59 ` Kai-Heng Feng
2021-07-14 10:25 ` Joerg Roedel
2021-09-09 6:32 ` Kai-Heng Feng
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=f3bdedcb-5602-cbca-7df1-019e8b8c4217@arm.com \
--to=robin.murphy@arm.com \
--cc=iommu@lists.linux-foundation.org \
--cc=kai.heng.feng@canonical.com \
--cc=linux-kernel@vger.kernel.org \
--cc=will@kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).