Re: [PATCH v3] arm64: dts: qcom: agatti: Add memory-region for audio PD

[sashiko-bot@kernel.org]

Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
- [High] The `adsp-rpc-remote-heap` region is configured as a `reusable` CMA pool without retaining HLOS (Host OS) access, leaving it mapped in the kernel's linear mapping and causing fatal stage-2 permission faults (XPU violations) upon speculative CPU access after ownership is transferred to the DSP.
--

--- Patch [1]: [PATCH v3] arm64: dts: qcom: agatti: Add memory-region for audio PD ---
commit 775c3c4fb571c7287ee665932e31677e111e34c6
Author: Vinayak Katoch <vinayak.katoch@oss.qualcomm.com>

arm64: dts: qcom: agatti: Add memory-region for audio PD

This commit reserves a memory region for audio PD dynamic loading and remote
heap requirements. It also adds the required VMID list for memory ownership
transfers.

Link: https://lore.kernel.org/r/20260807-agatti-audio-v2-1-3959b1ab8059@oss.qualcomm.com

> diff --git a/arch/arm64/boot/dts/qcom/agatti.dtsi b/arch/arm64/boot/dts/qcom/agatti.dtsi
> --- a/arch/arm64/boot/dts/qcom/agatti.dtsi
> +++ b/arch/arm64/boot/dts/qcom/agatti.dtsi
> @@ -381,6 +381,14 @@ rmtfs_mem: memory@89b01000 {
>  			qcom,client-id = <1>;
>  			qcom,vmid = <QCOM_SCM_VMID_MSS_MSA QCOM_SCM_VMID_NAV>;
>  		};
> +
> +		adsp_rpc_remote_heap_mem: adsp-rpc-remote-heap {
> +			compatible = "shared-dma-pool";
> +			alloc-ranges = <0x0 0x0 0x1 0x0>;
> +			reusable;

[Severity: High]
Since this reserved-memory node is defined with reusable rather than no-map,
it forces the region to be managed by CMA and mapped in the kernel's linear
mapping.

Could this expose the region to speculative CPU accesses, which might lead to
fatal stage-2 permission faults (XPU violations) after ownership is transferred
to the DSP?

> +			alignment = <0x0 0x400000>;
> +			size = <0x0 0x800000>;
> +		};
>  	};

[ ... ]

> @@ -2347,6 +2355,9 @@ fastrpc {
>  					compatible = "qcom,fastrpc";
>  					qcom,glink-channels = "fastrpcglink-apps-dsp";
>  					label = "adsp";
> +					memory-region = <&adsp_rpc_remote_heap_mem>;
> +					qcom,vmids = <QCOM_SCM_VMID_LPASS
> +						      QCOM_SCM_VMID_ADSP_HEAP>;

[Severity: High]
The qcom,vmids array explicitly omits QCOM_SCM_VMID_HLOS here.

This directs the fastrpc driver to completely revoke CPU access during the SCM
assignment. If the memory remains in the linear mapping (due to the reusable
property above), doesn't this create a fatal mismatch with the active stage-1
linear mapping, resulting in kernel panics upon speculative CPU data or
instruction fetches?

>  
>  					qcom,non-secure-domain;

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20260820-agatti-audio-v3-1-47337097ee53@oss.qualcomm.com?part=1