On Thu, Feb 14, 2019 at 7:40 PM Doug Anderson <dianders@xxxxxxxxxxxx> wrote: > > Hi, > > On Thu, Feb 14, 2019 at 1:32 PM Robin Murphy <robin.murphy@xxxxxxx> wrote: > > > > Hi Doug, > > > > On 2019-02-14 8:44 pm, Douglas Anderson wrote: > > > Right now the only way to disable the iommu bypass for the ARM SMMU is > > > with the kernel command line parameter 'arm-smmu.disable_bypass'. > > > > > > In general kernel command line parameters make sense for things that > > > someone would like to tweak without rebuilding the kernel or for very > > > basic communication between the bootloader and the kernel, but are > > > awkward for other things. Specifically: > > > * Human parsing of the kernel command line can be difficult since it's > > > just a big runon space separated line of text. > > > * If every bit of the system was configured via the kernel command > > > line the kernel command line would get very large and even more > > > unwieldly. > > > * Typically there are not easy ways in build systems to adjust the > > > kernel command line for config-like options. > > > > > > Let's introduce a new config option that allows us to disable the > > > iommu bypass without affecting the existing default nor the existing > > > ability to adjust the configuration via kernel command line. > > > > I say let's just flip the default - for a while now it's been one of > > those "oh yeah, we should probably do that" things that gets instantly > > forgotten again, so some 3rd-party demand is plenty to convince me :) > > > > There are few reasons to allow unmatched stream bypass, and even fewer > > good ones, so I'd be happy to shift the command-line burden over to the > > esoteric cases at this point, and consider the config option in future > > if anyone from that camp pops up and screams hard enough. > > Sure, I can submit that patch if we want. I presume I'll get lots of > screaming but I'm used to that. ;-) > > ...specifically I found that when I turned on "disably bypass" on my > board (sdm845-cheza, which is not yet upstream) that a bunch of things > that used to work broke. That's a good thing because all the things > that broke need to be fixed properly (by adding the IOMMUs) but > presumably my board is not special in relying on the old insecure > behavior. So one niggly bit, beyond the drivers that aren't but should be using iommu, is the case where bootloader lights up the display. We actually still have a lot of work to do for this (in that clk and genpd drivers need to be aware of handover, in addition to just iommu).. But I'd rather not make a hard problem harder just yet. (it gets worse, afaict so far on the windows-arm laptops since in that case uefi/edk is actually taking the iommu out of bypass and things go badly when arm-smmu disables clks after probe..) But I might recommend making the default a kconfig option for now, so in the distro kernel case, where display driver is a kernel module, you aren't making a hard problem harder. For cases where bootloader isn't enabling display, things are much easier, and I think we could switch the default sooner. But I fear for cases where bootloader is enabling display it is a much harder problem :-( BR, -R > > I'm about to head on vacation for a week so I'm not sure I'll get to > re-post before then. If not I'll post this sometime after I get back > unless someone beats me to it. > > -Doug > _______________________________________________ > iommu mailing list > iommu@xxxxxxxxxxxxxxxxxxxxxxxxxx > https://lists.linuxfoundation.org/mailman/listinfo/iommu
