LKML Archive on lore.kernel.org
help / color / mirror / Atom feed
From: Robin Murphy <robin.murphy@arm.com>
To: "chenxiang (M)" <chenxiang66@hisilicon.com>,
	joro@8bytes.org, will@kernel.org
Cc: Maxime Ripard <mripard@kernel.org>,
	Jean-Philippe Brucker <jean-philippe@linaro.org>,
	Heiko Stuebner <heiko@sntech.de>,
	Geert Uytterhoeven <geert+renesas@glider.be>,
	linux-kernel@vger.kernel.org,
	Chunyan Zhang <chunyan.zhang@unisoc.com>,
	dianders@chromium.org, iommu@lists.linux-foundation.org,
	linux-arm-kernel@lists.infradead.org,
	"linuxarm@huawei.com" <linuxarm@huawei.com>
Subject: Re: [PATCH v2 00/24] iommu: Refactor DMA domain strictness
Date: Thu, 29 Jul 2021 11:59:01 +0100	[thread overview]
Message-ID: <942c3da1-fb79-967a-d50e-4cbf5331261c@arm.com> (raw)
In-Reply-To: <49c7ca2c-11a3-ff93-05bc-feb482a79980@hisilicon.com>

On 2021-07-29 03:55, chenxiang (M) wrote:
> Hi Robin,
> 
> 
> 在 2021/7/28 23:58, Robin Murphy 写道:
>> Hi all,
>>
>> Here's v2 where things start to look more realistic, hence the expanded
>> CC list. The patches are now based on the current iommu/core branch to
>> take John's iommu_set_dma_strict() cleanup into account.
>>
>> The series remiains in two (or possibly 3) logical parts - for people
>> CC'd on cookie cleanup patches, the later parts should not affect you
>> since your drivers don't implement non-strict mode anyway; the cleanup
>> is all pretty straightforward, but please do yell at me if I've managed
>> to let a silly mistake slip through and broken your driver.
>>
>> This time I have also build-tested x86 as well as arm64 :)
> 
> I have tested those patchset on ARM64 with SMMUV3, and the testcases are 
> as follows:
> - Boot with iommu.strict=0, running fio and it works well;
> - Boot with iommu.strict=1, running fio and it works well;
> - Change strict mode to lazy mode when building, the change takes effect;
> - Boot without iommu.strict(default strict mode), change the sysfs 
> interface type from DMA to DMA-FQ dynamically during running fio, and it 
> works well;
> - Boot without iommu.strict(default strict mode), change the sysfs 
> interface type from DMA-FQ to DMA dynamically, and it is not allowed and 
> print "Device or resource busy"
> (i know it is qualified, and we can change no-strict mode to strict by 
> unbind the driver -> change the sysfs interface (type)->bind the driver 
> (tested this and it works well),
> but i have a small question: is it also possible to change from DMA-FQ 
> to DMA dynamically? )

As patch #22 mentions, I think it's possible in principle, but it's 
certainly trickier. When enabling a flush queue, it doesn't matter if it 
takes a while for other threads to notice that cookie->fq_domain is now 
set and stop doing synchronous invalidations (and in the SMMU case it 
seems like there are probably enough dependencies to additionally 
prevent the io_pgtable quirk being observable before that). However when 
disabling, we'd need to be absolutely sure that the driver *has* started 
invalidating strictly before we stop queueing freed IOVAs, plus we need 
to be absolutely sure that we've stopped queueing freed IOVAs before we 
attempt to tear down the flush queue itself. I'm not sure off-hand how 
feasible it would be to put all that synchronisation in the right places 
without it also impacting normal operation.

Furthermore, as also noted, there doesn't seem to be a good reason for 
ever actually needing to do that. If a device isn't trusted, it should 
be given a strict domain *before* any driver has a chance to start doing 
anything, or your trust model is broken and pretty useless. I can 
imagine some niche debugging/benchmarking cases where it might help save 
a bit of effort, but nothing with a strong enough justification to be 
worth supporting in mainline.

> Anyway, please feel free to add :
> Tested-by: Xiang Chen <chenxiang66@hisilicon.com>

That's great, thanks!

Robin.

