From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mx0a-0031df01.pphosted.com (mx0a-0031df01.pphosted.com [205.220.168.131]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 1D6583E7174 for ; Thu, 13 Aug 2026 09:05:13 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=205.220.168.131 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1786611914; cv=none; b=r1U3a/qZ3b6nr178qUpRJfnNiJw5D3MuLxKKPHmgc3r3H14L5Ni7b32/cOMtd2wr/CheHokZ0dVsNSTxZUoBbTj545Egj1gGWIVKj2NV/AHmod3w1IHyXgvmoq6kCoXIx97y/ovi9V4wFDMHtHp8muNGZtvCHtcXmun0CUtYBG0= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1786611914; c=relaxed/simple; bh=T0L3tpfGXHSCFKA/MYT8j6LXFVeLB1uzDVoTGvUhPPU=; h=Message-ID:Date:MIME-Version:Subject:To:Cc:References:From: In-Reply-To:Content-Type; b=qfRJ1xJvxZTe/PLZYXyi/giPztM4KoBh3S9jF3mDqx3WCz1deZ37gA70AgJnmdxGQeaDPZA80aOV6Tb92jj5LY+/IP+f/+u+fA+9n9up2KYcvrcJXa1OlPu3Ze3jXqjufVgUUkk7Y59S5V6Z+XNqWWdLh8hBShfHo1jE2wZ+xlo= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=reject dis=none) header.from=oss.qualcomm.com; spf=pass smtp.mailfrom=oss.qualcomm.com; dkim=pass (2048-bit key) header.d=qualcomm.com header.i=@qualcomm.com header.b=kCR4KQ6Z; dkim=pass (2048-bit key) header.d=oss.qualcomm.com header.i=@oss.qualcomm.com header.b=Hi7ulfZ8; arc=none smtp.client-ip=205.220.168.131 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=reject dis=none) header.from=oss.qualcomm.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=oss.qualcomm.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=qualcomm.com header.i=@qualcomm.com header.b="kCR4KQ6Z"; dkim=pass (2048-bit key) header.d=oss.qualcomm.com header.i=@oss.qualcomm.com header.b="Hi7ulfZ8" Received: from pps.filterd (m0279862.ppops.net [127.0.0.1]) by mx0a-0031df01.pphosted.com (8.18.1.11/8.18.1.11) with ESMTP id 67D925ep1979257 for ; Thu, 13 Aug 2026 09:05:12 GMT DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=qualcomm.com; h= cc:content-transfer-encoding:content-type:date:from:in-reply-to :message-id:mime-version:references:subject:to; s=qcppdkim1; bh= T0L3tpfGXHSCFKA/MYT8j6LXFVeLB1uzDVoTGvUhPPU=; b=kCR4KQ6ZidoXLKJj 8bdoJIPbEp0Yh2NEQYDyh/SLC3I3ZiYLrsoHCeKQNI3hHIoqCjw/4q8QBUDNXqbY IkVz+53Lk+4NFz/WaiAZuLN9+mQYfxBEx5krDKFXuvaxB4rXzauBAYTOl6MUS1zT 5k/JZcfF21Bht016DV8KrqpnGHm3mmz/8Kvoxf0lTGfk/fOpyfTG0CrpMW0cf62x SLBY23IdL5waqJtl8t8oN3/I4Q8Ojc0A2hODFfIs5CZwkgULaGOOd/vuGwYyz6GS ngaqf8X+ojRzsV0zj6VC/W4yBENsoI4mAjr3fQoVwIrTeXkKaCnRC9ryD9UaX9Ty xlpqcg== Received: from mail-pg1-f198.google.com (mail-pg1-f198.google.com [209.85.215.198]) by mx0a-0031df01.pphosted.com (PPS) with ESMTPS id 4g143hsmn6-1 (version=TLSv1.3 cipher=TLS_AES_128_GCM_SHA256 bits=128 verify=NOT) for ; Thu, 13 Aug 2026 09:05:11 +0000 (GMT) Received: by mail-pg1-f198.google.com with SMTP id 41be03b00d2f7-ca124bf0189so608233a12.0 for ; Thu, 13 Aug 2026 02:05:11 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=oss.qualcomm.com; s=google; t=1786611911; x=1787216711; darn=vger.kernel.org; h=content-transfer-encoding:content-type:in-reply-to:from :content-language:references:cc:to:subject:user-agent:mime-version :date:message-id:from:to:cc:subject:date:message-id:reply-to :content-type; bh=T0L3tpfGXHSCFKA/MYT8j6LXFVeLB1uzDVoTGvUhPPU=; b=Hi7ulfZ8/KJgY87a2tTNAPfkookSstZP39cMCyUrexynnnDpLpBSLfV2SNzU7SOuph EwVd3sxrB92omNaUOgVguWHYQRLQKoBpBhIwQWVcuvjDBueD/Ca3uBaNC12+rNcMUtLQ cGmK2vI8WObQ+ECPozgTfqf5CVx7AhsUEbxWDpOELozQ/1saS6+rgxMfhaXh21PB58/V 6kYMOEqIscIzTKWPGkDJXD59+3qQsmM68FHUvXF9rTOHKj/eYX8JRioO8kTpvs2I6jum mjpgvcoPkj+OfkffgJINfp+wKPgkvAXt1t1onif87PPMvD2QHBnnZ+Q5AOIXB2fCUMuu DzDA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1786611911; x=1787216711; h=content-transfer-encoding:content-type:in-reply-to:from :content-language:references:cc:to:subject:user-agent:mime-version :date:message-id:x-gm-gg:x-gm-message-state:from:to:cc:subject:date :message-id:reply-to:content-type; bh=T0L3tpfGXHSCFKA/MYT8j6LXFVeLB1uzDVoTGvUhPPU=; b=Y4DEgyxDLIPvbR8MvtE5YjjMGoEVqE5ZLrSO7T2XV9oQON/CC9aGEno5zGNG1B9HiU wGesAbbxyBgqJ/p0vHZnqcQumiKPZoke7fvGie82K8FhCwCx/tEz8OoMjueWJvCTBwws J8c41a3ApGMJNVIjVTLDy0dy54RYqJJv9FZ8P9KLEmqxwYPpdTBKOv4hJ97a+ybJU751 dZuPjAYTW0KXf603BI5bC6b9ECLnAcna3g/1jpubSO02PeB+uiWi652FgZG4xAuS8NBb SY/ZNtsSxng0ii4cJfwj99e6x63+jFVwWX64xLDjiyxzn11Xy/Fvu88E2aoTldV+uOZJ 9BVQ== X-Forwarded-Encrypted: i=1; AHgh+Ro/idno4VFR/KxyIjKiFLImM6apEkTnO35wMhX/tmfhRMHT1gmuSFG0ShkHkykuRNRj0TbW0JkwL8TGnnI=@vger.kernel.org X-Gm-Message-State: AOJu0Yw5KHC5QheL5NGSRXcSe8RwME9UNFbVsWSPqOIM+LhWFKtQ5YS5 M7O7/Vq33zJVhwMmJYtXxBfk71Rivg3SQcShsC/KYstmoBarSJeBnP3aE/eh7JJAM5f9rv2uiR0 sYWj8Xq5kwQiA/u55wa4Oa5MwNYOVT+9O8It0a/rWzlnynW2FLYOnuTrlOiqJN8odnH4= X-Gm-Gg: AR+sD114FQTcNcoy2FZ6IE+eHPH/T9+7oBbV8HW8Scf+lUe7dk0QA6DWewgvDzd0fnU dHyuDwoIvou+U5dmjLZr10yd+glCOBmerIKPXWD/L3N/lcStbmazAybTdYQfUqJn5WtbJMTFayd f/U4OOT0Hf90gIxp7eAdj9ATFGfiEg8XIkiwmeOdSm/RLRA0Gu/Gn61A+behJjrPTLCjJC/9UJ8 eMrLSlcNBMPFVml55JD+16tbmPpuvHDJtUcBlRJJxV8Qz5CDGERMF7jcB2XY4c4ohB7dRjlgTMR gmylVI1182xoXCOPEfr8FQ6/PzALwuFnOwWkOIDcmwgQijFfvOLVoR4nCSBm8P8tLY6dELXF5By heYHCPRY4+kEtqmz42p/3Yil3tgSqRLWzcA== X-Received: by 2002:a17:90b:52d0:b0:387:d5bd:622f with SMTP id 98e67ed59e1d1-3931f971fa1mr1668340a91.18.1786611910967; Thu, 13 Aug 2026 02:05:10 -0700 (PDT) X-Received: by 2002:a17:90b:52d0:b0:387:d5bd:622f with SMTP id 98e67ed59e1d1-3931f971fa1mr1668311a91.18.1786611910433; Thu, 13 Aug 2026 02:05:10 -0700 (PDT) Received: from [10.218.31.237] ([202.46.22.19]) by smtp.gmail.com with ESMTPSA id 98e67ed59e1d1-3931f44de1esm2177013a91.13.2026.08.13.02.05.03 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Thu, 13 Aug 2026 02:05:09 -0700 (PDT) Message-ID: <63bae39b-1256-4e19-a9de-840d8752ec69@oss.qualcomm.com> Date: Thu, 13 Aug 2026 14:35:01 +0530 Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH 2/2] net: wwan: qcom_bam_dmux: Alloc RX buffers as a single coherent block To: Stephan Gerhold Cc: Stephan Gerhold , Andrew Lunn , "David S. Miller" , Eric Dumazet , Jakub Kicinski , Paolo Abeni , Rob Herring , Krzysztof Kozlowski , Conor Dooley , Loic Poulain , Sergey Ryazanov , Johannes Berg , linux-arm-msm@vger.kernel.org, netdev@vger.kernel.org, devicetree@vger.kernel.org, linux-kernel@vger.kernel.org, chris.lew@oss.qualcomm.com, Deepak Kumar Singh References: <20260714-qcom-bam-dmux-vmid-ext-v1-0-3f29da7cca76@oss.qualcomm.com> <20260714-qcom-bam-dmux-vmid-ext-v1-2-3f29da7cca76@oss.qualcomm.com> Content-Language: en-US From: Vishnu Santhosh In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Authority-Analysis: v=2.4 cv=R5oz39RX c=1 sm=1 tr=0 ts=6a7d88c7 cx=c_pps a=Qgeoaf8Lrialg5Z894R3/Q==:117 a=fChuTYTh2wq5r3m49p7fHw==:17 a=IkcTkHD0fZMA:10 a=Sv0fKeRqtYgA:10 a=s4-Qcg_JpJYA:10 a=VkNPw1HP01LnGYTKEx00:22 a=u7WPNUs3qKkmUXheDGA7:22 a=_K5XuSEh1TEqbUxoQ0s3:22 a=EUspDBNiAAAA:8 a=J4aCkolXD37Z9lCRw_gA:9 a=QEXdDO2ut3YA:10 a=x9snwWr2DeNwDh03kgHS:22 X-Proofpoint-Spam-Details-Enc: AW1haW4tMjYwODEzMDA2MiBTYWx0ZWRfX/4P/YGoC66WS vri+l/uGudeZmNzFqsHS9tmGdRNKf8V/IZYY81iHRsHaHqZeMk0DWSc5JAJ/49mBCEvJbW8uzCy 1EEaPvroKtkkTVWxCXGgMlx3nLTCOVrn2iFtbzr+OAnn2YVRYmfEzrW2REsMPWlSyhyugr5yLB3 YW2Ugm739foRQ4hWnY5frLTutHLLXZYjwx+Fk7QRspgziXBzN4FxFbfcNfpMXbUXgkyI6YMvfDp rW2XtkwBcXZLvdIWvpSs2ib5au6vbkPB+J2kioI7mYvwXr6izRh9X0/Q0kL8aa4UU3Vn7oxh8sx L5MceF9sZevl4TXn5YnxB9PmC4LhII1nrOTaSd9pi7V3f5GoHWLv+P9fzAsUR2WJcAmF37eFgJ7 E9Wz6aWrYlvUu/sLiM6Quppu5AoKwNA3Bi3a4EKgF2OFZbd8oktw2K6C8OkShQs5zVUlDZDgVOh UbgEpjwPtbCIMUgFx7A== X-Proofpoint-GUID: 2w6XCYJuL0qG2-CRBUFTc571sy2OaLvG X-Proofpoint-Spam-Info: AW1haW4tMjYwODEzMDA2MiBTYWx0ZWRfXwFc46HbEliYE uISIEG9OWq3nHY92jYTCT3cJUQK2YNQOsSb0GZ8zzrzMXt5GuJDin0en/YNVNM+S4F/BzoazpZo PlJwhK1vjkj1q87R39Qu5Wf2sGCz0GY= X-Proofpoint-ORIG-GUID: 2w6XCYJuL0qG2-CRBUFTc571sy2OaLvG X-Proofpoint-Virus-Version: vendor=baseguard engine=ICAP:2.0.293,Aquarius:18.0.1176,Hydra:6.1.134,FMLib:17.12.100.49 definitions=2026-08-13_03,2026-08-12_01,2025-10-01_01 X-Proofpoint-Spam-Details: rule=outbound_notspam policy=outbound score=0 malwarescore=0 suspectscore=0 adultscore=0 clxscore=1015 priorityscore=1501 impostorscore=0 phishscore=0 lowpriorityscore=0 spamscore=0 bulkscore=0 classifier=typeunknown authscore=0 authtc= authcc= route=outbound adjust=0 reason=mlx scancount=1 engine=8.22.0-2606150000 definitions=main-2608130062 On 24-07-2026 03:04 pm, Stephan Gerhold wrote: > On Fri, Jul 24, 2026 at 10:16:31AM +0530, Vishnu Santhosh wrote: >> On 14-07-2026 01:05 pm, Stephan Gerhold wrote: >>> On Tue, Jul 14, 2026 at 11:02:32AM +0530, Vishnu Santhosh wrote: >>>> On Qualcomm SoCs where the modem (e.g. the mDSP on Shikra, VMID 43 / >>>> NAV) is the AXI master for BAM-DMUX RX transfers and the XPU enforces >>>> per-region access control, each individually DMA-mapped RX buffer >>>> requires its own XPU resource group (RG). With ~16 RGs available, the >>>> 32 per-buffer dma_map_single() calls exhaust the table and the first >>>> inbound transfer faults with an XPU violation. >>>> >>>> BAM-DMUX is a singleton (exactly one instance per SoC), so the >>>> destination VMID does not need to be a DT property; it is looked up >>>> from the compatible string's match data instead. Add struct >>>> bam_dmux_data with a single vmid field, and a shikra_data instance >>>> hardcoding QCOM_SCM_VMID_NAV for qcom,shikra-bam-dmux. >>>> >>>> When match data is present, allocate all BAM_DMUX_NUM_SKB RX buffers as >>>> a single contiguous dma_alloc_coherent() block and SCM-assign that >>>> block to HLOS plus the VMID once at probe. This reduces RG consumption >>>> from 32 to 1. The block is never reclaimed across a modem power cycle >>>> (bam_dmux_power_off() does not touch it), so the probe-time assignment >>>> covers every subsequent restart without re-assigning or reclaiming. It >>>> is reclaimed to HLOS only once, at remove or on a probe error, and if >>>> that reclaim fails it is leaked rather than returned to the page >>>> allocator. >>>> >>>> Each rx_skbs[] slot is pre-assigned its virtual and DMA address from >>>> the block, so no per-buffer mapping is needed at power-on. Because the >>>> coherent block is not page-backed, received payload is copied into a >>>> regular netdev skb before handoff to the network stack; this is an >>>> unavoidable extra copy on the XPU-enforced RX path. >>>> >>>> Platforms without match data are unaffected: rx_virt stays NULL, no >>>> coherent memory is allocated, and the per-buffer dma_map_single() path >>>> is unchanged. >>>> >>>> Co-developed-by: Deepak Kumar Singh >>>> Signed-off-by: Deepak Kumar Singh >>>> Signed-off-by: Vishnu Santhosh >>> So how do you handle TX buffers? Right now, they are just passed on from >>> the net subsystem. There can be up to 32 TX buffers in progress as well. >>> >>> Overall, I have mixed feelings about this patch. It looks reasonably >>> simple, but fundamentally I don't understand why we need to go back to >>> the old days of implementing protection using a highly limited MPU (in >>> your case: the xPU). >>> >>> Why does the setup of BAM-DMUX differ e.g. from the setup for the crypto >>> engine? Crypto is also using bam-dma, but it avoids this inflexibility >>> by making use of the &apps_smmu. Is BAM-DMUX not covered by the SMMU? Or >>> did you just decide to bypass the SMMU in this case? (If so: Why?) >> I checked with secure systems team on this. Crypto BAM is >> behind apps_smmu, so protection is enforced through the SMMU's Stage-2 >> page tables. >> >> A2 BAM (used by BAM-DMUX) is present in secure domain and does not >> support Stage-2 translation on this SoC, and there is no IOMMU domain >> that can be attached to it. The only protection mechanism available is >> the xPU. >> > Thanks for investigating this! > > So is this a hardware limitation or something you could change with a > firmware update? Could you move the A2 BAM out of the secure domain and > protect it via the IOMMU instead of the xPU mechanism? The other modern > platforms with IPA do not have this limitation, they can use the IOMMU > for this. > > We can try to support the xPU protection mechanism in the BAM-DMUX > driver, but it's pretty bad from a performance and memory usage point of > view if you need to copy buffers around multiple times. So if you have > some way to change this in the firmware (and there is still time to do > so before production boards ship), I would strongly recommend to > investigate that. > > Thanks, > Stephan Based on what we confirmed with the Secure Systems team, this is a limitation of the current Shikra platform rather than something that can be addressed through a firmware-only update. The A2 BAM used by BAM-DMUX is not connected to an SMMU/IOMMU domain on Shikra, which means Stage-2 translation is not available for this path. As a result, it is not possible to move this path behind an IOMMU. Modern IPA-based platforms differ because their data paths are physically routed through SMMU interfaces and therefore do not rely on VMID/xPU ownership assignment for this type of access control. On Shikra, the A2 BAM path is protected using the xPU3 VM-based access-control model, where DDR memory access is restricted and granted through the request-based Hypervisor VM assignment framework. In contrast, older targets relied on the earlier xPU2 resource-sharing model, in which modem access did not require this type of explicit VM ownership configuration. This architectural difference explains why the issue does not occur on those older platforms. So, for this path on Shikra, SCM-driven VMID assignment remains the only practical solution. Thanks, Vishnu