Re: [RFC PATCH v2 1/2] dma: swiotlb: Centralize default pool initialization and sizing
From: Catalin Marinas
Date: Fri Aug 14 2026 - 12:15:51 EST
On Thu, Aug 13, 2026 at 03:55:20PM +0530, Aneesh Kumar K.V (Arm) wrote:
> The addressing_limited argument to swiotlb_init() no longer describes
> all the reasons why a default swiotlb pool may be needed. Confidential
> computing systems need a shared pool even without addressing limitations,
> while some systems need a smaller pool for bouncing unaligned kmalloc
> buffers.
>
> Replace the argument with SWIOTLB_INIT_ADDRESSING_LIMIT and
> SWIOTLB_INIT_CC_SHARED reason flags, and add swiotlb_should_init() to
> determine whether initialization is required for limited DMA addressing,
> confidential-computing shared DMA, unaligned kmalloc bouncing, or
> swiotlb=force.
>
> Have architectures report addressing-limit and confidential-computing
> requirements before swiotlb_init(). Mark CC pools shared before their
> memory attributes are updated, and keep both addressing-limited and
> CC-shared pools at their normal size instead of applying the reduced
> kmalloc-only sizing policy.
>
> Move the reduced kmalloc-bounce sizing policy from arm64 and RISC-V into
> the SWIOTLB core. This keeps architecture code responsible for reporting
> why a pool is needed while centralizing initialization and sizing
> decisions.
>
> Signed-off-by: Aneesh Kumar K.V (Arm) <aneesh.kumar@xxxxxxxxxx>
> ---
> arch/arm/mm/init.c | 6 +++-
> arch/arm64/mm/init.c | 18 ++++------
> arch/loongarch/kernel/setup.c | 2 +-
> arch/mips/cavium-octeon/dma-octeon.c | 2 +-
> arch/mips/loongson64/dma.c | 2 +-
> arch/mips/sibyte/common/dma.c | 2 +-
> arch/powerpc/kernel/dma-swiotlb.c | 4 ++-
> arch/powerpc/mm/mem.c | 15 +++++++-
> arch/powerpc/platforms/pseries/svm.c | 10 ------
> arch/powerpc/sysdev/fsl_pci.c | 1 +
> arch/riscv/mm/init.c | 18 +++-------
> arch/s390/mm/init.c | 2 +-
> arch/x86/include/asm/iommu.h | 2 ++
> arch/x86/kernel/amd_gart_64.c | 1 +
> arch/x86/kernel/pci-dma.c | 17 +++++----
> arch/x86/mm/mem_encrypt.c | 4 +++
> include/linux/swiotlb.h | 12 ++++---
> kernel/dma/swiotlb.c | 52 ++++++++++++++++++++++++----
> 18 files changed, 109 insertions(+), 61 deletions(-)
>
> diff --git a/arch/arm/mm/init.c b/arch/arm/mm/init.c
> index 0cc1bf04686d..aca97a4e5dcd 100644
> --- a/arch/arm/mm/init.c
> +++ b/arch/arm/mm/init.c
> @@ -223,7 +223,11 @@ static inline void poison_init_mem(void *s, size_t count)
> void __init arch_mm_preinit(void)
> {
> #ifdef CONFIG_ARM_LPAE
> - swiotlb_init(max_pfn > arm_dma_pfn_limit, SWIOTLB_VERBOSE);
> + unsigned int flags = SWIOTLB_VERBOSE;
> +
> + if (max_pfn > arm_dma_pfn_limit)
> + flags |= SWIOTLB_INIT_ADDRESSING_LIMIT;
> + swiotlb_init(flags);
> #endif
>
> #ifdef CONFIG_SA1111
> diff --git a/arch/arm64/mm/init.c b/arch/arm64/mm/init.c
> index e308a7cabd12..9f5b366d2086 100644
> --- a/arch/arm64/mm/init.c
> +++ b/arch/arm64/mm/init.c
> @@ -338,19 +338,15 @@ void __init arch_setup_zero_pages(void)
> void __init arch_mm_preinit(void)
> {
> unsigned int flags = SWIOTLB_VERBOSE;
> + /* pKVM uses restricted-dma-pool */
> + bool cc_guest = is_realm_world();
>
> - if (max_pfn <= PFN_DOWN(arm64_dma_phys_limit)) {
> - /*
> - * If no bouncing needed for ZONE_DMA, reduce the swiotlb
> - * buffer for kmalloc() bouncing to 1MB per 1GB of RAM.
> - */
> - unsigned long size =
> - DIV_ROUND_UP(memblock_phys_mem_size(), 1024);
> -
> - swiotlb_adjust_size(min(swiotlb_size_or_default(), size));
> - }
> + if (cc_guest)
> + flags |= SWIOTLB_INIT_CC_SHARED;
> + else if (max_pfn > PFN_DOWN(arm64_dma_phys_limit))
> + flags |= SWIOTLB_INIT_ADDRESSING_LIMIT;
>
> - swiotlb_init(true, flags);
> + swiotlb_init(flags);
I like the idea of more flags than the boolean for address limit.
However, depending on when such patch would go in (presumably on top of
what's currently in -next), we may not need the SWIOTLB_INIT_CC_SHARED
at all here just to remove it in the second patch. I think we have all
the information available already.
Other than that, it looks fine to me. If you repost at -rc1, hopefully
Sashiko will manage to apply it.
Reviewed-by: Catalin Marinas <catalin.marinas@xxxxxxx>