Hi, On Tue, Aug 25, 2020 at 8:43 AM Sai Prakash Ranjan <saiprakash.ranjan@xxxxxxxxxxxxxx> 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". > > Example: iommu.nonstrict_device="7c4000.sdhci,a600000.dwc3,6048000.etr" I have an inherent dislike of jamming things like this onto the command line. IMHO the command line is the last resort for specifying configuration and generally should be limited to some specialized debug options and cases where the person running the kernel needs to override a config that was set by the person (or company) compiling the kernel. Specifically, having a long/unwieldy command line makes it harder to use for the case when an end user actually wants to use it to override something. It's also just another place to look for config. The other problem is that this doesn't necessarily scale very well. While it works OK for embedded cases it doesn't work terribly well for distributions. I know that in an out-of-band thread you indicated that it doesn't break anything that's not already broken (AKA this doesn't fix the distro case but it doesn't make it worse), it would be better to come up with a more universal solution. Ideally it feels like we should figure out how to tag devices in a generic manner automatically (hardcode at the driver or in the device tree). I think the out-of-band discussions talked about "external facing" and the like. We could also, perhaps, tag devices that have "binary blob" firmware if we wanted. Then we'd have a policy (set by Kconfig, perhaps overridable via commandline) that indicated the strictness level for the various classes of devices. So policy would be decided by KConfig and/or command line. -Doug
