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
