Hi Robin, Mathieu
On 2020-06-03 17:07, Robin Murphy wrote:
On 2020-06-01 22:28, Mathieu Poirier wrote:
That being said I'm sure that dependencies on an IOMMU isn't a problem
confined
to coresight. I am adding Robin Murphy, who added this commit [1], to
the thread
in the hope that he can provide guidance on the right way to do this.
Right, it's not specific to CoreSight, and it's not even specific to
IOMMUs really. In short, blame kexec ;)
Yes it is not specific to coresight, we are targeting this for all
consumers/clients of SMMU(atleast on SC7180 SoC). We have display
throwing
NoC/interconnect errors[1] during reboot after SMMU is disabled.
This is also not specific to kexec either as you explained here [2]
about
a case with display which is exacly what is happening in our system [1].
[1]
https://lore.kernel.org/lkml/1591009402-681-1-git-send-email-mkrishn@xxxxxxxxxxxxxx/
[2]
https://lore.kernel.org/lkml/5858bdac-b7f9-ac26-0c0d-c9653cef841d@xxxxxxx/
The fundamental thing is that devices should stop any DMA activity at
shutdown. For a normal poweroff you can typically get away without
doing so, but over kexec, ongoing DMA traffic may corrupt memory in
the new kernel (at worst, I think even DMA reads could potentially
cause unexpected cache behaviour that might lead to mishaps, given the
right combination of memory attributes).
IOMMUs merely help to make the situation more serious. For similar
kexec reasons, they need to disable any existing translations at
shutdown (imagine if the second kernel didn't have an IOMMU driver).
And at that point, even the normal poweroff case becomes problematic,
because any device DMA that hasn't been shut down beforehand is now
not necessarily going benignly to memory as it would in the no-IOMMU
case above, but potentially to random physical addresses, with all the
hilarity ensuing that you would expect from that.
Thanks,
Sai
--
QUALCOMM INDIA, on behalf of Qualcomm Innovation Center, Inc. is a
member
of Code Aurora Forum, hosted by The Linux Foundation