>> Changes in v2:
>>
>> - Add iommu_is_dma_domain() helper to abstract flag check (and help
>>    avoid silly typos like the one in v1).
>> - Tweak a few commit messages for spelling and (hopefully) clarity.
>> - Move the iommu_create_device_direct_mappings() update to patch #14
>>    where it should have been.
>> - Rewrite patch #20 as a conversion of the now-existing option.
>> - Clean up the ops->flush_iotlb_all check which is also made redundant
>>    by the new domain type
>> - Add patch #24, which is arguably tangential, but it was something I
>>    spotted during the rebase, so...
>>
>> Once again, the whole lot is available on a branch here:
>>
>> https://gitlab.arm.com/linux-arm/linux-rm/-/tree/iommu/fq
>>
>> Thanks,
>> Robin.
>>
>>
>> CC: Marek Szyprowski <m.szyprowski@samsung.com>
>> CC: Yoshihiro Shimoda <yoshihiro.shimoda.uh@renesas.com>
>> CC: Geert Uytterhoeven <geert+renesas@glider.be>
>> CC: Yong Wu <yong.wu@mediatek.com>
>> CC: Heiko Stuebner <heiko@sntech.de>
>> CC: Chunyan Zhang <chunyan.zhang@unisoc.com>
>> CC: Chunyan Zhang <chunyan.zhang@unisoc.com>
>> CC: Maxime Ripard <mripard@kernel.org>
>> CC: Jean-Philippe Brucker <jean-philippe@linaro.org>
>>
>> Robin Murphy (24):
>>    iommu: Pull IOVA cookie management into the core
>>    iommu/amd: Drop IOVA cookie management
>>    iommu/arm-smmu: Drop IOVA cookie management
>>    iommu/vt-d: Drop IOVA cookie management
>>    iommu/exynos: Drop IOVA cookie management
>>    iommu/ipmmu-vmsa: Drop IOVA cookie management
>>    iommu/mtk: Drop IOVA cookie management
>>    iommu/rockchip: Drop IOVA cookie management
>>    iommu/sprd: Drop IOVA cookie management
>>    iommu/sun50i: Drop IOVA cookie management
>>    iommu/virtio: Drop IOVA cookie management
>>    iommu/dma: Unexport IOVA cookie management
>>    iommu/dma: Remove redundant "!dev" checks
>>    iommu: Introduce explicit type for non-strict DMA domains
>>    iommu/amd: Prepare for multiple DMA domain types
>>    iommu/arm-smmu: Prepare for multiple DMA domain types
>>    iommu/vt-d: Prepare for multiple DMA domain types
>>    iommu: Express DMA strictness via the domain type
>>    iommu: Expose DMA domain strictness via sysfs
>>    iommu: Merge strictness and domain type configs
>>    iommu/dma: Factor out flush queue init
>>    iommu: Allow enabling non-strict mode dynamically
>>    iommu/arm-smmu: Allow non-strict in pgtable_quirks interface
>>    iommu: Only log strictness for DMA domains
>>
>>   .../ABI/testing/sysfs-kernel-iommu_groups     |  2 +
>>   drivers/iommu/Kconfig                         | 80 +++++++++----------
>>   drivers/iommu/amd/iommu.c                     | 21 +----
>>   drivers/iommu/arm/arm-smmu-v3/arm-smmu-v3.c   | 25 ++++--
>>   drivers/iommu/arm/arm-smmu/arm-smmu.c         | 29 ++++---
>>   drivers/iommu/arm/arm-smmu/qcom_iommu.c       |  8 --
>>   drivers/iommu/dma-iommu.c                     | 44 +++++-----
>>   drivers/iommu/exynos-iommu.c                  | 18 +----
>>   drivers/iommu/intel/iommu.c                   | 23 ++----
>>   drivers/iommu/iommu.c                         | 53 +++++++-----
>>   drivers/iommu/ipmmu-vmsa.c                    | 27 +------
>>   drivers/iommu/mtk_iommu.c                     |  6 --
>>   drivers/iommu/rockchip-iommu.c                | 11 +--
>>   drivers/iommu/sprd-iommu.c                    |  6 --
>>   drivers/iommu/sun50i-iommu.c                  | 12 +--
>>   drivers/iommu/virtio-iommu.c                  |  8 --
>>   include/linux/dma-iommu.h                     |  9 ++-
>>   include/linux/iommu.h                         | 15 +++-
>>   18 files changed, 171 insertions(+), 226 deletions(-)
>>
> 
> 

  reply	other threads:[~2021-07-29 10:59 UTC|newest]

Thread overview: 65+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-07-28 15:58 Robin Murphy
2021-07-28 15:58 ` [PATCH v2 01/24] iommu: Pull IOVA cookie management into the core Robin Murphy
2021-07-30  6:06   ` Lu Baolu
2021-07-30  9:32   ` Jean-Philippe Brucker
2021-07-28 15:58 ` [PATCH v2 02/24] iommu/amd: Drop IOVA cookie management Robin Murphy
2021-07-28 15:58 ` [PATCH v2 03/24] iommu/arm-smmu: " Robin Murphy
2021-07-28 15:58 ` [PATCH v2 04/24] iommu/vt-d: " Robin Murphy
2021-07-30  6:07   ` Lu Baolu
2021-07-28 15:58 ` [PATCH v2 05/24] iommu/exynos: " Robin Murphy
2021-07-28 15:58 ` [PATCH v2 06/24] iommu/ipmmu-vmsa: " Robin Murphy
2021-07-28 15:58 ` [PATCH v2 07/24] iommu/mtk: " Robin Murphy
2021-07-28 15:58 ` [PATCH v2 08/24] iommu/rockchip: " Robin Murphy
2021-07-28 15:58 ` [PATCH v2 09/24] iommu/sprd: " Robin Murphy
2021-07-28 15:58 ` [PATCH v2 10/24] iommu/sun50i: " Robin Murphy
2021-07-28 15:58 ` [PATCH v2 11/24] iommu/virtio: " Robin Murphy
2021-07-30  9:20   ` Jean-Philippe Brucker
2021-07-28 15:58 ` [PATCH v2 12/24] iommu/dma: Unexport " Robin Murphy
2021-07-30  6:07   ` Lu Baolu
2021-07-30  9:21   ` Jean-Philippe Brucker
2021-07-28 15:58 ` [PATCH v2 13/24] iommu/dma: Remove redundant "!dev" checks Robin Murphy
2021-07-30  6:08   ` Lu Baolu
2021-07-28 15:58 ` [PATCH v2 14/24] iommu: Introduce explicit type for non-strict DMA domains Robin Murphy
2021-07-30  6:08   ` Lu Baolu
2021-07-30  9:23   ` Jean-Philippe Brucker
2021-07-28 15:58 ` [PATCH v2 15/24] iommu/amd: Prepare for multiple DMA domain types Robin Murphy
2021-07-28 15:58 ` [PATCH v2 16/24] iommu/arm-smmu: " Robin Murphy
2021-07-28 15:58 ` [PATCH v2 17/24] iommu/vt-d: " Robin Murphy
2021-07-30  6:09   ` Lu Baolu
2021-07-28 15:58 ` [PATCH v2 18/24] iommu: Express DMA strictness via the domain type Robin Murphy
2021-07-29  7:13   ` Lu Baolu
2021-07-29  9:36     ` Robin Murphy
2021-07-29 12:42       ` Lu Baolu
2021-07-30  6:09       ` Lu Baolu
2021-07-28 15:58 ` [PATCH v2 19/24] iommu: Expose DMA domain strictness via sysfs Robin Murphy
2021-07-30  6:10   ` Lu Baolu
2021-07-30  9:28   ` Jean-Philippe Brucker
2021-07-30 10:20   ` John Garry
2021-07-28 15:58 ` [PATCH v2 20/24] iommu: Merge strictness and domain type configs Robin Murphy
2021-07-30  6:10   ` Lu Baolu
2021-07-30  9:29   ` Jean-Philippe Brucker
2021-07-30  9:33   ` John Garry
2021-07-28 15:58 ` [PATCH v2 21/24] iommu/dma: Factor out flush queue init Robin Murphy
2021-07-30  6:11   ` Lu Baolu
2021-07-30  9:20   ` John Garry
2021-07-28 15:58 ` [PATCH v2 22/24] iommu: Allow enabling non-strict mode dynamically Robin Murphy
2021-07-30  6:11   ` Lu Baolu
2021-07-30  9:24   ` John Garry
2021-07-28 15:58 ` [PATCH v2 23/24] iommu/arm-smmu: Allow non-strict in pgtable_quirks interface Robin Murphy
2021-08-02 13:04   ` Will Deacon
2021-08-02 14:15     ` Robin Murphy
2021-08-03 10:36       ` Will Deacon
2021-08-03 12:13         ` Robin Murphy
2021-08-03 12:35           ` Will Deacon
2021-07-28 15:58 ` [PATCH v2 24/24] iommu: Only log strictness for DMA domains Robin Murphy
2021-07-29  9:04   ` John Garry
2021-07-30  6:12   ` Lu Baolu
2021-07-29  2:55 ` [PATCH v2 00/24] iommu: Refactor DMA domain strictness chenxiang (M)
2021-07-29 10:59   ` Robin Murphy [this message]
2021-07-30  1:21     ` chenxiang (M)
2021-07-29 15:04 ` Heiko Stübner
2021-07-29 15:43   ` Robin Murphy
2021-07-29 15:53     ` Heiko Stübner
2021-07-29 16:29       ` Robin Murphy
2021-07-29 22:33 ` Doug Anderson
2021-07-30  0:06   ` Doug Anderson

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=942c3da1-fb79-967a-d50e-4cbf5331261c@arm.com \
    --to=robin.murphy@arm.com \
    --cc=chenxiang66@hisilicon.com \
    --cc=chunyan.zhang@unisoc.com \
    --cc=dianders@chromium.org \
    --cc=geert+renesas@glider.be \
    --cc=heiko@sntech.de \
    --cc=iommu@lists.linux-foundation.org \
    --cc=jean-philippe@linaro.org \
    --cc=joro@8bytes.org \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linuxarm@huawei.com \
    --cc=mripard@kernel.org \
    --cc=will@kernel.org \
    --subject='Re: [PATCH v2 00/24] iommu: Refactor DMA domain strictness' \
    /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

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