On 2021-08-03 01:09, Rajat Jain wrote:
Hi Robin, Doug,
On Wed, Jul 14, 2021 at 8:14 AM Doug Anderson <dianders@xxxxxxxxxxxx> wrote:
Hi,
On Tue, Jul 13, 2021 at 11:07 AM Robin Murphy <robin.murphy@xxxxxxx> 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:
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.
Yup, most recently here:
https://lore.kernel.org/linux-iommu/cover.1627468308.git.robin.murphy@xxxxxxx/
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 gitlab.arm.com, 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 kernel.org 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) ]
Thanks,
Robin.
