From: Lu Baolu <baolu.lu@linux.intel.com>
To: John Garry <john.garry@huawei.com>,
joro@8bytes.org, will@kernel.org, dwmw2@infradead.org,
robin.murphy@arm.com, corbet@lwn.net
Cc: linux-doc@vger.kernel.org, linuxarm@huawei.com,
linux-kernel@vger.kernel.org, iommu@lists.linux-foundation.org
Subject: Re: [PATCH v14 6/6] iommu: Remove mode argument from iommu_set_dma_strict()
Date: Mon, 21 Jun 2021 18:00:25 +0800 [thread overview]
Message-ID: <855dd109-1449-7bc6-3d25-7ffeeeffa82a@linux.intel.com> (raw)
In-Reply-To: <60bdd7c3-d73e-c005-ddf7-069bc5065bce@huawei.com>
On 2021/6/21 16:12, John Garry wrote:
> On 21/06/2021 06:17, Lu Baolu wrote:
>> On 2021/6/18 19:34, John Garry wrote:
>>> diff --git a/drivers/iommu/iommu.c b/drivers/iommu/iommu.c
>>> index 60b1ec42e73b..ff221d3ddcbc 100644
>>> --- a/drivers/iommu/iommu.c
>>> +++ b/drivers/iommu/iommu.c
>>> @@ -349,10 +349,9 @@ static int __init iommu_dma_setup(char *str)
>>> }
>>> early_param("iommu.strict", iommu_dma_setup);
>>> -void iommu_set_dma_strict(bool strict)
>>> +void iommu_set_dma_strict(void)
>>> {
>>> - if (strict || !(iommu_cmd_line & IOMMU_CMD_LINE_STRICT))
>>> - iommu_dma_strict = strict;
>>> + iommu_dma_strict = true;
>>> }
>>
>
> Hi baolu,
Hi John,
>
>> Sorry for this late comment.
>> > Normally the cache invalidation policy should come from the user. We
>> have pre-build kernel option and also a kernel boot command iommu.strict
>> to override it. These seem reasonable.
>>
>> We also have a helper (iommu_set_dma_strict()) so that the vendor iommu
>> driver could squeeze in and change the previous settings mostly due to:
>>
>> a) vendor iommu driver specific kernel boot command. (We are about to
>> deprecate those.)
>>
>> b) quirky hardware.
>>
>> c) kernel optimization (e.x. strict mode in VM environment).
>>
>> a) and b) are mandatory, while c) is optional. In any instance should c)
>> override the flush mode specified by the user. Hence, probably we should
>> also have another helper like:
>>
>> void iommu_set_dma_strict_optional()
>> {
>> if (!(iommu_cmd_line & IOMMU_CMD_LINE_STRICT))
>> iommu_dma_strict = true;
>> }
>>
>> Any thoughts?
>
> What you are suggesting is a change in policy from mainline code.
> Currently for c) we always set strict enabled, regardless of any user
> cmdline input. But now you are saying that you want iommu.strict to
> override in particular scenario, right?
>
> In that case I would think it's better to rework the current API, like
> adding an option to "force" strict mode:
>
> void iommu_set_dma_strict(bool force)
> {
> if (force == true)
> iommu_dma_strict = true;
> else if (!(iommu_cmd_line & IOMMU_CMD_LINE_STRICT))
> iommu_dma_strict = true;
> }
>
> So we would use iommu_set_dma_strict(true) for a) and b), but
> iommu_set_dma_strict(false) for c).
Yes. We need to distinguish the "must" and "nice-to-have" cases of
setting strict mode.
>
> Then I am not sure what you want to do with the accompanying print for
> c). It was:
> "IOMMU batching is disabled due to virtualization"
>
> And now is from this series:
> "IOMMU batching disallowed due to virtualization"
>
> Using iommu_get_dma_strict(domain) is not appropriate here to know the
> current mode (so we know whether to print).
>
> Note that this change would mean that the current series would require
> non-trivial rework, which would be unfortunate so late in the cycle.
This patch series looks good to me and I have added by reviewed-by.
Probably we could make another patch series to improve it so that the
kernel optimization should not override the user setting.
Best regards,
baolu
_______________________________________________
iommu mailing list
iommu@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/iommu
next prev parent reply other threads:[~2021-06-21 10:00 UTC|newest]
Thread overview: 23+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-06-18 11:34 [PATCH v14 0/6] iommu: Enhance IOMMU default DMA mode build options John Garry
2021-06-18 11:34 ` [PATCH v14 1/6] iommu: Deprecate Intel and AMD cmdline methods to enable strict mode John Garry
2021-06-18 13:09 ` Lu Baolu
2021-06-18 11:34 ` [PATCH v14 2/6] iommu: Print strict or lazy mode at init time John Garry
2021-06-18 13:10 ` Lu Baolu
2021-06-18 11:34 ` [PATCH v14 3/6] iommu: Enhance IOMMU default DMA mode build options John Garry
2021-06-18 13:11 ` Lu Baolu
2021-06-18 11:34 ` [PATCH v14 4/6] iommu/vt-d: Add support for " John Garry
2021-06-18 13:12 ` Lu Baolu
2021-06-18 11:34 ` [PATCH v14 5/6] iommu/amd: " John Garry
2021-06-18 11:34 ` [PATCH v14 6/6] iommu: Remove mode argument from iommu_set_dma_strict() John Garry
2021-06-18 13:13 ` Lu Baolu
2021-06-21 5:17 ` Lu Baolu
2021-06-21 8:12 ` John Garry
2021-06-21 10:00 ` Lu Baolu [this message]
2021-06-21 10:34 ` John Garry
2021-06-21 11:59 ` Robin Murphy
2021-06-21 12:08 ` John Garry
2021-06-21 14:32 ` Lu Baolu
2021-06-22 22:25 ` Robin Murphy
2021-06-23 7:21 ` Lu Baolu
2021-06-25 16:41 ` [PATCH v14 0/6] iommu: Enhance IOMMU default DMA mode build options John Garry
2021-07-08 9:38 ` joro
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=855dd109-1449-7bc6-3d25-7ffeeeffa82a@linux.intel.com \
--to=baolu.lu@linux.intel.com \
--cc=corbet@lwn.net \
--cc=dwmw2@infradead.org \
--cc=iommu@lists.linux-foundation.org \
--cc=john.garry@huawei.com \
--cc=joro@8bytes.org \
--cc=linux-doc@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linuxarm@huawei.com \
--cc=robin.murphy@arm.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).