Message ID | 20230117085840.32356-1-quic_sibis@quicinc.com (mailing list archive) |
---|---|
Headers | show |
Series | Fix XPU violation during modem metadata authentication | expand |
On Tue, 17 Jan 2023 14:28:29 +0530, Sibi Sankar wrote: > The memory region allocated using dma_alloc_attr with no kernel mapping > attribute set would still be a part of the linear kernel map. Any access > to this region by the application processor after assigning it to the > remote Q6 will result in a XPU violation. Fix this by replacing the > dynamically allocated memory region with a no-map carveout and unmap the > modem metadata memory region before passing control to the remote Q6. > The addition of the carveout and memunmap is required only on SoCs that > mandate memory protection before transferring control to Q6, hence the > driver falls back to dynamic memory allocation in the absence of the > modem metadata carveout. > > [...] Applied, thanks! [01/11] dt-bindings: remoteproc: qcom,q6v5: Move MSM8996 to schema commit: bdea142295ffd76aaec2a90a36ba09ad19660686 [02/11] dt-bindings: remoteproc: qcom,msm8996-mss-pil: Update memory region commit: 9b3024247b2ddea6880fa77b638c870ddbdb6bba [03/11] dt-bindings: remoteproc: qcom,sc7180-mss-pil: Update memory-region commit: 95864f27330674c970c84b81ae791182de150b0f [04/11] dt-bindings: remoteproc: qcom,sc7280-mss-pil: Update memory-region commit: eb48137d783b4c845c7b081e32a73666326dcbb3 [05/11] Revert "remoteproc: qcom_q6v5_mss: map/unmap metadata region before/after use" commit: a899d542b687c9b04ccbd9eefabc829ba5fef791 [06/11] remoteproc: qcom_q6v5_mss: Use a carveout to authenticate modem headers commit: 57f72170a2b2a362c35bb9407fc844eac5afdec1 Best regards,
Hi Sibi, On Tue, Jan 17, 2023 at 02:28:29PM +0530, Sibi Sankar wrote: > The memory region allocated using dma_alloc_attr with no kernel mapping > attribute set would still be a part of the linear kernel map. Any access > to this region by the application processor after assigning it to the > remote Q6 will result in a XPU violation. Fix this by replacing the > dynamically allocated memory region with a no-map carveout and unmap the > modem metadata memory region before passing control to the remote Q6. > The addition of the carveout and memunmap is required only on SoCs that > mandate memory protection before transferring control to Q6, hence the > driver falls back to dynamic memory allocation in the absence of the > modem metadata carveout. [...] > remoteproc: qcom_q6v5_mss: Use a carveout to authenticate modem > headers With this change now merged, am I ok to downgrade the arm64 arch_dma_prep_coherent() back to a clean? Thanks, Will
On Mon, Mar 27, 2023 at 05:18:57PM +0100, Will Deacon wrote: > Hi Sibi, > > On Tue, Jan 17, 2023 at 02:28:29PM +0530, Sibi Sankar wrote: > > The memory region allocated using dma_alloc_attr with no kernel mapping > > attribute set would still be a part of the linear kernel map. Any access > > to this region by the application processor after assigning it to the > > remote Q6 will result in a XPU violation. Fix this by replacing the > > dynamically allocated memory region with a no-map carveout and unmap the > > modem metadata memory region before passing control to the remote Q6. > > The addition of the carveout and memunmap is required only on SoCs that > > mandate memory protection before transferring control to Q6, hence the > > driver falls back to dynamic memory allocation in the absence of the > > modem metadata carveout. > > [...] > > > remoteproc: qcom_q6v5_mss: Use a carveout to authenticate modem > > headers > > With this change now merged, am I ok to downgrade the arm64 > arch_dma_prep_coherent() back to a clean? > I think you can. If something breaks, we will fix it (without reverting) ;) - Mani > Thanks, > > Will