LKML Archive on
help / color / mirror / Atom feed
From: Doug Anderson <>
To: Joerg Roedel <>
Cc: Will Deacon <>,
	Robin Murphy <>,
	Bjorn Andersson <>,
	Ulf Hansson <>,
	Adrian Hunter <>,
	Bjorn Helgaas <>,
	John Garry <>,
	Rob Clark <>,, Saravana Kannan <>,
	Rajat Jain <>,
	Sai Prakash Ranjan <>,
	Veerabhadrarao Badiganti <>,
	Linux MMC List <>,
	linux-arm-msm <>,,
	" DRIVERS <>,
	Joerg Roedel <>,"
	Sonny Rao <>,
	Joel Fernandes <>,
	Andrew Morton <>,
	Jonathan Corbet <>,
	Jordan Crouse <>,
	Konrad Dybcio <>,
	Krishna Reddy <>,
	"Maciej W. Rozycki" <>,
	Nicolin Chen <>,
	"Paul E. McKenney" <>,
	Peter Zijlstra <>,
	Randy Dunlap <>,
	Thierry Reding <>,
	Viresh Kumar <>,
	Vlastimil Babka <>,
	Linux ARM <>,
	Linux Doc Mailing List <>,
	LKML <>
Subject: Re: [PATCH v2 0/3] iommu: Enable non-strict DMA on QCom SD/MMC
Date: Thu, 8 Jul 2021 07:36:20 -0700	[thread overview]
Message-ID: <> (raw)
In-Reply-To: <>


On Thu, Jul 8, 2021 at 1:09 AM Joerg Roedel <> wrote:
> On Wed, Jul 07, 2021 at 01:00:13PM -0700, Doug Anderson wrote:
> > a) Nothing is inherently broken with my current approach.
> >
> > b) My current approach doesn't make anybody terribly upset even if
> > nobody is totally in love with it.
> Well, no, sorry :)
> I don't think it is a good idea to allow drivers to opt-out of the
> strict-setting. This is a platform or user decision, and the driver
> should accept whatever it gets.

Sure, I agree with you there. The driver shouldn't ever be able to
override and make things less strict than the user or platform wants.
It feels like that can be accomplished. See below.

> So the real question is still why strict is the default setting and how
> to change that.

I guess there are two strategies if we agree that there's a benefit to
running some devices in strict and others in non-strict:

* opt-in to strict: default is non-strict and we have to explicitly
list what we want to be strict.

* opt-out of strict: default is strict and we have to explicitly list
what we want to be non-strict.

I guess the question is: do we allow both strategies or only one of
them? I think you are suggesting that the kernel should support
"opt-in" to strict and that that matches the status quo with PCI on
x86. I'm pushing for some type of "opt-out" of strict support. I have
heard from security folks that they'd prefer "opt-out" of strict as
well. If we're willing to accept more complex config options we could
support both choosable by KConfig. How it'd all work in my mind:

Command line:

* iommu.strict=0 - suggest non-strict by default
* iommu.strict=1 - force strict for all drivers
* iommu.strict not specified - no opinion


* IOMMU_DEFAULT_LAZY - suggest non-strict by default; drivers can
opt-in to strict
* IOMMU_DEFAULT_STRICT - force strict for all drivers
* IOMMU_DEFAULT_LOOSE_STRICT - allow explicit suggestions for laziness
but default to strict if no votes.

* suggest lazy - suggest non-strict
* force strict - force strict
* no vote

How the above work together:

* if _any_ of the three things wants strict then it's strict.

* if _all_ of the three things want lazy then it's lazy.

* If the KConfig is "loose strict" and the command line is set to
"lazy" then it's equivalent to the KConfig saying "lazy". In other
words drivers could still "opt-in" to strict but otherwise we'd be

* The only way for a driver's "suggest lazy" vote to have any effect
at all is if "iommu.strict" wasn't specified on the command line _and_
if the KConfig was "loose strict". This is effectively the "opt-out"
of lazy.

If you think the strategy I describe above is garbage then would you
be OK if I re-worked my patchset to at least allow non-PCI drivers to
"opt-in" to strict? Effectively I'd change patch #3 to list all of the
peripherals on my SoC _except_ the USB and SD/MMC and request that
they all be strict. If other people expressed their preference for the
"opt-out" of strict strategy would that change your mind?

> Or document for the users that want performance how to
> change the setting, so that they can decide.

Pushing this to the users can make sense for a Linux distribution but
probably less sense for an embedded platform. So I'm happy to make
some way for a user to override this (like via kernel command line),
but I also strongly believe there should be a default that users don't
have to futz with that we think is correct.


  reply	other threads:[~2021-07-08 14:36 UTC|newest]

Thread overview: 20+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-06-24 17:17 Douglas Anderson
2021-06-24 17:17 ` [PATCH v2 1/3] iommu: Add per-domain strictness and combine with the global default Douglas Anderson
2021-06-24 17:17 ` [PATCH v2 2/3] iommu/arm-smmu: Check for strictness after calling impl->init_context() Douglas Anderson
2021-06-24 17:17 ` [PATCH v2 3/3] mmc: sdhci-msm: Request non-strict IOMMU mode Douglas Anderson
2021-06-24 23:05   ` Doug Anderson
2021-06-25 13:18 ` [PATCH v2 0/3] iommu: Enable non-strict DMA on QCom SD/MMC Joerg Roedel
2021-06-25 14:42   ` Doug Anderson
2021-07-07 20:00     ` Doug Anderson
2021-07-08  8:08       ` Joerg Roedel
2021-07-08 14:36         ` Doug Anderson [this message]
2021-07-13 18:07           ` Robin Murphy
2021-07-14 15:14             ` Doug Anderson
2021-08-03  0:09               ` Rajat Jain
2021-08-03  0:34                 ` Rajat Jain
2021-08-03  8:19                 ` Robin Murphy
2021-07-09 13:56         ` Robin Murphy
2021-07-14 10:15           ` Joerg Roedel
2021-07-14 10:29             ` Robin Murphy
2021-07-14 10:48               ` Joerg Roedel
2021-07-09 19:21         ` 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:

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to='' \ \ \ \ \ \ \ \ \ \ \ \ \ \ \ \ \ \ \ \ \ \ \ \ \ \ \ \ \ \ \ \ \ \ \ \ \ \
    --subject='Re: [PATCH v2 0/3] iommu: Enable non-strict DMA on QCom SD/MMC' \

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