From: Jean-Philippe Brucker <jean-philippe@linaro.org>
To: Saravana Kannan <saravanak@google.com>
Cc: Robin Murphy <robin.murphy@arm.com>,
John Garry <john.garry@huawei.com>,
Bjorn Helgaas <bhelgaas@google.com>,
"iommu@lists.linux-foundation.org"
<iommu@lists.linux-foundation.org>, Will Deacon <will@kernel.org>,
LKML <linux-kernel@vger.kernel.org>
Subject: Re: [PATCH 0/7] iommu: Permit modular builds of ARM SMMU[v3] drivers
Date: Thu, 7 Nov 2019 10:13:59 +0100 [thread overview]
Message-ID: <20191107091359.GA3752186@lophozonia> (raw)
In-Reply-To: <CAGETcx8QYBfGOBNtUTR+Lq_g+bmBxMOe0q=3U5UxvVqi+640Xw@mail.gmail.com>
On Wed, Nov 06, 2019 at 10:11:55PM -0800, Saravana Kannan wrote:
> > Right, in short the fundamental problem is that of_iommu_configure() now
> > does the wrong thing. Deferring probe of the entire host bridge/root
> > complex based on "iommu-map" would indeed happen to solve the problem by
> > brute force, I think, but could lead to a dependency cycle for PCI-based
> > IOMMUs as Jean points out.
>
> Sorry for the late reply. Got caught up on other work.
>
> I didn't think the SMMU itself was PCI based in the example Jean gave.
> I thought it just happened to be the case where the SMMU probes after
> the pcieport but before the other children. If the SMMU itself is a
> child of the pcieport, how can it be required for the parent to
> function? How will suspend/resume even work?! I feel like I'm missing
> some context wrt to PCI that everyone else seems to know (which isn't
> surprising).
The Arm SMMU isn't PCI based, it always appears as an independent MMIO
device. John's problem is something different if I understand correctly,
where the probe order between pcieport and endpoint shouldn't affect the
IOMMU grouping, but currently does.
Two other IOMMU models are PCI based, though, AMD IOMMU and virtio-iommu
(which is a purely virtual device). In theory they can have their
programming interface anywhere in the PCI config space, but to ensure
proper software support they should be at the top of the PCI hierarchy.
AMD strongly recommends that the IOMMU is a root-complex device (4.5 -
Software and Platform Firmware Implementation Issues). Within a PCIe
system the IOMMU would have to be a Root Complex integrated Endpoint, not
be a child of a root port.
Thanks,
Jean
next prev parent reply other threads:[~2019-11-07 9:14 UTC|newest]
Thread overview: 43+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-10-30 14:51 [PATCH 0/7] iommu: Permit modular builds of ARM SMMU[v3] drivers Will Deacon
2019-10-30 14:51 ` [PATCH 1/7] drivers/iommu: Export core IOMMU API symbols to permit modular drivers Will Deacon
2019-10-30 14:51 ` [PATCH 2/7] iommu/of: Request ACS from the PCI core when configuring IOMMU linkage Will Deacon
2019-10-30 14:51 ` [PATCH 3/7] PCI: Export pci_ats_disabled() as a GPL symbol to modules Will Deacon
2019-10-30 20:30 ` Bjorn Helgaas
2019-10-30 14:51 ` [PATCH 4/7] Revert "iommu/arm-smmu: Make arm-smmu-v3 explicitly non-modular" Will Deacon
2019-10-30 14:51 ` [PATCH 5/7] iommu/arm-smmu-v3: Allow building as a module Will Deacon
2019-10-30 19:31 ` Joerg Roedel
2019-10-31 15:42 ` Will Deacon
2019-11-04 19:15 ` Jean-Philippe Brucker
2019-11-08 14:54 ` Will Deacon
2019-11-05 12:15 ` Joerg Roedel
2019-11-08 11:03 ` Will Deacon
2019-10-30 14:51 ` [PATCH 6/7] Revert "iommu/arm-smmu: Make arm-smmu explicitly non-modular" Will Deacon
2019-10-30 23:09 ` Jordan Crouse
2019-10-31 12:03 ` Will Deacon
2019-10-31 15:32 ` Jordan Crouse
2019-10-30 14:51 ` [PATCH 7/7] iommu/arm-smmu: Allow building as a module Will Deacon
2019-10-30 15:22 ` Rob Herring
2019-10-30 15:26 ` Will Deacon
2019-10-30 15:33 ` Robin Murphy
2019-11-04 19:34 ` Isaac J. Manjarres
2019-11-07 12:48 ` Will Deacon
2019-10-30 15:35 ` [PATCH 0/7] iommu: Permit modular builds of ARM SMMU[v3] drivers Robin Murphy
2019-10-30 15:54 ` Will Deacon
2019-10-31 0:57 ` Saravana Kannan
2019-10-31 19:37 ` Jean-Philippe Brucker
2019-10-31 23:34 ` Saravana Kannan
2019-11-01 10:27 ` John Garry
2019-11-01 21:13 ` Saravana Kannan
2019-11-04 12:16 ` John Garry
2019-11-04 13:29 ` Robin Murphy
2019-11-07 6:11 ` Saravana Kannan
2019-11-07 9:13 ` Jean-Philippe Brucker [this message]
2019-11-07 6:02 ` Saravana Kannan
2019-11-01 11:41 ` Jean-Philippe Brucker
2019-11-01 12:28 ` Lorenzo Pieralisi
2019-11-01 21:26 ` Saravana Kannan
2019-11-04 11:43 ` Lorenzo Pieralisi
2019-11-07 5:55 ` Saravana Kannan
2019-11-01 17:21 ` Will Deacon
2019-11-04 7:54 ` Jean-Philippe Brucker
2019-11-07 6:16 ` Saravana Kannan
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=20191107091359.GA3752186@lophozonia \
--to=jean-philippe@linaro.org \
--cc=bhelgaas@google.com \
--cc=iommu@lists.linux-foundation.org \
--cc=john.garry@huawei.com \
--cc=linux-kernel@vger.kernel.org \
--cc=robin.murphy@arm.com \
--cc=saravanak@google.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 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).