Hi, On Wed, Aug 26, 2020 at 8:01 AM Sai Prakash Ranjan <saiprakash.ranjan@xxxxxxxxxxxxxx> wrote: > > On 2020-08-26 19:21, Robin Murphy wrote: > > On 2020-08-26 13:17, Sai Prakash Ranjan wrote: > >> On 2020-08-26 17:07, Robin Murphy wrote: > >>> On 2020-08-25 16:42, Sai Prakash Ranjan 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". > >>> > >>> There seems to be considerable overlap here with both the existing > >>> patches for per-device default domain control [1], and the broader > >>> ongoing development on how to define, evaluate and handle "trusted" > >>> vs. "untrusted" devices (e.g. [2],[3]). I'd rather see work done to > >>> make sure those integrate properly together and work well for > >>> everyone's purposes, than add more disjoint mechanisms that only > >>> address small pieces of the overall issue. > >>> > >>> Robin. > >>> > >>> [1] > >>> https://lore.kernel.org/linux-iommu/20200824051726.7xaJRTTszJuzdFWGJ8YNsshCtfNR0BNeMrlILAyqt_0@z/ > >>> [2] > >>> https://lore.kernel.org/linux-iommu/20200630044943.3425049-1-rajatja@xxxxxxxxxx/ > >>> [3] > >>> https://lore.kernel.org/linux-iommu/20200626002710.110200-2-rajatja@xxxxxxxxxx/ > >> > >> Thanks for the links, [1] definitely sounds interesting, I was under > >> the impression > >> that changing such via sysfs is late, but seems like other Sai has got > >> it working > >> for the default domain type. So we can extend that and add a strict > >> attribute as well, > >> we should be definitely OK with system booting with default strict > >> mode for all > >> peripherals as long as we have an option to change that later, Doug? > > > > Right, IIRC there was initially a proposal of a command line option > > there too, and it faced the same criticism around not being very > > generic or scalable. I believe sysfs works as a reasonable compromise > > since in many cases it can be tweaked relatively early from an initrd, > > and non-essential devices can effectively be switched at any time by > > removing and reprobing their driver. > > > > Ah I see, so the catch is that device must not be bound to the driver > and won't work for the internal devices or builtin drivers probed early. Hrm, that wouldn't work so well for us for eMMC. I don't think I'm going to manage to convince folks that we need an initrd just for this. I'm probably being naive and I haven't looked at the code, but it does seem a little weird that this isn't the kind of thing that could just be tweaked for transfers going forward... > > As for a general approach for internal devices where you do believe > > the hardware is honest but don't necessarily trust whatever firmware > > it happens to be running, I'm pretty sure that's come up already, but > > I'll be sure to mention it at Rajat's imminent LPC talk if nobody else > > does. I'll at least attend. We'll see how useful my contributions are since, as per usual, I'm wandering into an area I'm not an expert in here. ;-) -Doug
