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

[Wesley Cheng]

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.

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