Re: [PATCH v6 0/8] dma: swiotlb: Centralize default pool policy and sizing

[Will Deacon <will@kernel.org>]

On Tue, Oct 06, 2026 at 11:42:54PM +0200, Marek Szyprowski wrote:
> On 24.09.2026 08:07, Aneesh Kumar K.V (Arm) wrote:
> > This series centralizes swiotlb default-pool selection and sizing, and
> > simplifies the initialization flags used to describe pool placement.
> >
> > The first patch replaces the addressing-limit argument with initialization
> > flags and introduces explicit policies for the different reasons a default
> > pool may be needed. Architectures now report DMA addressing constraints with
> > SWIOTLB_INIT_ADDRESSING_LIMIT, while the core selects the corresponding pool
> > policy.
> >
> > The second patch moves the reduced sizing used when the pool is needed only
> > for unaligned kmalloc bouncing from arm64 and RISC-V into the swiotlb core.
> >
> > The third patch centralizes swiotlb sizing for memory-encrypted systems. It
> > moves the existing x86 guest-sizing policy into the core. Host memory
> > encryption retains the normal pool size, and a shared default pool is not
> > selected solely for guest memory encryption when a restricted DMA pool is
> > present.
> >
> > The fourth patch removes SWIOTLB_ANY. Pool placement is derived directly from
> > SWIOTLB_INIT_ADDRESSING_LIMIT: pools required for limited DMA addressing are
> > allocated below the architecture's low address limit, while other pools may
> > be allocated anywhere in directly mapped memory. Xen continues to request a
> > pool explicitly with SWIOTLB_INIT_REMAP without imposing a low-address
> > constraint.
> 
> 
> I will give this patchset a chance in linux-next. If one feels that it still needs
> to be improved or sees any other reason why it shouldn't be merged, let me know
> asap.

I think the restricted-dma pool heuristic is horribly naive, so please drop
that part for now.

Will