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. Applied to dma-mapping-for-next. Best regards -- Marek Szyprowski, PhD Samsung R&D Institute Poland
