On 2020-03-12 6:28 am, Sai Prakash Ranjan wrote:

Hi Robin,

On 2020-03-10 22:14, Robin Murphy wrote:

quoted

On 10/03/2020 4:23 pm, Joerg Roedel wrote:

quoted

On Tue, Mar 10, 2020 at 07:30:50PM +0530, Sibi Sankar wrote:

quoted

The accesses are initiated by the firmware
and they access modem reserved regions.
However as explained in ^^ any accesses
outside the region will result in a violation
and is controlled through XPUs (protection units).

Okay, this sounds like a case for arm_smmu_get_resv_region(). It should
return an entry for the reserved memory region the firmware needs to
access, so that generic iommu can setup this mapping.

Note that it should return that entry only for your device, not for all
devices. Maybe there is a property in DT or IORT you can set to
transport this information into the arm-smmu driver.

This is pretty similar to RMRR mapping on the Intel VT-d IOMMU or
Unity-mapped ranges in the AMD-Vi IOMMU.

Yup, a way to describe boot-time memory regions in IORT is in the
process of being specced out; the first attempt at an equivalent for
DT is here:

https://lore.kernel.org/linux-iommu/20191209150748.2471814-1-thierry.reding@gmail.com/ (local) 


If that's not enough and the SMMU still needs to treat certain Stream
IDs specially because they may be untranslatable (due to having direct
access to memory as a side-channel), then that should be handled in
the SoC-specific corner of the SMMU driver, not delegated to
individual endpoint drivers.

Are you talking about this one for SoC specific change - 
https://lore.kernel.org/patchwork/patch/1183530/

Exactly - this particular wheel needs no reinventing at all.

[ I guess I should go review those patches properly... :) ]

Robin.