Re: [PATCH 0/2] Add larger page size support for USB audio offload path

[Wesley Cheng <wesley.cheng@oss.qualcomm.com>]

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
>