Linux Remote Processor Subsystem development
 help / color / mirror / Atom feed
From: Srinivasa Rao Mandadapu <quic_srivasam@quicinc.com>
To: Stephen Boyd <swboyd@chromium.org>, <agross@kernel.org>,
	<bgoswami@quicinc.com>, <bjorn.andersson@linaro.org>,
	<broonie@kernel.org>, <devicetree@vger.kernel.org>,
	<judyhsiao@chromium.org>, <lgirdwood@gmail.com>,
	<linux-arm-msm@vger.kernel.org>, <linux-kernel@vger.kernel.org>,
	<linux-remoteproc@vger.kernel.org>, <perex@perex.cz>,
	<quic_plai@quicinc.com>, <quic_rohkumar@quicinc.com>,
	<robh+dt@kernel.org>, <srinivas.kandagatla@linaro.org>,
	<tiwai@suse.com>
Subject: Re: [RESEND v5 6/7] remoteproc: qcom: Add support for memory sandbox
Date: Thu, 8 Sep 2022 18:29:18 +0530	[thread overview]
Message-ID: <025909d1-6c92-01e2-e786-5ed25608cbac@quicinc.com> (raw)
In-Reply-To: <df904bab-8c37-0797-1226-bc867178ed0b@quicinc.com>


On 8/25/2022 3:34 PM, Srinivasa Rao Mandadapu wrote:
>
> On 8/23/2022 8:55 AM, Stephen Boyd wrote:
> Thanks for your time and valuable suggestions!!!
>> Quoting Srinivasa Rao Mandadapu (2022-08-22 01:22:02)
>>> diff --git a/drivers/remoteproc/qcom_q6v5_adsp.c 
>>> b/drivers/remoteproc/qcom_q6v5_adsp.c
>>> index b0a63a0..d01c97e 100644
>>> --- a/drivers/remoteproc/qcom_q6v5_adsp.c
>>> +++ b/drivers/remoteproc/qcom_q6v5_adsp.c
>>> @@ -333,6 +336,185 @@ static int adsp_load(struct rproc *rproc, 
>>> const struct firmware *fw)
>>>          return 0;
>>>   }
>>>
>>> +static void adsp_of_unmap_smmu(struct iommu_domain *iommu_dom, 
>>> const __be32 *prop, int len)
>>> +{
>>> +       unsigned long iova;
>>> +       unsigned int mem_size;
>>> +       int i;
>>> +
>>> +       len /= sizeof(__be32);
>>> +       for (i = 0; i < len; i++) {
>>> +               iova = be32_to_cpu(prop[i++]);
>>> +               /* Skip Physical address*/
>>> +               i++;
>>> +               mem_size = be32_to_cpu(prop[i++]);
>>> +               iommu_unmap(iommu_dom, iova, mem_size);
>>> +       }
>>> +}
>>> +
>>> +static void adsp_rproc_unmap_smmu(struct rproc *rproc, int len)
>>> +{
>>> +       struct fw_rsc_devmem *rsc_fw;
>>> +       struct fw_rsc_hdr *hdr;
>>> +       int offset;
>>> +       int i;
>>> +
>>> +       for (i = 0; i < len; i++) {
>>> +               offset = rproc->table_ptr->offset[i];
>>> +               hdr = (void *)rproc->table_ptr + offset;
>>> +               rsc_fw = (struct fw_rsc_devmem *)hdr + sizeof(*hdr);
>>> +
>>> +               iommu_unmap(rproc->domain, rsc_fw->da, rsc_fw->len);
>>> +       }
>>> +}
>>> +
>>> +static void adsp_unmap_smmu(struct rproc *rproc)
>>> +{
>>> +       struct qcom_adsp *adsp = (struct qcom_adsp *)rproc->priv;
>>> +       const __be32 *prop;
>>> +       unsigned int len;
>>> +
>>> +       iommu_unmap(adsp->iommu_dom, adsp->mem_phys, adsp->mem_size);
>>> +
>>> +       prop = of_get_property(adsp->dev->of_node, 
>>> "qcom,adsp-memory-regions", &len);
>>> +       if (prop) {
>>> +               adsp_of_unmap_smmu(adsp->iommu_dom, prop, len);
>>> +       } else {
>>> +               if (rproc->table_ptr)
>>> +                       adsp_rproc_unmap_smmu(rproc, 
>>> rproc->table_ptr->num);
>>> +       }
>>> +
>>> +       iommu_domain_free(adsp->iommu_dom);
>>> +}
>>> +
>>> +static int adsp_of_map_smmu(struct iommu_domain *iommu_dom, const 
>>> __be32 *prop, int len)
>>> +{
>>> +       unsigned long mem_phys;
>>> +       unsigned long iova;
>>> +       unsigned int mem_size;
>>> +       unsigned int flag;
>>> +       int access_level;
>>> +       int ret;
>>> +       int i;
>>> +
>>> +       len /= sizeof(__be32);
>>> +       for (i = 0; i < len; i++) {
>>> +               iova = be32_to_cpu(prop[i++]);
>>> +               mem_phys = be32_to_cpu(prop[i++]);
>>> +               mem_size = be32_to_cpu(prop[i++]);
>>> +               access_level = be32_to_cpu(prop[i]);
>>> +
>>> +               if (access_level)
>>> +                       flag = IOMMU_READ | IOMMU_WRITE;
>>> +               else
>>> +                       flag = IOMMU_READ;
>>> +
>>> +               ret = iommu_map(iommu_dom, iova, mem_phys, mem_size, 
>>> flag);
>>> +               if (ret) {
>>> +                       pr_err("failed to map addr = %p mem_size = 
>>> %x\n", &(mem_phys), mem_size);
>> Why can't this be dev_err()?
> Actually, dev pointer is not available here, hence used pr_err.
>>
>>> +                       goto of_smmu_unmap;
>>> +               }
>>> +       }
>>> +       return 0;
>>> +of_smmu_unmap:
>>> +       adsp_of_unmap_smmu(iommu_dom, prop, i);
>>> +       return ret;
>>> +}
>>> +
>>> +static int adsp_rproc_map_smmu(struct rproc *rproc, int len)
>>> +{
>>> +       struct fw_rsc_devmem *rsc_fw;
>> const?
> Okay. will update.
>>
>>> +       struct fw_rsc_hdr *hdr;
>> const?
> Okay. Will update.
>>
>>> +       int offset;
>>> +       int ret;
>>> +       int i;
>>> +
>>> +       if (!rproc->table_ptr)
>>> +               return 0;
>>> +
>>> +       for (i = 0; i < rproc->table_ptr->num; i++) {
>>> +               offset = rproc->table_ptr->offset[i];
>>> +               hdr = (void *)rproc->table_ptr + offset;
>>> +               rsc_fw = (struct fw_rsc_devmem *)hdr + sizeof(*hdr);
>>> +
>>> +               ret = iommu_map(rproc->domain, rsc_fw->da, rsc_fw->pa,
>>> +                                       rsc_fw->len, rsc_fw->flags);
>>> +               if (ret) {
>>> +                       pr_err("failed to map addr = %x mem_size = 
>>> %x\n", rsc_fw->pa, rsc_fw->len);
>> Why can't this be dev_err()?
> Okay. Will change it.
>>
>>> +                       goto rproc_smmu_unmap;
>>> +               }
>>> +       }
>>> +
>>> +       return 0;
>>> +
>>> +rproc_smmu_unmap:
>>> +       adsp_rproc_unmap_smmu(rproc, i);
>> Does i need to be incremented? And/or unmap should be done in reverse.
>
> Here i is the upper bound index in mapping failure case, hence it is 
> used as length. un-mapping is being done from starting till i value.
>
> Please correct me if I am missing some thing.
>
>>
>>> +       return ret;
>>> +}
>>> +
>>> +static int adsp_map_smmu(struct qcom_adsp *adsp, struct rproc *rproc)
>>> +{
>>> +       struct of_phandle_args args;
>>> +       const __be32 *prop;
>>> +       long long sid;
>>> +       unsigned int len;
>>> +       int ret;
>>> +
>>> +       ret = of_parse_phandle_with_args(adsp->dev->of_node, 
>>> "iommus", "#iommu-cells", 0, &args);
>>> +       if (ret < 0)
>>> +               sid = -1;
>> Is it a good idea to set the sid to -1? Does that mean all stream IDs?
> It seems, if sid is -1 iomap fails, because of alignment issues. Any I 
> will update with return in this case.
>>
>>> +       else
>>> +               sid = args.args[0] & SID_MASK_DEFAULT;
>>> +
>>> +       adsp->iommu_dom = iommu_domain_alloc(adsp->dev->bus);
>>> +       if (!adsp->iommu_dom) {
>>> +               dev_err(adsp->dev, "failed to allocate iommu 
>>> domain\n");
>>> +               ret = -ENOMEM;
>>> +               goto domain_free;
>>> +       }
>>> +
>>> +       ret = iommu_attach_device(adsp->iommu_dom, adsp->dev);
>>> +       if (ret) {
>>> +               dev_err(adsp->dev, "could not attach device ret = 
>>> %d\n", ret);
>>> +               ret = -EBUSY;
>> Why do we overwrite the error value?
> It seems not required. Will remove it.
>>
>>> +               goto detach_device;
>>> +       }
>>> +
>>> +       /* Add SID configuration for ADSP Firmware to SMMU */
>>> +       adsp->mem_phys =  adsp->mem_phys | (sid << 32);
>>> +
>>> +       ret = iommu_map(adsp->iommu_dom, adsp->mem_phys, 
>>> adsp->mem_phys,
>>> +                       adsp->mem_size, IOMMU_READ | IOMMU_WRITE);
>>> +       if (ret) {
>>> +               dev_err(adsp->dev, "Unable to map ADSP Physical 
>>> Memory\n");
>>> +               goto sid_unmap;
>>> +       }
>>> +
>>> +       prop = of_get_property(adsp->dev->of_node, 
>>> "qcom,adsp-memory-regions", &len);
>> I find it odd that we're encoding virtual addresses (iovas) into
> Actually from HLOS perspective, same IOVA and physical memory is being 
> used. Hence will remove virtual address field in DT.
>> devicetree. Presumably the physical address needs to be in DT as a
>> carveout, but after that I would think we're free to allocate the
> Will try to carveout the physical addresses and handle it accordingly. 
> If this method is ignored I don't think we need to mention in DT in 
> anyway.
>> segments from the carveout however we see fit and then program that into
>> the SMMU. Maybe DT can be a suggestion, but otherwise can it be ignored?
>
> Yes, it seems it can be ignored. As it is the approach we did for 
> bringing up AudioReach solution, and used when ADSP binary is without 
> metadata section header info.
>
> Will check internally and update accordingly.
>
> Your opinion also helps please!!. Is it okay to keep it as backup 
> option with proper comment, such that this method can be used 
> internally, with raw ADSP binary in early stage bring-up scenarios?

After internal discussions, decided to remove sandboxing using device 
tree and explicitly doing in PIL driver.

Instead, decided to use rproc's parse_fw call back 
"rproc_elf_load_rsc_table" function and achieve the sand boxing.

Will re post the patches with corresponding changes.

>
>>
>>> +       if (prop) {
>>> +               ret = adsp_of_map_smmu(adsp->iommu_dom, prop, len);
>>> +               if (ret) {
>>> +                       dev_err(adsp->dev, "Unable to map memory 
>>> regions accessed by ADSP\n");
>>> +                       goto sid_unmap;
>>> +               }
>>> +       } else {
>>> +               ret = adsp_rproc_map_smmu(rproc, len);
>>> +               if (ret) {
>>> +                       dev_err(adsp->dev, "Unable to map memory 
>>> regions accessed by ADSP\n");
>> Maybe this should be a different string in case it is confused with the
>> above print of the same string.
> Okay. Will modify the string.
As explained above will remove both of the above methods.
>>
>>> +                       goto sid_unmap;
>>> +               }
>>> +       }
>>> +       return 0;
>>> +
>>> +sid_unmap:
>>> +       iommu_unmap(adsp->iommu_dom, adsp->mem_phys, adsp->mem_size);
>>> +detach_device:
>>> +       iommu_domain_free(adsp->iommu_dom);
>>> +domain_free:
>>> +       return ret;
>>> +}
>>> +
>>> +
>>>   static int adsp_start(struct rproc *rproc)
>>>   {
>>>          struct qcom_adsp *adsp = (struct qcom_adsp *)rproc->priv;
>>> @@ -343,9 +525,16 @@ static int adsp_start(struct rproc *rproc)
>>>          if (ret)
>>>                  return ret;
>>>
>>> +       if (adsp->adsp_sandbox_needed) {
>>> +               ret = adsp_map_smmu(adsp, rproc);
>>> +               if (ret) {
>>> +                       dev_err(adsp->dev, "ADSP smmu mapping 
>>> failed\n");
>>> +                       goto disable_irqs;
>>> +               }
>>> +       }
>> Newline here please.
> Okay.
>>
>>>          ret = clk_prepare_enable(adsp->xo);
>>>          if (ret)
>>> -               goto disable_irqs;
>>> +               goto adsp_smmu_unmap;
>>>
>>>          ret = qcom_rproc_pds_enable(adsp, adsp->proxy_pds,
>>>                                      adsp->proxy_pd_count);

  reply	other threads:[~2022-09-08 13:00 UTC|newest]

Thread overview: 19+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-08-22  8:21 [RESEND v5 0/7] Update ADSP pil loader for SC7280 platform Srinivasa Rao Mandadapu
2022-08-22  8:21 ` [RESEND v5 1/7] dt-bindings: remoteproc: qcom: Add SC7280 ADSP support Srinivasa Rao Mandadapu
2022-08-23  3:04   ` Stephen Boyd
2022-08-22  8:21 ` [RESEND v5 2/7] remoteproc: qcom: Add flag in adsp private data structure Srinivasa Rao Mandadapu
2022-08-23  3:04   ` Stephen Boyd
2022-08-22  8:21 ` [RESEND v5 3/7] remoteproc: qcom: Add compatible name for SC7280 ADSP Srinivasa Rao Mandadapu
2022-08-23  3:05   ` Stephen Boyd
2022-08-23 14:35     ` Srinivasa Rao Mandadapu
2022-08-22  8:22 ` [RESEND v5 4/7] remoteproc: qcom: Replace hard coded values with macros Srinivasa Rao Mandadapu
2022-08-23  3:06   ` Stephen Boyd
2022-08-22  8:22 ` [RESEND v5 5/7] remoteproc: qcom: Add efuse evb selection control Srinivasa Rao Mandadapu
2022-08-23  3:12   ` Stephen Boyd
2022-08-22  8:22 ` [RESEND v5 6/7] remoteproc: qcom: Add support for memory sandbox Srinivasa Rao Mandadapu
2022-08-23  3:25   ` Stephen Boyd
2022-08-25 10:04     ` Srinivasa Rao Mandadapu
2022-09-08 12:59       ` Srinivasa Rao Mandadapu [this message]
2022-08-22  8:22 ` [RESEND v5 7/7] remoteproc: qcom: Update QDSP6 out-of-reset timeout value Srinivasa Rao Mandadapu
2022-08-23  3:26   ` Stephen Boyd
2022-08-25 12:18 ` [RESEND v5 0/7] Update ADSP pil loader for SC7280 platform Krzysztof Kozlowski

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=025909d1-6c92-01e2-e786-5ed25608cbac@quicinc.com \
    --to=quic_srivasam@quicinc.com \
    --cc=agross@kernel.org \
    --cc=bgoswami@quicinc.com \
    --cc=bjorn.andersson@linaro.org \
    --cc=broonie@kernel.org \
    --cc=devicetree@vger.kernel.org \
    --cc=judyhsiao@chromium.org \
    --cc=lgirdwood@gmail.com \
    --cc=linux-arm-msm@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-remoteproc@vger.kernel.org \
    --cc=perex@perex.cz \
    --cc=quic_plai@quicinc.com \
    --cc=quic_rohkumar@quicinc.com \
    --cc=robh+dt@kernel.org \
    --cc=srinivas.kandagatla@linaro.org \
    --cc=swboyd@chromium.org \
    --cc=tiwai@suse.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox