From: Will Deacon <will.deacon@arm.com>
To: Robin Murphy <robin.murphy@arm.com>
Cc: joro@8bytes.org, thunder.leizhen@huawei.com,
iommu@lists.linux-foundation.org,
linux-arm-kernel@lists.infradead.org,
linux-kernel@vger.kernel.org, linuxarm@huawei.com,
guohanjun@huawei.com, huawei.libin@huawei.com,
john.garry@huawei.com
Subject: Re: [PATCH v7 4/6] iommu: Add bootup option "iommu.non_strict"
Date: Tue, 18 Sep 2018 18:10:13 +0100 [thread overview]
Message-ID: <20180918171013.GK16498@arm.com> (raw)
In-Reply-To: <41f81c46348db4acd9a542184f10e7ca24f6c219.1536935328.git.robin.murphy@arm.com>
On Fri, Sep 14, 2018 at 03:30:22PM +0100, Robin Murphy wrote:
> From: Zhen Lei <thunder.leizhen@huawei.com>
>
> Add a bootup option to make the system manager can choose which mode to
> be used. The default mode is strict.
>
> Signed-off-by: Zhen Lei <thunder.leizhen@huawei.com>
> [rm: move handling out of SMMUv3 driver]
> Signed-off-by: Robin Murphy <robin.murphy@arm.com>
> ---
> .../admin-guide/kernel-parameters.txt | 13 ++++++++++
> drivers/iommu/iommu.c | 26 +++++++++++++++++++
> 2 files changed, 39 insertions(+)
>
> diff --git a/Documentation/admin-guide/kernel-parameters.txt b/Documentation/admin-guide/kernel-parameters.txt
> index 9871e649ffef..406b91759b62 100644
> --- a/Documentation/admin-guide/kernel-parameters.txt
> +++ b/Documentation/admin-guide/kernel-parameters.txt
> @@ -1749,6 +1749,19 @@
> nobypass [PPC/POWERNV]
> Disable IOMMU bypass, using IOMMU for PCI devices.
>
> + iommu.non_strict= [ARM64]
> + Format: { "0" | "1" }
> + 0 - strict mode, default.
> + Release IOVAs after the related TLBs are invalid
> + completely.
> + 1 - non-strict mode.
> + Put off TLBs invalidation and release memory first.
> + It's good for scatter-gather performance but lacks
> + full isolation, an untrusted device can access the
> + reused memory because the TLBs may still valid.
> + Please take full consideration before choosing this
> + mode. Note that, VFIO will always use strict mode.
This text needs help. How about something like:
0 - strict mode, default.
Invalidate the TLB of the IOMMU hardware as part of every
unmap() operation.
1 - lazy mode.
Defer TLB invalidation so that the TLB of the IOMMU hardware
is invalidated periodically, rather than as part of every
unmap() operation.
(generally, I think I'd s/non strict/lazy/ in this patch to avoid the double
negatives)
> +
> iommu.passthrough=
> [ARM64] Configure DMA to bypass the IOMMU by default.
> Format: { "0" | "1" }
> diff --git a/drivers/iommu/iommu.c b/drivers/iommu/iommu.c
> index 8c15c5980299..2cabd0c0a4f3 100644
> --- a/drivers/iommu/iommu.c
> +++ b/drivers/iommu/iommu.c
> @@ -41,6 +41,7 @@ static unsigned int iommu_def_domain_type = IOMMU_DOMAIN_IDENTITY;
> #else
> static unsigned int iommu_def_domain_type = IOMMU_DOMAIN_DMA;
> #endif
> +static bool iommu_dma_non_strict __read_mostly;
>
> struct iommu_callback_data {
> const struct iommu_ops *ops;
> @@ -131,6 +132,24 @@ static int __init iommu_set_def_domain_type(char *str)
> }
> early_param("iommu.passthrough", iommu_set_def_domain_type);
>
> +static int __init iommu_dma_setup(char *str)
> +{
> + int ret;
> +
> + ret = kstrtobool(str, &iommu_dma_non_strict);
> + if (ret)
> + return ret;
> +
> + if (iommu_dma_non_strict) {
> + pr_warn("WARNING: iommu non-strict mode is chosen.\n"
> + "It's good for scatter-gather performance but lacks full isolation\n");
Hmm, not sure about this message either and tainting is probably over the
top. Maybe drop the taint and just pr_info something like "IOMMU DMA ops
using lazy TLB invalidation: unable to protect against malicious devices"
> + add_taint(TAINT_WARN, LOCKDEP_STILL_OK);
> + }
> +
> + return 0;
> +}
> +early_param("iommu.non_strict", iommu_dma_setup);
> +
> static ssize_t iommu_group_attr_show(struct kobject *kobj,
> struct attribute *__attr, char *buf)
> {
> @@ -1072,6 +1091,13 @@ struct iommu_group *iommu_group_get_for_dev(struct device *dev)
> group->default_domain = dom;
> if (!group->domain)
> group->domain = dom;
> +
> + if (dom && iommu_dma_non_strict) {
> + int attr = 1;
> + iommu_domain_set_attr(dom,
> + DOMAIN_ATTR_DMA_USE_FLUSH_QUEUE,
> + &attr);
> + }
Hmm, I don't think we can guarantee that we're working with the DMA domain
here. Does this all fall out in the wash for the identity domain?
Will
next prev parent reply other threads:[~2018-09-18 17:09 UTC|newest]
Thread overview: 17+ messages / expand[flat|nested] mbox.gz Atom feed top
2018-09-14 14:30 [PATCH v7 0/6] Add non-strict mode support for iommu-dma Robin Murphy
2018-09-14 14:30 ` [PATCH v7 1/6] iommu/arm-smmu-v3: Implement flush_iotlb_all hook Robin Murphy
2018-09-14 14:30 ` [PATCH v7 2/6] iommu/dma: Add support for non-strict mode Robin Murphy
2018-09-18 17:10 ` Will Deacon
2018-09-18 18:52 ` Robin Murphy
2018-09-14 14:30 ` [PATCH v7 3/6] iommu/io-pgtable-arm: " Robin Murphy
2018-09-14 14:30 ` [PATCH v7 4/6] iommu: Add bootup option "iommu.non_strict" Robin Murphy
2018-09-18 17:10 ` Will Deacon [this message]
2018-09-18 19:01 ` Robin Murphy
2018-09-14 14:30 ` [PATCH v7 5/6] iommu/arm-smmu-v3: Add support for non-strict mode Robin Murphy
2018-09-18 17:10 ` Will Deacon
2018-09-18 19:09 ` Robin Murphy
2018-09-14 14:30 ` [PATCH v7 6/6] iommu/arm-smmu: Support " Robin Murphy
2018-09-18 17:10 ` Will Deacon
2018-09-18 19:22 ` Robin Murphy
2018-09-18 17:10 ` [PATCH v7 0/6] Add non-strict mode support for iommu-dma Will Deacon
2018-09-18 18:28 ` Robin Murphy
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=20180918171013.GK16498@arm.com \
--to=will.deacon@arm.com \
--cc=guohanjun@huawei.com \
--cc=huawei.libin@huawei.com \
--cc=iommu@lists.linux-foundation.org \
--cc=john.garry@huawei.com \
--cc=joro@8bytes.org \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linuxarm@huawei.com \
--cc=robin.murphy@arm.com \
--cc=thunder.leizhen@huawei.com \
/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).