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

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:

quoted

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