Re: [PATCH v2 0/3] iommu: Enable non-strict DMA on QCom SD/MMC
From: Rajat Jain <hidden>
Date: 2021-08-03 00:09:48
Also in:
linux-arm-kernel, linux-arm-msm, linux-iommu, linux-mmc, linux-pci, lkml
Hi Robin, Doug, On Wed, Jul 14, 2021 at 8:14 AM Doug Anderson [off-list ref] wrote:
Hi, On Tue, Jul 13, 2021 at 11:07 AM Robin Murphy [off-list ref] wrote:quoted
On 2021-07-08 15:36, Doug Anderson wrote: [...]quoted
quoted
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: https://gitlab.arm.com/linux-arm/linux-rm/-/commits/iommu/fq
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.
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? Thanks, Rajat