Hi Rob, On Mon, Aug 2, 2021 at 5:09 PM Rajat Jain <rajatja@xxxxxxxxxx> 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 BTW, is there another mirror to this? I (and another colleague) are getting the following error when trying to clone it: rajatja@rajat2:~/rob_iommu$ git clone https://git.gitlab.arm.com/linux-arm/linux-rm.git Cloning into 'linux-rm'... remote: Enumerating objects: 125712, done. remote: Counting objects: 100% (125712/125712), done. remote: Compressing objects: 100% (41203/41203), done. error: RPC failed; curl 18 transfer closed with outstanding read data remaining error: 804 bytes of body are still expected fetch-pack: unexpected disconnect while reading sideband packet fatal: early EOF fatal: fetch-pack: invalid index-pack output rajatja@rajat2:~/rob_iommu$ We've tried both git and https methods. > > 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
