Re: [PATCH v6 6/8] dma: swiotlb: Centralize memory-encryption pool sizing

[Will Deacon <will@kernel.org>]

On Thu, Sep 24, 2026 at 11:37:54AM +0530, Aneesh Kumar K.V (Arm) wrote:
> Memory-encrypted guests use shared or unencrypted memory for DMA and may
> route all DMA through SWIOTLB. The default pool can therefore be too
> small for I/O-intensive workloads.
> 
> Move the existing x86 guest-sizing policy into the SWIOTLB core. For
> SWIOTLB_POOL_CC_GUEST, size the pool to 6% of guest memory, clamped
> between the normal default and 1 GiB. Preserve an explicit swiotlb=
> size.
> 
> Host memory encryption still selects a normal-sized shared pool and
> does not use the guest-sizing policy.
> 
> A restricted DMA pool already provides shared bounce buffers for its
> devices. Record its presence during reserved-memory initialization and
> do not select the confidential-guest default-pool policy solely because
> guest memory encryption is active.
> 
> Reviewed-by: Catalin Marinas <catalin.marinas@arm.com>
> Cc: Dave Hansen <dave.hansen@linux.intel.com>
> Cc: Andy Lutomirski <luto@kernel.org>
> Cc: Peter Zijlstra <peterz@infradead.org>
> Cc: Thomas Gleixner <tglx@kernel.org>
> Cc: Ingo Molnar <mingo@redhat.com>
> Cc: Borislav Petkov <bp@alien8.de>
> Cc: x86@kernel.org
> Cc: "H. Peter Anvin" <hpa@zytor.com>
> Cc: Marek Szyprowski <m.szyprowski@samsung.com>
> Cc: Robin Murphy <robin.murphy@arm.com>
> Signed-off-by: Aneesh Kumar K.V (Arm) <aneesh.kumar@kernel.org>
> ---
>  arch/x86/mm/mem_encrypt.c | 24 ------------------------
>  kernel/dma/swiotlb.c      | 27 +++++++++++++++++++++++++--
>  2 files changed, 25 insertions(+), 26 deletions(-)
> 
> diff --git a/arch/x86/mm/mem_encrypt.c b/arch/x86/mm/mem_encrypt.c
> index 95bae74fdab2..912f22ca838f 100644
> --- a/arch/x86/mm/mem_encrypt.c
> +++ b/arch/x86/mm/mem_encrypt.c
> @@ -101,9 +101,6 @@ void __init mem_encrypt_init(void)
>  
>  void __init mem_encrypt_setup_arch(void)
>  {
> -	phys_addr_t total_mem = memblock_phys_mem_size();
> -	unsigned long size;
> -
>  	/*
>  	 * Do RMP table fixups after the e820 tables have been setup by
>  	 * e820__memory_setup().
> @@ -114,27 +111,6 @@ void __init mem_encrypt_setup_arch(void)
>  	if (!cc_platform_has(CC_ATTR_GUEST_MEM_ENCRYPT))
>  		return;
>  
> -	/*
> -	 * For SEV and TDX, all DMA has to occur via shared/unencrypted pages.
> -	 * Kernel uses SWIOTLB to make this happen without changing device
> -	 * drivers. However, depending on the workload being run, the
> -	 * default 64MB of SWIOTLB may not be enough and SWIOTLB may
> -	 * run out of buffers for DMA, resulting in I/O errors and/or
> -	 * performance degradation especially with high I/O workloads.
> -	 *
> -	 * Adjust the default size of SWIOTLB using a percentage of guest
> -	 * memory for SWIOTLB buffers. Also, as the SWIOTLB bounce buffer
> -	 * memory is allocated from low memory, ensure that the adjusted size
> -	 * is within the limits of low available memory.
> -	 *
> -	 * The percentage of guest memory used here for SWIOTLB buffers
> -	 * is more of an approximation of the static adjustment which
> -	 * 64MB for <1G, and ~128M to 256M for 1G-to-4G, i.e., the 6%
> -	 */
> -	size = total_mem * 6 / 100;
> -	size = clamp_val(size, IO_TLB_DEFAULT_SIZE, SZ_1G);
> -	swiotlb_adjust_size(size);
> -
>  	/* Set restricted memory access for virtio. */
>  	virtio_set_mem_acc_cb(virtio_require_restricted_mem_acc);
>  }
> diff --git a/kernel/dma/swiotlb.c b/kernel/dma/swiotlb.c
> index 75ee63cd354e..e626cca63ad1 100644
> --- a/kernel/dma/swiotlb.c
> +++ b/kernel/dma/swiotlb.c
> @@ -33,6 +33,7 @@
>  #include <linux/kmsan-checks.h>
>  #include <linux/iommu-helper.h>
>  #include <linux/init.h>
> +#include <linux/math64.h>
>  #include <linux/memblock.h>
>  #include <linux/mm.h>
>  #include <linux/pfn.h>
> @@ -80,6 +81,7 @@ struct io_tlb_slot {
>  
>  static bool swiotlb_force_bounce;
>  static bool swiotlb_force_disable;
> +static bool restricted_dma_pool_present __initdata;
>  
>  enum swiotlb_pool_policy {
>  	SWIOTLB_POOL_NONE,
> @@ -478,7 +480,25 @@ swiotlb_adjust_pool_size(enum swiotlb_pool_policy policy)
>  		size = min(swiotlb_default_pool_size(), size);
>  		break;
>  	case SWIOTLB_POOL_CC_GUEST:
> -		return;
> +		/*
> +		 * For SEV and TDX and CCA, all DMA has to occur via
> +		 * shared/unencrypted pages. Kernel uses SWIOTLB to make this
> +		 * happen without changing device drivers. However, depending on
> +		 * the workload being run, the default 64MB of SWIOTLB may not be
> +		 * enough and SWIOTLB may run out of buffers for DMA, resulting in
> +		 * I/O errors and/or performance degradation especially with high
> +		 * I/O workloads.
> +		 *
> +		 * Adjust the default size of SWIOTLB using a percentage of guest
> +		 * memory for SWIOTLB buffers.
> +		 *
> +		 * The percentage of guest memory used here for SWIOTLB buffers is
> +		 * more of an approximation of the static adjustment which 64MB for
> +		 * <1G, and ~128M to 256M for 1G-to-4G, i.e., the 6%
> +		 */
> +		size = div_u64((u64)memblock_phys_mem_size() * 6, 100);
> +		size = clamp_val(size, IO_TLB_DEFAULT_SIZE, SZ_1G);
> +		break;
>  	case SWIOTLB_POOL_NONE:
>  		WARN(true, "Cannot adjust SWIOTLB size without a pool\n");
>  		return;
> @@ -496,7 +516,8 @@ swiotlb_select_pool_policy(unsigned int flags)
>  	if (swiotlb_force_disable)
>  		return SWIOTLB_POOL_NONE;
>  
> -	if (cc_platform_has(CC_ATTR_GUEST_MEM_ENCRYPT))
> +	if (cc_platform_has(CC_ATTR_GUEST_MEM_ENCRYPT) &&
> +	    !restricted_dma_pool_present)
>  		return SWIOTLB_POOL_CC_GUEST;

I think this check on the restricted DMA pool is too general -- the pool
could be tied to a specific DMA-capable peripheral and so treating its
presence as a global property isn't right.

Will