Re: [RFC PATCH v2 1/2] dma: swiotlb: Centralize default pool initialization and sizing

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) <[email protected]>
> ---
>  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 <[email protected]>