From: Dmitry Osipenko <digetx@gmail.com> To: Robin Murphy <robin.murphy@arm.com>, Thierry Reding <thierry.reding@gmail.com> Cc: Joerg Roedel <joro@8bytes.org>, Rob Herring <robh+dt@kernel.org>, Frank Rowand <frowand.list@gmail.com>, Will Deacon <will@kernel.org>, iommu@lists.linux-foundation.org, devicetree@vger.kernel.org, linux-kernel@vger.kernel.org, "linux-tegra@vger.kernel.org" <linux-tegra@vger.kernel.org> Subject: Re: [PATCH v2 1/4] dt-bindings: reserved-memory: Document "active" property Date: Fri, 25 Sep 2020 16:52:50 +0300 [thread overview] Message-ID: <4f35bf17-a354-6ffb-fd4a-063027d83ccc@gmail.com> (raw) In-Reply-To: <484b9e90-7395-6161-577c-4d3f3716997e@arm.com> 25.09.2020 15:39, Robin Murphy пишет: ... >> Yes, my understanding that this is what Robin suggested here: >> >> https://lore.kernel.org/linux-iommu/cb12808b-7316-19db-7413-b7f852a6f8ae@arm.com/ >> > > Just to clarify, what I was talking about there is largely orthogonal to > the issue here. That was about systems with limited translation > resources letting translation be specifically opt-in by IOMMU-aware > drivers. It probably *would* happen to obviate the issue of disrupting > live DMA at boot time on these particular Tegra platforms, but we still > need something like Thierry's solution in general, since IOMMU drivers > may have no other way to determine whether devices are active at boot > and they have to take care to avoid breaking anything - e.g. SMMUv3 will > at a bare minimum need to set up *some* form of valid stream table entry > for the relevant device(s) right at the beginning where we first probe > and reset the SMMU itself, regardless of what happens with domains and > addresses later down the line. Yes, I only meant that yours suggestion also should be useful here. Anyways, thank you for the clarification :) I agree that the Thierry's proposal is good! But it needs some more thought yet because it's not very applicable to the current devices. >>> The primary goal here is to move towards using the DMA API rather than >>> the IOMMU API directly, so we don't really have the option of replacing >>> with an explicitly created domain. Unless we have code in the DMA/IOMMU >>> code that does this somehow. >>> >>> But I'm not sure what would be a good way to mark certain devices as >>> needing an identity domain by default. Do we still use the reserved- >>> memory node for that? >> >> The reserved-memory indeed shouldn't be needed for resolving the >> implicit IOMMU problem since we could mark certain devices within the >> kernel IOMMU driver. >> >> I haven't got around to trying to implement the implicit IOMMU support >> yet, but I suppose we could implement the def_domain_type() hook in the >> SMMU driver and then return IOMMU_DOMAIN_IDENTITY for the Display/VDE >> devices. Then the Display/VDE drivers will take over the identity domain >> and replace it with the explicit domain. > > FWIW I've already cooked up identity domain support for tegra-gart; I > was planning on tackling it for tegra-smmu as well for the next version > of my arm default domains series (which will be after the next -rc1 now > since I'm just about to take some long-overdue holiday). Very nice! Maybe we will have some more food for the discussion by the time you'll return. Have a good time!
WARNING: multiple messages have this Message-ID (diff)
From: Dmitry Osipenko <digetx@gmail.com> To: Robin Murphy <robin.murphy@arm.com>, Thierry Reding <thierry.reding@gmail.com> Cc: devicetree@vger.kernel.org, Frank Rowand <frowand.list@gmail.com>, linux-kernel@vger.kernel.org, iommu@lists.linux-foundation.org, Rob Herring <robh+dt@kernel.org>, "linux-tegra@vger.kernel.org" <linux-tegra@vger.kernel.org>, Will Deacon <will@kernel.org> Subject: Re: [PATCH v2 1/4] dt-bindings: reserved-memory: Document "active" property Date: Fri, 25 Sep 2020 16:52:50 +0300 [thread overview] Message-ID: <4f35bf17-a354-6ffb-fd4a-063027d83ccc@gmail.com> (raw) In-Reply-To: <484b9e90-7395-6161-577c-4d3f3716997e@arm.com> 25.09.2020 15:39, Robin Murphy пишет: ... >> Yes, my understanding that this is what Robin suggested here: >> >> https://lore.kernel.org/linux-iommu/cb12808b-7316-19db-7413-b7f852a6f8ae@arm.com/ >> > > Just to clarify, what I was talking about there is largely orthogonal to > the issue here. That was about systems with limited translation > resources letting translation be specifically opt-in by IOMMU-aware > drivers. It probably *would* happen to obviate the issue of disrupting > live DMA at boot time on these particular Tegra platforms, but we still > need something like Thierry's solution in general, since IOMMU drivers > may have no other way to determine whether devices are active at boot > and they have to take care to avoid breaking anything - e.g. SMMUv3 will > at a bare minimum need to set up *some* form of valid stream table entry > for the relevant device(s) right at the beginning where we first probe > and reset the SMMU itself, regardless of what happens with domains and > addresses later down the line. Yes, I only meant that yours suggestion also should be useful here. Anyways, thank you for the clarification :) I agree that the Thierry's proposal is good! But it needs some more thought yet because it's not very applicable to the current devices. >>> The primary goal here is to move towards using the DMA API rather than >>> the IOMMU API directly, so we don't really have the option of replacing >>> with an explicitly created domain. Unless we have code in the DMA/IOMMU >>> code that does this somehow. >>> >>> But I'm not sure what would be a good way to mark certain devices as >>> needing an identity domain by default. Do we still use the reserved- >>> memory node for that? >> >> The reserved-memory indeed shouldn't be needed for resolving the >> implicit IOMMU problem since we could mark certain devices within the >> kernel IOMMU driver. >> >> I haven't got around to trying to implement the implicit IOMMU support >> yet, but I suppose we could implement the def_domain_type() hook in the >> SMMU driver and then return IOMMU_DOMAIN_IDENTITY for the Display/VDE >> devices. Then the Display/VDE drivers will take over the identity domain >> and replace it with the explicit domain. > > FWIW I've already cooked up identity domain support for tegra-gart; I > was planning on tackling it for tegra-smmu as well for the next version > of my arm default domains series (which will be after the next -rc1 now > since I'm just about to take some long-overdue holiday). Very nice! Maybe we will have some more food for the discussion by the time you'll return. Have a good time! _______________________________________________ iommu mailing list iommu@lists.linux-foundation.org https://lists.linuxfoundation.org/mailman/listinfo/iommu
next prev parent reply other threads:[~2020-09-25 13:52 UTC|newest] Thread overview: 48+ messages / expand[flat|nested] mbox.gz Atom feed top 2020-09-04 12:59 [PATCH v2 1/4] dt-bindings: reserved-memory: Document "active" property Thierry Reding 2020-09-04 12:59 ` Thierry Reding 2020-09-04 12:59 ` [PATCH v2 2/4] iommu: Implement of_iommu_get_resv_regions() Thierry Reding 2020-09-04 12:59 ` Thierry Reding 2020-09-04 12:59 ` [PATCH v2 3/4] iommu: dma: Use of_iommu_get_resv_regions() Thierry Reding 2020-09-04 12:59 ` Thierry Reding 2020-09-04 13:00 ` [RFC 4/4] iommu/tegra-smmu: Add support for reserved regions Thierry Reding 2020-09-04 13:00 ` Thierry Reding 2020-09-14 22:08 ` [PATCH v2 1/4] dt-bindings: reserved-memory: Document "active" property Rob Herring 2020-09-14 22:08 ` Rob Herring 2020-09-15 12:36 ` Thierry Reding 2020-09-15 12:36 ` Thierry Reding 2020-09-24 11:27 ` Thierry Reding 2020-09-24 11:27 ` Thierry Reding 2020-11-05 16:43 ` Thierry Reding 2020-11-05 16:43 ` Thierry Reding 2020-11-05 17:47 ` Robin Murphy 2020-11-05 17:47 ` Robin Murphy 2020-11-06 15:25 ` Thierry Reding 2020-11-06 15:25 ` Thierry Reding 2020-11-10 19:33 ` Thierry Reding 2020-11-10 19:33 ` Thierry Reding 2020-12-17 15:00 ` Thierry Reding 2020-12-17 15:00 ` Thierry Reding 2020-12-18 22:15 ` Rob Herring 2020-12-18 22:15 ` Rob Herring 2020-12-19 0:49 ` Thierry Reding 2020-12-19 0:49 ` Thierry Reding 2020-09-24 13:23 ` Dmitry Osipenko 2020-09-24 13:23 ` Dmitry Osipenko 2020-09-24 14:01 ` Thierry Reding 2020-09-24 14:01 ` Thierry Reding 2020-09-24 16:23 ` Dmitry Osipenko 2020-09-24 16:23 ` Dmitry Osipenko 2020-09-25 12:39 ` Robin Murphy 2020-09-25 12:39 ` Robin Murphy 2020-09-25 13:21 ` Dmitry Osipenko 2020-09-25 13:21 ` Dmitry Osipenko 2020-11-05 16:23 ` Thierry Reding 2020-11-05 16:23 ` Thierry Reding 2020-09-25 13:52 ` Dmitry Osipenko [this message] 2020-09-25 13:52 ` Dmitry Osipenko 2020-11-05 15:57 ` Thierry Reding 2020-11-05 15:57 ` Thierry Reding 2020-11-05 15:49 ` Thierry Reding 2020-11-05 15:49 ` Thierry Reding 2021-01-12 19:00 ` Dmitry Osipenko 2021-01-12 19:00 ` Dmitry Osipenko
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=4f35bf17-a354-6ffb-fd4a-063027d83ccc@gmail.com \ --to=digetx@gmail.com \ --cc=devicetree@vger.kernel.org \ --cc=frowand.list@gmail.com \ --cc=iommu@lists.linux-foundation.org \ --cc=joro@8bytes.org \ --cc=linux-kernel@vger.kernel.org \ --cc=linux-tegra@vger.kernel.org \ --cc=robh+dt@kernel.org \ --cc=robin.murphy@arm.com \ --cc=thierry.reding@gmail.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: linkBe 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.