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

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

[Ekansh Gupta]

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

Signed-off-by: Ekansh Gupta <ekansh.gupta@oss.qualcomm.com>
---
 arch/arm64/boot/dts/qcom/kaanapali.dtsi | 11 +++++++++++
 1 file changed, 11 insertions(+)

diff --git a/arch/arm64/boot/dts/qcom/kaanapali.dtsi b/arch/arm64/boot/dts/qcom/kaanapali.dtsi
index 131fd2a16c54..f79f7679de02 100644
--- a/arch/arm64/boot/dts/qcom/kaanapali.dtsi
+++ b/arch/arm64/boot/dts/qcom/kaanapali.dtsi
@@ -451,6 +451,14 @@ rmtfs_mem: rmtfs@d7c00000 {
 			qcom,client-id = <1>;
 			qcom,vmid = <QCOM_SCM_VMID_MSS_MSA>;
 		};
+
+		adsp_rpc_remote_heap_mem: adsp-rpc-remote-heap {
+			compatible = "shared-dma-pool";
+			alloc-ranges = <0x0 0x0 0x1 0x0>;
+			reusable;
+			alignment = <0x0 0x400000>;
+			size = <0x0 0x800000>;
+		};
 	};
 
 	smp2p-adsp {
@@ -2755,6 +2763,9 @@ fastrpc {
 					compatible = "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>;
 					#address-cells = <1>;
 					#size-cells = <0>;
 

---
base-commit: 5c4d4169604b335c38bbc79bc1fc03042981fc6f
change-id: 20260922-knp-rh-b090f9ec1572

Best regards,
-- 
Ekansh Gupta <ekansh.gupta@oss.qualcomm.com>

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

[sashiko-bot]

Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
- [High] dts: fatal hypervisor fault due to reusable CMA memory assignment
--

commit 00239a518b7712da455472149c4770b8452bb6e8
Author: Ekansh Gupta <ekansh.gupta@oss.qualcomm.com>

arm64: dts: qcom: kaanapali: 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 to the fastrpc node.

> diff --git a/arch/arm64/boot/dts/qcom/kaanapali.dtsi b/arch/arm64/boot/dts/qcom/kaanapali.dtsi
> index 131fd2a16c545..f79f7679de02a 100644
> --- a/arch/arm64/boot/dts/qcom/kaanapali.dtsi
> +++ b/arch/arm64/boot/dts/qcom/kaanapali.dtsi
> @@ -451,6 +451,14 @@ rmtfs_mem: rmtfs@d7c00000 {
>  			qcom,client-id = <1>;
>  			qcom,vmid = <QCOM_SCM_VMID_MSS_MSA>;
>  		};
> +
> +		adsp_rpc_remote_heap_mem: adsp-rpc-remote-heap {
> +			compatible = "shared-dma-pool";
> +			alloc-ranges = <0x0 0x0 0x1 0x0>;
> +			reusable;

[Severity: High]
Could marking this region as "reusable" lead to a fatal hypervisor fault?

By defining this with compatible = "shared-dma-pool" and "reusable", the
region is added to the Linux CMA allocator pool. This means the memory remains
in the kernel's linear map and is considered available for movable OS
allocations, such as the page cache.

> +			alignment = <0x0 0x400000>;
> +			size = <0x0 0x800000>;
> +		};
>  	};
>  
>  	smp2p-adsp {
> @@ -2755,6 +2763,9 @@ fastrpc {
>  					compatible = "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>;

Since the fastrpc node references the remote heap memory region and provides
"qcom,vmids", the fastrpc driver will unconditionally strip HLOS permissions
from the entire CMA region during probe.

Specifically, fastrpc_init_reserved_mem() calls qcom_scm_assign_mem() to
transfer ownership to the DSP, removing host OS access at the hypervisor
level. Because the memory is directly assigned away without being allocated
from the CMA pool via cma_alloc(), the kernel remains unaware it has lost
access.

Will any subsequent page reclaim, CMA allocation, or speculative CPU fetch
to the linear map of this region trigger an XPU violation and crash the
kernel?

Should this memory region use "no-map" instead of "reusable" to safely
remove it from the kernel's linear map before it is statically assigned
away from the host?

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

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20260922-knp-rh-v1-1-35e29b104809@oss.qualcomm.com?part=1