All of lore.kernel.org
 help / color / mirror / Atom feed
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

  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: 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.