From: Konrad Rzeszutek Wilk <konrad@darnok.org>
To: Robin Murphy <robin.murphy@arm.com>
Cc: "open list:AMD IOMMU \(AMD-VI\)"
<iommu@lists.linux-foundation.org>,
Kai-Heng Feng <kai.heng.feng@canonical.com>,
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: Tue, 13 Jul 2021 19:57:40 -0400 [thread overview]
Message-ID: <YO4odF0EwqxfNLFq@fedora> (raw)
In-Reply-To: <f3bdedcb-5602-cbca-7df1-019e8b8c4217@arm.com>
On Thu, Jul 08, 2021 at 03:43:42PM +0100, Robin Murphy wrote:
> 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.
<scratches his head>
It is kind of silly to enable SWIOTLB which will just eat 64MB of memory
"just in case".
The SWIOTLB does have support to do late initialization (xen-pcifront
does that for example - so if you add devices that can't do 64-bit it
will allocate something like 4MB).
Would that be a better choice going forward - that is allocate this
under those conditions?
>
> Robin.
_______________________________________________
iommu mailing list
iommu@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/iommu
WARNING: multiple messages have this Message-ID (diff)
From: Konrad Rzeszutek Wilk <konrad@darnok.org>
To: Robin Murphy <robin.murphy@arm.com>
Cc: Kai-Heng Feng <kai.heng.feng@canonical.com>,
will@kernel.org,
"open list:AMD IOMMU (AMD-VI)" <iommu@lists.linux-foundation.org>,
open list <linux-kernel@vger.kernel.org>,
Joerg Roedel <joro@8bytes.org>
Subject: Re: [PATCH] iommu/amd: Enable swiotlb if any device supports iommu v2 and uses identity mapping
Date: Tue, 13 Jul 2021 19:57:40 -0400 [thread overview]
Message-ID: <YO4odF0EwqxfNLFq@fedora> (raw)
In-Reply-To: <f3bdedcb-5602-cbca-7df1-019e8b8c4217@arm.com>
On Thu, Jul 08, 2021 at 03:43:42PM +0100, Robin Murphy wrote:
> 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.
<scratches his head>
It is kind of silly to enable SWIOTLB which will just eat 64MB of memory
"just in case".
The SWIOTLB does have support to do late initialization (xen-pcifront
does that for example - so if you add devices that can't do 64-bit it
will allocate something like 4MB).
Would that be a better choice going forward - that is allocate this
under those conditions?
>
> Robin.
next prev parent reply other threads:[~2021-07-13 23:57 UTC|newest]
Thread overview: 18+ 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 7:42 ` Kai-Heng Feng
2021-07-08 9:28 ` Joerg Roedel
2021-07-08 9:28 ` Joerg Roedel
2021-07-08 10:18 ` Robin Murphy
2021-07-08 10:18 ` Robin Murphy
2021-07-08 13:57 ` Kai-Heng Feng
2021-07-08 13:57 ` Kai-Heng Feng
2021-07-08 14:43 ` Robin Murphy
2021-07-08 14:43 ` Robin Murphy
2021-07-13 23:57 ` Konrad Rzeszutek Wilk [this message]
2021-07-13 23:57 ` Konrad Rzeszutek Wilk
2021-07-14 4:59 ` Kai-Heng Feng
2021-07-14 4:59 ` Kai-Heng Feng
2021-07-14 10:25 ` Joerg Roedel
2021-07-14 10:25 ` Joerg Roedel
2021-09-09 6:32 ` Kai-Heng Feng
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=YO4odF0EwqxfNLFq@fedora \
--to=konrad@darnok.org \
--cc=iommu@lists.linux-foundation.org \
--cc=kai.heng.feng@canonical.com \
--cc=linux-kernel@vger.kernel.org \
--cc=robin.murphy@arm.com \
--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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.