From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail-ej1-f50.google.com (mail-ej1-f50.google.com [209.85.218.50]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id C6F943CF97A for ; Tue, 25 Aug 2026 07:43:33 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.218.50 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1787643815; cv=none; b=AotPlXQZAUpFctCYtGkkTxEiCwAyIaYx+WrS/uL8Fi/Cy1k6oJcN7dSlu7H0kesNigggZa1YmyQi2IK/cf5MJLXjJdHtvdDRXWUi1IVS9OlqJOavv0UeFRBKm/+D34eeF5rHuvIMvG/2uZlUM/A8YzTo3WP/oLvxfqkStZKb1FE= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1787643815; c=relaxed/simple; bh=sLg8Ckk/hQ3NBVs8nL/RdwFJItCXw1At4jpUvXP85Gc=; h=Date:From:To:Cc:Subject:Message-ID:In-Reply-To:References: MIME-Version:Content-Type; b=nBGwqRsAx3HVgPMB1YIZUiYw0wQfSdNWpqinjca4FRydx0nSdIpGNm46Yjb+O4hXldB0muKTBOtSzGOerbB1LJmsdMd5X9J0jpZtntVVNinS3kXe2ObLp5UIqPvxUPBJJf7aRV3T6vcAgQQ1qnswsvwpwAu/BwLTdK8NzkthWic= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=gmail.com; spf=pass smtp.mailfrom=gmail.com; dkim=pass (2048-bit key) header.d=gmail.com header.i=@gmail.com header.b=gWJZ9te8; arc=none smtp.client-ip=209.85.218.50 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=gmail.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=gmail.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=gmail.com header.i=@gmail.com header.b="gWJZ9te8" Received: by mail-ej1-f50.google.com with SMTP id a640c23a62f3a-c214321dc32so860750466b.0 for ; Tue, 25 Aug 2026 00:43:33 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20251104; t=1787643812; x=1788248612; darn=vger.kernel.org; h=content-transfer-encoding:content-type:mime-version:references :in-reply-to:message-id:subject:cc:to:from:date:from:to:cc:subject :date:message-id:reply-to:content-type; bh=53BGkIX3YCtdYzektyoVFu0+GpJUKht1d2NbX/XeaVI=; b=gWJZ9te8J4edl5o0rlinczfhmd7/K7qHnv6x2x1sG8TrApK4meazHAymh4Li+euUky q86pykaLRU7ZpeN5cmKXTSS+b3A32FDA24UL0nzk4vWx7KLLEwRISsWeqi7FGkVVbKE4 l9bkwmBEhXTMv04T2ESX4s7EvwMq1L5ZwYpcOs3Tic5Jpw/ZnE4Ox/fBJ8iKw2sXnGD+ opa/TPH60fDQNQzpMSEI4+cbjgihYFtfOIVhN9POHLImbFPz2VtHgAX4xzBcpcMp4W6e 9LogdN+f7AdE/N0RcdawYLTporRMuFC84g8rN6X7NHceNfZWV2q+CrOlUOCKCfR/wNpi 9cZg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1787643812; x=1788248612; h=content-transfer-encoding:content-type:mime-version:references :in-reply-to:message-id:subject:cc:to:from:date:x-gm-gg :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to :content-type; bh=53BGkIX3YCtdYzektyoVFu0+GpJUKht1d2NbX/XeaVI=; b=N4e/sF6UP2mxSOPTXwkra4TJs7oT4kFbu74W/a7DRgdU+qRVTja08x7YrIg6WIpoZH 99GWF6IGqWYf2i+PzCIYb6dd5dqkkrA53MXILxXpVFGhdqxUqzjRTFNJD1VZGhAKZ+CE 0IiAdN9K1jujDD3vDGp4H5NUJHv9Y3pe4K83nNGi2aQ8JYhebLRH073ose+HSyUj6xlf TVy4N0cUaGOpFreuRO++Rpsk0uWdRMT5Dbwn3LrnQqt393qMvJbqTLUV2VTBh5W8DF5B 5r4uZErDHLxbwXC+KWDjP3qOD8wBUux/EC7yiCs+TUDIzdqN4PT7MnZt5xvwZTUaTAGA bliQ== X-Forwarded-Encrypted: i=1; AHgh+Rof1dCXC4SjrxPTKQk6MLWIOla6iBVkb7E5vN3L2bNLR8ryXyTO/PGpx/8C7gxvJ+MZhqatQl2/4R3/K6A=@vger.kernel.org X-Gm-Message-State: AFuF++kkEK0eMzOXZ2dPoTah/kKq6E3hcAFLyst8tcs+Gt9YFF3+Ahsm ivsGdbFVSFCyxUzB5HGepclE4P8RpNJlUYrjtu+tttMAPduB1xlzYTm8 X-Gm-Gg: AR+sD1244InCXh0x5NFZfYrn+4ShFZ7M2PR/oTkZjcNvrfkkN9Lc7izCMpNTEYGCiSm iG4kL4+3KcKgqIZKrmHggxj8CiS5yaXBy9sys4dR2qcxz3x90k2QGHvocjIzx9pyMpcH6I4rB+Z dDnEneBu3KLUk524zUq3mncRjjffk1WmhpRFQ6IrIccclb1mlQvFwi8ykzSeqmrdTBup+OUbmCp BPhwkpZx3PnmpJSMO3/Df5gOfq870KhivBRuLHb9ZBOd9//a8kJOzWf6BVGmi0+hCXZL9nCm3pf IcjfpvK+Rj/lMIZUQYFVbwQHAh5TwRkLmGdX6UxAza7JA6P6VU9NC0cHWTC6rczDs3/DVBINFfv f4Uln7qQyQu5Rusn7an/fnSn1JLRUGJEGi2TzqIKXEFAmO0xHA3BQQ7f2x4hQBDabdes8L1mC4M Fty9tcqqi52SsqtwJ7udl+FnwRPKeg7iVwpE+18SWKYhkT7txBnqnIRlaty1BZwo0kUwc= X-Received: by 2002:a17:907:72c5:b0:c24:d6f0:1223 with SMTP id a640c23a62f3a-c24d6f20633mr953718966b.12.1787643811777; Tue, 25 Aug 2026 00:43:31 -0700 (PDT) Received: from foxbook (bfk5.neoplus.adsl.tpnet.pl. [83.28.48.5]) by smtp.gmail.com with ESMTPSA id a640c23a62f3a-c24966f9cbcsm1852865066b.29.2026.08.25.00.43.30 (version=TLS1_2 cipher=AES128-SHA bits=128/128); Tue, 25 Aug 2026 00:43:31 -0700 (PDT) Date: Tue, 25 Aug 2026 09:43:27 +0200 From: Michal Pecio To: Wesley Cheng 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 Subject: Re: [PATCH 0/2] Add larger page size support for USB audio offload path Message-ID: <20260825094327.606072e9.michal.pecio@gmail.com> In-Reply-To: <20260824-16k_offload_v1_b4-v1-0-49a6be60ca30@oss.qualcomm.com> References: <20260824-16k_offload_v1_b4-v1-0-49a6be60ca30@oss.qualcomm.com> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit 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. > 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? 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