LKML Archive on
help / color / mirror / Atom feed
From: Robin Murphy <>
To: Rajat Jain <>, Doug Anderson <>
Cc: Joerg Roedel <>, Will Deacon <>,
	Bjorn Andersson <>,
	Ulf Hansson <>,
	Adrian Hunter <>,
	Bjorn Helgaas <>,
	John Garry <>,
	Rob Clark <>,, Saravana Kannan <>,
	Sai Prakash Ranjan <>,
	Veerabhadrarao Badiganti <>,
	Linux MMC List <>,
	linux-arm-msm <>,,
	" DRIVERS" <>,
	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: Tue, 3 Aug 2021 09:19:08 +0100	[thread overview]
Message-ID: <> (raw)
In-Reply-To: <>

On 2021-08-03 01:09, Rajat Jain wrote:
> Hi Robin, Doug,
> On Wed, Jul 14, 2021 at 8:14 AM Doug Anderson <> wrote:
>> Hi,
>> On Tue, Jul 13, 2021 at 11:07 AM Robin Murphy <> wrote:
>>> On 2021-07-08 15:36, Doug Anderson wrote:
>>> [...]
>>>>> 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.
>>> FYI I did make progress on the "punt it to userspace" approach. I'm not
>>> posting it even as an RFC yet because I still need to set up a machine
>>> to try actually testing any of it (it's almost certainly broken
>>> somewhere), but in the end it comes out looking surprisingly not too bad
>>> overall. If you're curious to take a look in the meantime I put it here:
> I was wondering if you got any closer to testing / sending it out? I
> looked at the patches and am trying to understand, would they also
> make it possible to convert at runtime, an existing "non-strict"
> domain (for a particular device) into a "strict" domain leaving the
> other devices/domains as-is? Please let me know when you think your
> patches are good to be tested, and I'd also be interested in trying
> them out.

Yup, most recently here:

I'm currently getting v3 ready, so I'll try to remember to add you to 
the CC list.

>> Being able to change this at runtime through sysfs sounds great and it
>> fills all the needs I'm aware of, thanks! In Chrome OS we can just use
>> this with some udev rules and get everything we need.
> I still have another (inverse) use case where this does not work:
> We have an Intel chromebook with the default domain type being
> non-strict. There is an LTE modem (an internal PCI device which cannot
> be marked external), which we'd like to be treated as a "Strict" DMA
> domain.
> Do I understand it right that using Rob's patches, I could potentially
> switch the domain to "strict" *after* booting (since we don't use
> initramfs), but by that time, the driver might have already attached
> to the modem device (using "non-strict" domain), and thus the damage
> may have already been done? So perhaps we still need a device property
> that the firmware could use to indicate "strictness" for certain
> devices at boot?

Well, in my view the "external facing" firmware property *should* 
effectively be the "I don't trust this device not to misbehave" 
property, but I guess it's a bit too conflated with other aspects of 
Thunderbolt root ports (at least in the ACPI definition) to abuse in 
that manner.

Ideas off the top of my head would be to flip the default domain type 
and manually relax all the other performance-sensitive devices instead, 
or module_blacklist the modem driver to load manually later after 
tweaking its group. However, if you think it's a sufficiently general 
concern, maybe a quirk to set pci_dev->untrusted might be worth 
exploring? It may make sense to drive such a thing from a command-line 
option rather than a hard-coded list, though, since trust is really down 
to the individual use-case.

[ re, I understand it tends not to like large transfers - 
some colleagues have reported similar issues pushing large repos as 
well. I'd suggest cloning the base mainline repo from or 
another reliable source, then fetching my branch into that. I've just 
tried that on a different machine (outside the work network) and it 
worked fine) ]


  parent reply	other threads:[~2021-08-03  8:19 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
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 [this message]
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 \ \ \ \ \ \ \ \ \ \ \ \ \ \ \ \ \ \ \ \ \ \ \ \ \ \ \ \ \ \ \ \ \ \ \ \ \ \ \
    --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).