Re: [PATCH v1 2/4] arm64: dts: qcom: glymur: Make the ADSP remote heap no-map

[sashiko-bot@kernel.org]

Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
- [High] arm64/dma: Incomplete protection against speculative aborts for shared-dma-pool with no-map
--

commit 406984dd5e0c9e02f86eace82d9c1edf7af73157
Author: Jianping Li <jianping.li@oss.qualcomm.com>

arm64: dts: qcom: glymur: Make the ADSP remote heap no-map

This patch replaces the reusable property with no-map for the ADSP remote
heap to exclude it from the standard kernel memory mapping. This is intended
to prevent synchronous external aborts caused by kernel accesses after the
memory is handed over to the DSP.

Link: https://lore.kernel.org/all/20260701-glymur-audio-v1-1-2c3862d95a09@oss.qualcomm.com/

> diff --git a/arch/arm64/boot/dts/qcom/glymur.dtsi b/arch/arm64/boot/dts/qcom/glymur.dtsi
> index f04058d2e0891..ddbacc21f780e 100644
> --- a/arch/arm64/boot/dts/qcom/glymur.dtsi
> +++ b/arch/arm64/boot/dts/qcom/glymur.dtsi
> @@ -691,7 +691,7 @@ smem_mem: smem@ffe00000 {
>  		adsp_rpc_remote_heap_mem: adsp-rpc-remote-heap {
>  			compatible = "shared-dma-pool";
>  			alloc-ranges = <0x0 0x80000000 0x0 0x80000000>;
> -			reusable;
> +			no-map;

[Severity: High]
Does this fully protect against speculative aborts when combined with
the compatible = "shared-dma-pool" property?

Because the reusable property is removed but shared-dma-pool remains, the
reserved memory framework handles this node via rmem_dma_setup() in
kernel/dma/coherent.c. 

When the FastRPC driver probes and binds to this region via
of_reserved_mem_device_init(), it maps the entire 8MB physical region into
the kernel's vmalloc space:

kernel/dma/coherent.c:dma_init_coherent_memory() {
    ...
    mem_base = memremap(phys_addr, size, MEMREMAP_WC);
    ...
}

On the ARM architecture, MEMREMAP_WC creates a Normal Non-Cacheable mapping.
The architecture permits the CPU to perform speculative data reads on any
Normal memory, including Normal Non-Cacheable.

When the FastRPC driver allocates memory from this pool and assigns it to the
DSP via qcom_scm_assign_mem() (which revokes host access), this persistent
Normal memory mapping in vmalloc space remains intact.

Could speculative CPU reads through this vmalloc mapping still trigger the
exact same synchronous external aborts this patch aims to prevent?

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

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20261015071511.977-1-jianping.li@oss.qualcomm.com?part=2