Re: [PATCH 0/3] Request direct mapping for modem firmware subdevice

[Robin Murphy]

On 2020-03-12 6:28 am, Sai Prakash Ranjan wrote:
> Hi Robin,
>
> On 2020-03-10 22:14, Robin Murphy wrote:
> > On 10/03/2020 4:23 pm, Joerg Roedel wrote:
> > > On Tue, Mar 10, 2020 at 07:30:50PM +0530, Sibi Sankar wrote:
> > > > 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@xxxxxxxxx/ 
> >
> >
> > 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.