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

[sashiko-bot@kernel.org]

Thank you for your contribution! Sashiko AI review found 2 potential issue(s) to consider:

New issues:
- [High] The `adsp-rpc-remote-heap` memory region uses `reusable` without retaining HLOS access, leading to fatal hypervisor faults due to speculative execution.

Pre-existing issues:
- [High] The fastrpc driver does not restore memory ownership to HLOS before freeing the remote_heap, causing a fatal XPU violation on memory reuse.
--

commit 39381f5de37bbf0f0366047bc842de4cb219a1ec
Author: Vinayak Katoch <vinayak.katoch@oss.qualcomm.com>

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

Reserve memory region for audio PD dynamic loading and remote heap
requirements. Add the required VMID list for memory ownership
transfers.

> diff --git a/arch/arm64/boot/dts/qcom/glymur.dtsi b/arch/arm64/boot/dts/qcom/glymur.dtsi
> index 20b49af7298e9..f403f542aa00c 100644
> --- a/arch/arm64/boot/dts/qcom/glymur.dtsi
> +++ b/arch/arm64/boot/dts/qcom/glymur.dtsi
[ ... ]
> @@ -663,6 +664,14 @@ smem_mem: smem@ffe00000 {
>  			hwlocks = <&tcsr_mutex 3>;
>  			no-map;
>  		};
> +
> +		adsp_rpc_remote_heap_mem: adsp-rpc-remote-heap {
> +			compatible = "shared-dma-pool";
> +			alloc-ranges = <0x0 0x80000000 0x0 0x80000000>;
> +			reusable;
> +			alignment = <0x0 0x400000>;
> +			size = <0x0 0x800000>;
> +		};
>  	};
>  
>  	smp2p-adsp {
[ ... ]
> @@ -3845,6 +3854,9 @@ fastrpc {
>  					compatible = "qcom,glymur-fastrpc", "qcom,kaanapali-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]
Since this memory region is defined with the reusable property, it is placed
in the CMA pool and the kernel's linear mapping. When the fastrpc driver
allocates this memory and assigns it, it strips QCOM_SCM_VMID_HLOS because it
is missing from this qcom,vmids array.

Because the pages remain mapped in the kernel's linear mapping, will any
speculative CPU fetch to these addresses immediately trigger a hypervisor
protection fault?

Should this region use no-map instead, or should QCOM_SCM_VMID_HLOS be
included in the qcom,vmids array?

[Severity: High]
This is a pre-existing issue, but I noticed a related problem in the fastrpc
driver when handling this remote heap memory.

When the driver frees the remote heap during channel teardown or module
removal, it returns the buffer to the CMA pool:

drivers/misc/fastrpc.c:fastrpc_rpmsg_remove() {
        ...
        if (cctx->remote_heap)
                fastrpc_buf_free(cctx->remote_heap);
        ...
}

Does this free the memory without restoring ownership to QCOM_SCM_VMID_HLOS?

If so, could this cause an XPU/SMMU violation when the CMA allocator
subsequently reuses these freed pages for another kernel component?

>  					#address-cells = <1>;
>  					#size-cells = <0>;

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20260701-glymur-audio-v1-1-2c3862d95a09@oss.qualcomm.com?part=1