From: Sai Prakash Ranjan <saiprakash.ranjan@codeaurora.org>
To: Robin Murphy <robin.murphy@arm.com>
Cc: linux-kernel@vger.kernel.org, Joerg Roedel <joro@8bytes.org>,
Douglas Anderson <dianders@chromium.org>,
Stephen Boyd <swboyd@chromium.org>,
iommu@lists.linux-foundation.org, linux-arm-msm@vger.kernel.org,
Tomasz Figa <tfiga@chromium.org>, Will Deacon <will@kernel.org>,
linux-arm-kernel@lists.infradead.org
Subject: Re: [PATCH] iommu: Add support to filter non-strict/lazy mode based on device names
Date: Wed, 26 Aug 2020 20:31:03 +0530 [thread overview]
Message-ID: <f8ac8f57bcf10b2218b4795197efb854@codeaurora.org> (raw)
In-Reply-To: <a03ce8f0-cab5-2782-ac50-930cf94b7dcd@arm.com>
On 2020-08-26 19:21, Robin Murphy wrote:
> On 2020-08-26 13:17, Sai Prakash Ranjan wrote:
>> On 2020-08-26 17:07, Robin Murphy wrote:
>>> On 2020-08-25 16:42, Sai Prakash Ranjan wrote:
>>>> Currently the non-strict or lazy mode of TLB invalidation can only
>>>> be set
>>>> for all or no domains. This works well for development platforms
>>>> where
>>>> setting to non-strict/lazy mode is fine for performance reasons but
>>>> on
>>>> production devices, we need a more fine grained control to allow
>>>> only
>>>> certain peripherals to support this mode where we can be sure that
>>>> it is
>>>> safe. So add support to filter non-strict/lazy mode based on the
>>>> device
>>>> names that are passed via cmdline parameter
>>>> "iommu.nonstrict_device".
>>>
>>> There seems to be considerable overlap here with both the existing
>>> patches for per-device default domain control [1], and the broader
>>> ongoing development on how to define, evaluate and handle "trusted"
>>> vs. "untrusted" devices (e.g. [2],[3]). I'd rather see work done to
>>> make sure those integrate properly together and work well for
>>> everyone's purposes, than add more disjoint mechanisms that only
>>> address small pieces of the overall issue.
>>>
>>> Robin.
>>>
>>> [1]
>>> https://lore.kernel.org/linux-iommu/20200824051726.7xaJRTTszJuzdFWGJ8YNsshCtfNR0BNeMrlILAyqt_0@z/
>>> [2]
>>> https://lore.kernel.org/linux-iommu/20200630044943.3425049-1-rajatja@google.com/
>>> [3]
>>> https://lore.kernel.org/linux-iommu/20200626002710.110200-2-rajatja@google.com/
>>
>> Thanks for the links, [1] definitely sounds interesting, I was under
>> the impression
>> that changing such via sysfs is late, but seems like other Sai has got
>> it working
>> for the default domain type. So we can extend that and add a strict
>> attribute as well,
>> we should be definitely OK with system booting with default strict
>> mode for all
>> peripherals as long as we have an option to change that later, Doug?
>
> Right, IIRC there was initially a proposal of a command line option
> there too, and it faced the same criticism around not being very
> generic or scalable. I believe sysfs works as a reasonable compromise
> since in many cases it can be tweaked relatively early from an initrd,
> and non-essential devices can effectively be switched at any time by
> removing and reprobing their driver.
>
Ah I see, so the catch is that device must not be bound to the driver
and won't work for the internal devices or builtin drivers probed early.
-Sai
> As for a general approach for internal devices where you do believe
> the hardware is honest but don't necessarily trust whatever firmware
> it happens to be running, I'm pretty sure that's come up already, but
> I'll be sure to mention it at Rajat's imminent LPC talk if nobody else
> does.
>
> Robin.
--
QUALCOMM INDIA, on behalf of Qualcomm Innovation Center, Inc. is a
member
of Code Aurora Forum, hosted by The Linux Foundation
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
next prev parent reply other threads:[~2020-08-26 15:04 UTC|newest]
Thread overview: 13+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-08-25 15:42 [PATCH] iommu: Add support to filter non-strict/lazy mode based on device names Sai Prakash Ranjan
2020-08-25 16:10 ` Doug Anderson
2020-08-25 19:00 ` Sai Prakash Ranjan
2020-08-25 22:15 ` Doug Anderson
2020-08-25 22:53 ` Rob Clark
2020-08-26 0:24 ` Doug Anderson
2020-08-26 1:16 ` Rob Clark
2020-08-26 8:03 ` Sai Prakash Ranjan
2020-08-26 11:37 ` Robin Murphy
2020-08-26 12:17 ` Sai Prakash Ranjan
2020-08-26 13:51 ` Robin Murphy
2020-08-26 15:01 ` Sai Prakash Ranjan [this message]
2020-08-26 15:07 ` 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=f8ac8f57bcf10b2218b4795197efb854@codeaurora.org \
--to=saiprakash.ranjan@codeaurora.org \
--cc=dianders@chromium.org \
--cc=iommu@lists.linux-foundation.org \
--cc=joro@8bytes.org \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-arm-msm@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=robin.murphy@arm.com \
--cc=swboyd@chromium.org \
--cc=tfiga@chromium.org \
--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).