| Message ID | 20200309182255.20142-1-sibis@codeaurora.org (mailing list archive) |
|---|---|
| Headers | show |
| Series | Request direct mapping for modem firmware subdevice | expand |
On Mon, Mar 09, 2020 at 11:52:52PM +0530, Sibi Sankar wrote: > The Q6 modem sub-system has direct access to DDR through memnoc and > an indirect access routed through a SMMU which MSS CE (crypto engine > sub-component of MSS) uses during out of reset sequence. Request direct > mapping for the modem-firmware subdevice since smmu is not expected > to provide access control/translation for these SIDs (sandboxing of the > modem is achieved through XPUs engaged using SMC calls). So the DMA accesses are initiated by the firmware and need to be direct mapped? Which memory region do they access? Regards, Joerg
Hey Joerg, Thanks for taking time to review the series! On 2020-03-10 16:53, Joerg Roedel wrote: > On Mon, Mar 09, 2020 at 11:52:52PM +0530, Sibi Sankar wrote: >> The Q6 modem sub-system has direct access to DDR through memnoc and >> an indirect access routed through a SMMU which MSS CE (crypto engine >> sub-component of MSS) uses during out of reset sequence. Request >> direct >> mapping for the modem-firmware subdevice since smmu is not expected >> to provide access control/translation for these SIDs (sandboxing of >> the >> modem is achieved through XPUs engaged using SMC calls). > > So the DMA accesses are initiated by the firmware and need to be direct > mapped? Which memory region do they access? 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). With ARM_SMMU_DISABLE_BYPASS_BY_DEFAULT y the firmware SIDs will explicitly need to be directly mapped to avoid observing global faults in the absence of secure firmware (TrustZone) programming the modem SIDs as S2CR-Bypass. > > Regards, > > Joerg
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. Regards, Joerg
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@gmail.com/ 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. Robin.
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@gmail.com/ > > 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/ Thanks, Sai
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@gmail.com/ >> >> >> 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.
On Mon, Mar 09, 2020 at 11:52:52PM +0530, Sibi Sankar wrote: > The Q6 modem sub-system has direct access to DDR through memnoc and > an indirect access routed through a SMMU which MSS CE (crypto engine > sub-component of MSS) uses during out of reset sequence. Request direct > mapping for the modem-firmware subdevice since smmu is not expected > to provide access control/translation for these SIDs (sandboxing of the > modem is achieved through XPUs engaged using SMC calls). Please fix your device tree so that the device isn't bound to an IOMMU.
Hey Christoph, Thanks for taking time to review the series. On 2020-03-16 21:20, Christoph Hellwig wrote: > On Mon, Mar 09, 2020 at 11:52:52PM +0530, Sibi Sankar wrote: >> The Q6 modem sub-system has direct access to DDR through memnoc and >> an indirect access routed through a SMMU which MSS CE (crypto engine >> sub-component of MSS) uses during out of reset sequence. Request >> direct >> mapping for the modem-firmware subdevice since smmu is not expected >> to provide access control/translation for these SIDs (sandboxing of >> the >> modem is achieved through XPUs engaged using SMC calls). > > Please fix your device tree so that the device isn't bound to an > IOMMU. the bindings proposed in the series would add a sub-device with an iommu property. modem_pil: remoteproc@xxxxx { ... modem-firmware { iommus = <&apps_smmu 0x460 0x1>; }; ... }; Remoteproc device will not have a iommu property but modem-firmware sub-device will. With ARM_SMMU_DISABLE_BYPASS_BY_DEFAULT y, we would want to configure the SID either in direct mapping or bypass (either will do since protection is achieved through other means) https://lore.kernel.org/lkml/497e40b8-300f-1b83-4312-93a58c459d1d@arm.com/ Currently the restructuring is trending towards whats discussed in the ^^ thread. i.e either direct mapping/bypass will be done in the SoC specific corner of the SMMU driver.
Hi Robin, On 2020-03-12 17:35, Robin Murphy wrote: > On 2020-03-12 6:28 am, Sai Prakash Ranjan wrote: >> Hi Robin, >> >> >> 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... :) ] > It would be great if you could review the patch - https://lore.kernel.org/patchwork/patch/1183530/ Sibi has posted a v2 of this series based on that patch. Thanks, Sai
The Q6 modem sub-system has direct access to DDR through memnoc and an indirect access routed through a SMMU which MSS CE (crypto engine sub-component of MSS) uses during out of reset sequence. Request direct mapping for the modem-firmware subdevice since smmu is not expected to provide access control/translation for these SIDs (sandboxing of the modem is achieved through XPUs engaged using SMC calls). Sibi Sankar (3): iommu: Export "iommu_request_dm_for_dev" dt-bindings: remoteproc: qcom: Add modem-firmware bindings remoteproc: qcom_q6v5_mss: Request direct mapping for firmware subdevice .../bindings/remoteproc/qcom,q6v5.txt | 4 ++ drivers/iommu/iommu.c | 1 + drivers/remoteproc/qcom_q6v5_mss.c | 68 +++++++++++++++++++ 3 files changed, 73 insertions(+)