Re: [PATCH 0/2] Add larger page size support for USB audio offload path
From: Wesley Cheng
Date: Wed Aug 26 2026 - 16:02:04 EST
On 8/26/2026 4:44 AM, Mathias Nyman wrote:
On 8/26/26 13:25, Michal Pecio wrote:
On Wed, 26 Aug 2026 00:50:53 -0700, Wesley Cheng wrote:I have similar thoughts.
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.
The part about memory being "owned by the audio DSP" made me wonder
if it would be helpful to let offload drivers allocate their own memory
and then just dma_map() it for the xHC. No new rings would be allocated
for offloaded endpoints when they are enabled, we would point Endpoint
Context of the xHC to the sideband ring and leave ep->ring as NULL.
Offload drivers would have full control over memory allocation - size,
number of segments (it seems that qc-usb-audio only uses one out of two
allocated by xhci-hcd), alignment, anything else.
It would become impossible to offload an endpoint which is already
enabled, but is this an issue for anyone?
NULL ep->ring will cause oopses/panics when somebody submits URBs to
offloaded endpoints, but I think it wouldn't be a problem otherwise.
One idea would be to basically let sideband allocate the entire ring and set
ep->new_ring early. This would tell xhci_endpoint_init() that a ring exists and
a new one should not be allocated.
xhci ring allocation would need some refactoring to create helpers for sideband
to allocate and initialize all the other parts of the ring.
This is something that VTIO (xhci spec section 4.25) would also need.
There an endpoint can be handed over to a secondary DMA ID (second, new PCI BDF),
that the normal xhci driver can be excluded from with iommu.
VTIO use case is something like trusted VM accessing a secure usb storage device,
preventing regular OS running the xhci driver in another VM from touching it.
The secure VM needs to allocate and map the ring to this secondary PCI BDF
Interesting, so in both you're comments, it looks like when USB endpoints are offloaded, you want that to be fully isolated from the xHCI layer running on the Linux machine/proc. During the initial USB audio offload series submission, I think there was a point where we had a discussion where we decided to support both the Linux USB sound path alongside the offload path. This is because applications that are unaware of the offload path can still utilize the USB sound PCM devices.
In that situation, we're needing to map the region for both domains, and proper ring structures in xHCI, which is the current design.
However, with the current changes I have, it might address some of these points. I'll just give a quick highlight of them:
1. Currently, during xhci_sideband_register() I'm creating a sideband segment pool and saving that reference. (if we wanted to adjust this to your design, I think we can have the DMA segment pool allocations be handled by the offload client driver and passed into xhci-sideband) I think keeping the dma pool design just fits better with the overall xHCI ring helpers, and all you need is the device structure associated w/ the SID you're trying to map to in the offload driver.
2. xhci_sideband_add_endpoint() will populate the sideband entry for an USB endpoint. This is used as the trigger for which pool to fetch new_ring from in xhci_endpoint_init(). This pool will get propagated down to the normal xHCI ring segment allocator, and will fetch an entry from the dma pool.
I guess the only thing missing is a way to avoid the current xHCI APIs to avoid operating on rings that have been offloaded, but as stated earlier, at least in the USB audio offload use case, we'd still want the Linux environment to be able to operate on the ring. I'm just trying to see if we can come up with a way to accommodate the VTIO situation as well.
Thanks
Wesley Cheng