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 B195A351C02 for ; Wed, 26 Aug 2026 07:50:57 +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=1787730658; cv=none; b=ODNmfGuvZUYCZJLCyppzWbNc6BwDbPSHqAZoYFfd+Kxk/vKeN3i6+b4B69z/kUJdTPgk7vDut9ACB6KBFSIsCZMutRX7NvIV1G9CnBBVIsl4nUOPWsHtjM7S4SBmZ+u+VmVjqBNVNun/FRGWSxBNl507GP+5XZnYM4MiWD3dNt8= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1787730658; c=relaxed/simple; bh=AGLvPVl1km06Qd2SJp9Kfnk85aC+F3AEnFspKy5slLo=; h=Message-ID:Date:MIME-Version:Subject:From:To:Cc:References: In-Reply-To:Content-Type; b=UFOg8m0Veb+Vdc5RLkQ84v1EzzZFZ3du7L+tB6nlwD/vHwuIVyqz5PPiuT+aYw9V5QZUqyok+9O49h7SFIzJBlS/ZYWCofj8hIOj+4ddWa3UuSoli1erFU7xLuqqRV+c8v2JuY4gzofoUGMdULf62WtuI5MizYGTgKpBRzgUfzA= 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=P+iynFJQ; dkim=pass (2048-bit key) header.d=oss.qualcomm.com header.i=@oss.qualcomm.com header.b=YF/Ql8R8; 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="P+iynFJQ"; dkim=pass (2048-bit key) header.d=oss.qualcomm.com header.i=@oss.qualcomm.com header.b="YF/Ql8R8" Received: from pps.filterd (m0279865.ppops.net [127.0.0.1]) by mx0a-0031df01.pphosted.com (8.18.1.11/8.18.1.11) with ESMTP id 67Q6RmJ2683536 for ; Wed, 26 Aug 2026 07:50:57 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= GVQm7LcKqb3/uCDJ8rBRntP24G/9E0sp761G2/nC4u8=; b=P+iynFJQre2Kk7SU hkukfoif+fCGeK/xztYy5ZwmNTUcax5AIoxD9c1Nh2hLWmRVeQb2H2Bc/TG6DEOk d4q4EtX7HD4x5j7VMg/VC/cEJodadCNjK/T6Ct1pbVrFMSvG5A9TwEv+Wr2jNCWN eFN26s4659McxUBQiXcFM6Q6nbFggvU9nLqeGu1y2eGZjV8BjNboSXqQM35QOIW0 KpyhhdzkqhLB6yt1wBGQ0BynaIK8EdRd2A12YzdlCNnqqGFr/FZ34Z4opNyWUEYP 42OuzAMDUkkZnfZgQfjTj7T+2PD93W5ryvU5uJzTZmsqZPKv0tfV2SXE/VusRerO KREmeA== Received: from mail-pl1-f197.google.com (mail-pl1-f197.google.com [209.85.214.197]) by mx0a-0031df01.pphosted.com (PPS) with ESMTPS id 4g9fgxjsug-1 (version=TLSv1.3 cipher=TLS_AES_128_GCM_SHA256 bits=128 verify=NOT) for ; Wed, 26 Aug 2026 07:50:56 +0000 (GMT) Received: by mail-pl1-f197.google.com with SMTP id d9443c01a7336-2cfa55c9430so8973385ad.0 for ; Wed, 26 Aug 2026 00:50:56 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=oss.qualcomm.com; s=google; t=1787730656; x=1788335456; darn=vger.kernel.org; h=content-transfer-encoding:content-type:in-reply-to:content-language :references:cc:to:from:subject:user-agent:mime-version:date :message-id:from:to:cc:subject:date:message-id:reply-to:content-type; bh=GVQm7LcKqb3/uCDJ8rBRntP24G/9E0sp761G2/nC4u8=; b=YF/Ql8R81ee3a/Ypu9dwHoj/kz+GfMQZNwcKnlpi1oats23xcv7RRVS+DGyFuo94h7 +XdYKMn5AAVoMM8pX8wQSdvzuyUYY2fTTIZQBl60NdeAGC8wF68mqncf2n1j7pafGdh6 lQvoDo5SMmn1fPpl/F5SXz3dhFW5VcJFjfpVGOPzp3a57Y0XaNrlwfgJz+dxdWNyLLAr sAQEjEX0vzWGcNOJhOlXnDnZP6hmM6oU1LmEF2/etw75M6+1l9pXllAy2funub40NnaE 02cEDpkDfh5dYa7w5mvOiPw332xD9z2XRh44mixINWuAoYj90kOD4H1or3IVgbTEnWt1 HLVw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1787730656; x=1788335456; h=content-transfer-encoding:content-type:in-reply-to:content-language :references:cc:to:from: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=GVQm7LcKqb3/uCDJ8rBRntP24G/9E0sp761G2/nC4u8=; b=KXRMKFiwCiold/KDXzQHpH/oE46yItpTxm9GGrNTLs0jq0eJocLq5OAkcVrQiqDiU9 34EnQDP3vlKFhLRJQQCmoEXGNHPORqYTm4Hd+7YXjF4anudMjTITa8MAmP/anPn4qzVC U9a72+tWdNltq7QrXMZgTS4kl8H6mJ3ccYeXygIXECS9n1hDDz8zrmteXghCjVl95QpF 7RBt/i8Zl+2N393hY4Kyn6XopKt2RENCatuYoF2e6uBBJjQFrm2zzttcod4j9p2m+bOo h6Kg+Hy2hDnJbiKDZOLSdWVcXXr8ZL1MlOIr5s94guUNMS5cwWFl5S9qrzYJs0fRh/VQ 8rTw== X-Forwarded-Encrypted: i=1; AHgh+Rp0KG8Qo725+nWRN6muAsJTnnboTglqJPOMPGd0x/+AibK51mtsc2dEC36ytVxF0tvbIDU2hiWNQU++ThA=@vger.kernel.org X-Gm-Message-State: AFuF++lefjXxLZMHCTqOtSVD9mu9zuAWV5uA05lB7aTwypB0MUaFpzL+ vVqDiqs9h2U/rtLQFxdCq3TzakWtv9yBmi3hXJ3n4ElTvgR35j6peffk6Dv1BMfpfFsnP4I50Dk UJCjnXbuwRhL3RT5eSYThINW3XPHwTdFG6wXR2q5sLwKoltX5hnsi3rCUXniQQfkV7bk= X-Gm-Gg: AR+sD12tODdQJHj406xeohAYp7xbsZKuE8UbXZl3WfBgNqdNhvNfdlPHy+8LOMDz080 kj2SzGPXXVkF2AHl12SRPUCWIXb5iZcpqW40qbcfQ70wBBTv7fZy4LuCZPYekwg2CYmISXSOlZ5 jjsfMPgte81Gt/BWLHtc36dVbc0v0Ov3eH34cFFbrTY/aoprhI0MxLZVqAYeRWoCcNy32WI0CAB a7pOv/ftYp8zsDP8RL5qtILclvuoaACq/cAlznDil2kxNVg9jdKM6XYvaxNK9yqNlodr7jCxpPU 0GVt+3Bfrwxzq1vHwB7+fuZzzeslEjI3OJdof+pcswQJNXqTFimNtoT3TvG8iwXBLP5l5uuHvwA ZDRgCw/iF5jY9365fAaY/urGrx0SGlw== X-Received: by 2002:a17:903:2305:b0:2cf:afa5:b19a with SMTP id d9443c01a7336-2d707b7faacmr76688325ad.11.1787730656105; Wed, 26 Aug 2026 00:50:56 -0700 (PDT) X-Received: by 2002:a17:903:2305:b0:2cf:afa5:b19a with SMTP id d9443c01a7336-2d707b7faacmr76687195ad.11.1787730655464; Wed, 26 Aug 2026 00:50:55 -0700 (PDT) Received: from [192.168.1.26] ([75.80.180.230]) by smtp.gmail.com with ESMTPSA id 5a478bee46e88-3283d769d81sm6247033eec.13.2026.08.26.00.50.53 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Wed, 26 Aug 2026 00:50:54 -0700 (PDT) Message-ID: <0bf654f3-51c5-4555-8cdd-dc9d25dd9f78@oss.qualcomm.com> Date: Wed, 26 Aug 2026 00:50:53 -0700 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 0/2] Add larger page size support for USB audio offload path From: Wesley Cheng To: Michal Pecio Cc: Mathias Nyman , Greg Kroah-Hartman , Jaroslav Kysela , Takashi Iwai , linux-usb@vger.kernel.org, linux-kernel@vger.kernel.org, linux-sound@vger.kernel.org References: <20260824-16k_offload_v1_b4-v1-0-49a6be60ca30@oss.qualcomm.com> <20260825094327.606072e9.michal.pecio@gmail.com> <25ebe180-a620-4170-92f7-fda6c55a4129@oss.qualcomm.com> Content-Language: en-US In-Reply-To: <25ebe180-a620-4170-92f7-fda6c55a4129@oss.qualcomm.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit X-Authority-Analysis: v=2.4 cv=MqZiLWae c=1 sm=1 tr=0 ts=6a8e9ae0 cx=c_pps a=cmESyDAEBpBGqyK7t0alAg==:117 a=agQD+r7xwyS+FYqxhQjztw==:17 a=IkcTkHD0fZMA:10 a=Sv0fKeRqtYgA:10 a=s4-Qcg_JpJYA:10 a=VkNPw1HP01LnGYTKEx00:22 a=u7WPNUs3qKkmUXheDGA7:22 a=Um2Pa8k9VHT-vaBCBUpS:22 a=K85ttj8os38tJnul55EA:9 a=3ZKOabzyN94A:10 a=QEXdDO2ut3YA:10 a=1OuFwYUASf3TG4hYMiVC:22 X-Proofpoint-ORIG-GUID: NFoNRLCFBDMTJLjK5t1ttjwzjYJWZQK2 X-Proofpoint-Spam-Details-Enc: AW1haW4tMjYwODI2MDA2MyBTYWx0ZWRfXxAlUbYOVHpux W8KbBEyP7s9C6ZiIrCQC2U6TDRQCyyeAYrOwk3aoqtWfWIwVerxfCmoesVx2PdySXyi0+AZPCSO fR+FrLiSilEyjEm5s882M5r1KXbcKUJ6fFpHDYxehow5XkacLSP3cS1hyYrhdt0qV7jmI1jMRW7 ya7f22C/NeR7Cy/qCIi5CRJxKa/OB2/2paSRDoh/zIryp1FjdHNDNXX03nlCK9YHlrq8oDaPvLN zAeyMR7i+WBdyNtq4B80lijfGt2co/lOmovfqN+BG7W7XDwOE+8rsOdT27ymQ0sML+QsY8JgkuT GRQjHjDFACsMj92aRo590ILtPlfu1oEEL+q4QbdEZTqrF69rjgCKPblawsmu0p7GlWLlPdZXjOw 3NUx/ZgAJa5/UYvpYDmuu1li6yT8N3Xnkekqc2tpg2dgjxuuKxAjIhs+tihrq8JSWP0Y0ia6fg4 XhhPJD5Na/8hvnH+a9g== X-Proofpoint-GUID: NFoNRLCFBDMTJLjK5t1ttjwzjYJWZQK2 X-Proofpoint-Spam-Info: AW1haW4tMjYwODI2MDA2MyBTYWx0ZWRfX+10kbsnW4JCu HcrOayCkmBUIz2iU9k8ow3ASRcaeANzZI6h0eE4ojXQ/noHOGE7zm95TFrH+FgFe6rDo2/54BJU Sbo0ai0yqDcBWPEF1gE77mxdz2Uxz6Y= 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-26_02,2026-08-24_01,2025-10-01_01 X-Proofpoint-Spam-Details: rule=outbound_notspam policy=outbound score=0 spamscore=0 impostorscore=0 suspectscore=0 malwarescore=0 bulkscore=0 adultscore=0 clxscore=1015 phishscore=0 lowpriorityscore=0 priorityscore=1501 classifier=typeunknown authscore=0 authtc= authcc= route=outbound adjust=0 reason=mlx scancount=1 engine=8.22.0-2606150000 definitions=main-2608260063 On 8/25/2026 12:08 PM, Wesley Cheng wrote: > > > On 8/25/2026 12:43 AM, Michal Pecio wrote: >> Hi, >> >> On Mon, 24 Aug 2026 19:06:54 -0700, Wesley Cheng wrote: >>> On some environments, 16kB pages can be enabled from the Linux subsystem, >>> which manages the IOMMU mappings for the audio DSP within the system.  In >>> the current design, the following assumptions break when 16k pages are >>> utilized: >>>    1. xHCI ring size is equal to PAGE_SIZE >>>    2. Ring addresses start at the beginning of a page >> >> FYI it's worse than you think - xhci_ring_to_sgtable() returns wrong >> data and uses some allocation out of bounds on these systems. Quickly >> scanning through the patch I haven't noticed any changes there. >> > > Hi Michal, > > Thanks for the review. > > I had a tidbit that I tested that addressed an OOB condition, but as it > currently stands, that API should be working properly, if TRB segment size > == page size.  Hence, why I left it out as a change. > > The OOB condition I saw was that when 16k pages were used (w/o this > series), since specified rings can exist at a page offset, that offset > information is never populated, so we might be mapping the incorrect range. > > Regardless, I'll introduce that change in the next revision, since that's > information that shouldn't be left out. > >>> When the USB offload driver maps the rings (w/ the audio DSP SID), it is >>> set with a 16k granular, which is a problem, as several xHCI rings could >>> exist on the same page.  This is because the rings are currently allocated >>> from the segment_pool.  Hence, potentially mapping non USB audio related >>> rings into the region accessible by the audio DSP. >> >> If that's a security or reliability concern, perhaps each sideband >> instance should create its own DMA pool, as opposed to allocating every >> ring segment on a separate page? >> > > This is an interesting suggestion.  Let me take a look at it more and get > back to you. > Hi Michal, Thanks for this suggestion. I think it actually makes the overall design a lot better. So now that the sideband driver has its own segment pool (per sideband instance), we expect that any page allocations done from this pool is technically owned by the audio DSP. This allows us to still utilize 4k ring segments, while mapping the entire 16k page, so it helps conserve/optimize the memory allocations. I will do a bit more testing and review before submitting a new revision w/ these changes. BTW, I tried my best to see if I could re-use existing ring/segment alloc apis w/o modifying the arguments, but up to a certain point it was unavoidable. However, I think code re-use is better than having a, more or less the same, sideband API variant. Thanks Wesley Cheng > Thanks > Wesley Cheng > >> I suppose each 'xhci_ring' could keep a pointer to its segment pool and >> things would work for everyone, with very few changes. >> >> Regards, >> Michal >