Linux-ARM-Kernel Archive on lore.kernel.org
 help / color / mirror / Atom feed
From: Catalin Marinas <catalin.marinas@arm.com>
To: "Aneesh Kumar K.V (Arm)" <aneesh.kumar@kernel.org>
Cc: iommu@lists.linux.dev, linux-arm-kernel@lists.infradead.org,
	linux-kernel@vger.kernel.org, linux-coco@lists.linux.dev,
	Robin Murphy <robin.murphy@arm.com>,
	Marek Szyprowski <m.szyprowski@samsung.com>,
	Will Deacon <will@kernel.org>, Marc Zyngier <maz@kernel.org>,
	Steven Price <steven.price@arm.com>,
	Suzuki K Poulose <Suzuki.Poulose@arm.com>,
	Jiri Pirko <jiri@resnulli.us>, Jason Gunthorpe <jgg@ziepe.ca>,
	Mostafa Saleh <smostafa@google.com>,
	Petr Tesarik <ptesarik@suse.com>,
	Alexey Kardashevskiy <aik@amd.com>,
	Xu Yilun <yilun.xu@linux.intel.com>,
	linuxppc-dev@lists.ozlabs.org, linux-s390@vger.kernel.org,
	Madhavan Srinivasan <maddy@linux.ibm.com>,
	Michael Ellerman <mpe@ellerman.id.au>,
	Nicholas Piggin <npiggin@gmail.com>,
	Christophe Leroy <chleroy@kernel.org>,
	Alexander Gordeev <agordeev@linux.ibm.com>,
	Gerald Schaefer <gerald.schaefer@linux.ibm.com>,
	Heiko Carstens <hca@linux.ibm.com>,
	Vasily Gorbik <gor@linux.ibm.com>,
	Christian Borntraeger <borntraeger@linux.ibm.com>,
	Sven Schnelle <svens@linux.ibm.com>,
	x86@kernel.org
Subject: Re: [RFC PATCH v2 2/2] dma: swiotlb: Initialize and size shared default pools for memory encryption
Date: Fri, 14 Aug 2026 18:34:39 +0100	[thread overview]
Message-ID: <an9RrwoaAsqJQ2vN@arm.com> (raw)
In-Reply-To: <20260813102521.1367737-3-aneesh.kumar@kernel.org>

On Thu, Aug 13, 2026 at 03:55:21PM +0530, Aneesh Kumar K.V (Arm) wrote:
> diff --git a/arch/arm64/mm/init.c b/arch/arm64/mm/init.c
> index 9f5b366d2086..c3188ca878f3 100644
> --- a/arch/arm64/mm/init.c
> +++ b/arch/arm64/mm/init.c
> @@ -338,12 +338,8 @@ 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 (cc_guest)
> -		flags |= SWIOTLB_INIT_CC_SHARED;
> -	else if (max_pfn > PFN_DOWN(arm64_dma_phys_limit))
> +	if (max_pfn > PFN_DOWN(arm64_dma_phys_limit))
>  		flags |= SWIOTLB_INIT_ADDRESSING_LIMIT;
>  
>  	swiotlb_init(flags);

This looks fine. As I mentioned on patch 1, we might as well move this
hunk over there and avoid the flag definition.

> @@ -102,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().
> @@ -112,33 +108,9 @@ void __init mem_encrypt_setup_arch(void)
>  	if (cc_platform_has(CC_ATTR_HOST_SEV_SNP))
>  		snp_fixup_e820_tables();
>  
> -	if (cc_platform_has(CC_ATTR_MEM_ENCRYPT))
> -		x86_swiotlb_flags |= SWIOTLB_INIT_CC_SHARED;
> -
>  	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);
>  }

Credit to claude, it noticed a slight change in behaviour for x86 w.r.t.
the crash kernel reservation. crash_low_size_default() reads the swiotlb
size but the resizing now happens after arch_reserve_crashkernel().
Maybe not an issue.

Alternatively, we could build the sizing logic into
swiotlb_size_or_default() but I haven't checked whether we have the
right information when this function is called.

> @@ -382,12 +374,54 @@ static void __init *swiotlb_memblock_alloc(unsigned long nslabs,
>  	return tlb;
>  }
>  
> +static void __init swiotlb_adjust_cc_attributes(void)
> +{
> +	unsigned long size;
> +	phys_addr_t total_mem = memblock_phys_mem_size();
> +
> +	/* Do not resize for host memory encryption. */
> +	if (!cc_platform_has(CC_ATTR_GUEST_MEM_ENCRYPT))
> +		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. 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);
> +
> +	if (!IS_ENABLED(CONFIG_SWIOTLB_DYNAMIC))
> +		pr_info("Consider enabling CONFIG_SWIOTLB_DYNAMIC for memory-encrypted systems\n");

I agree with Michael, let's drop this pr_info().

> +}
> +
>  static bool __init swiotlb_kmalloc_needs_bounce(void)
>  {
>  	return IS_ENABLED(CONFIG_DMA_BOUNCE_UNALIGNED_KMALLOC) &&
>  	       (dma_get_cache_alignment() > 1);
>  }
>  
> +static bool __init swiotlb_default_pool_needs_cc_shared(void)
> +{
> +	/* A restricted DMA pool provides the shared buffers instead. */
> +	return cc_platform_has(CC_ATTR_MEM_ENCRYPT) &&
> +	       !restricted_dma_pool_present;
> +}

I don't think restricted_dma_pool_present should change the cc_shared
attribute. The rmem pool is all about sizing the swiotlb, not disabling
sharing.

Thinking some more, if other archs don't like rmem pool influencing the
default swiotlb size, we could add a flag (SWIOTLB_SKIP_IF_RMEM_POOL or
some better name). But only if people dislike the heuristics.

> @@ -437,9 +469,11 @@ void __init swiotlb_init_remap(unsigned int flags,
>  		io_tlb_default_mem.phys_limit = ARCH_LOW_ADDRESS_LIMIT;
>  #endif
>  
> -	if (!(flags & (SWIOTLB_INIT_ADDRESSING_LIMIT |
> -		       SWIOTLB_INIT_CC_SHARED)) &&
> -	    swiotlb_kmalloc_needs_bounce()) {
> +	if (swiotlb_default_pool_needs_cc_shared()) {
> +		io_tlb_default_mem.cc_shared = true;
> +		swiotlb_adjust_cc_attributes();
> +	} else if (!(flags & SWIOTLB_INIT_ADDRESSING_LIMIT) &&
> +		   swiotlb_kmalloc_needs_bounce()) {

I think at a high level, we need (i.e. separate attributed from sizing):

	if (cc_platform_has(CC_ATTR_MEM_ENCRYPT))
		io_tlb_default_mem.cc_shared = true;

	if (cc_platform_has(CC_ATTR_GUEST_MEM_ENCRYPT)) {
		if (!restricted_dma_pool_present)
			swiotlb_adjust_cc_size();	/* 6%, clamped */
	} else if (!(flags & SWIOTLB_INIT_ADDRESSING_LIMIT) &&
		   swiotlb_kmalloc_needs_bounce()) {
		swiotlb_shrink_for_kmalloc();		/* 1MB per 1GB */
	}

-- 
Catalin


      parent reply	other threads:[~2026-08-14 17:34 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-08-13 10:25 [RFC PATCH v2 0/2] dma: swiotlb: Centralize default pool sizing Aneesh Kumar K.V (Arm)
2026-08-13 10:25 ` [RFC PATCH v2 1/2] dma: swiotlb: Centralize default pool initialization and sizing Aneesh Kumar K.V (Arm)
2026-08-14 16:15   ` Catalin Marinas
2026-08-13 10:25 ` [RFC PATCH v2 2/2] dma: swiotlb: Initialize and size shared default pools for memory encryption Aneesh Kumar K.V (Arm)
2026-08-13 16:50   ` Michael Kelley
2026-08-14 17:34   ` Catalin Marinas [this message]

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=an9RrwoaAsqJQ2vN@arm.com \
    --to=catalin.marinas@arm.com \
    --cc=Suzuki.Poulose@arm.com \
    --cc=agordeev@linux.ibm.com \
    --cc=aik@amd.com \
    --cc=aneesh.kumar@kernel.org \
    --cc=borntraeger@linux.ibm.com \
    --cc=chleroy@kernel.org \
    --cc=gerald.schaefer@linux.ibm.com \
    --cc=gor@linux.ibm.com \
    --cc=hca@linux.ibm.com \
    --cc=iommu@lists.linux.dev \
    --cc=jgg@ziepe.ca \
    --cc=jiri@resnulli.us \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=linux-coco@lists.linux.dev \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-s390@vger.kernel.org \
    --cc=linuxppc-dev@lists.ozlabs.org \
    --cc=m.szyprowski@samsung.com \
    --cc=maddy@linux.ibm.com \
    --cc=maz@kernel.org \
    --cc=mpe@ellerman.id.au \
    --cc=npiggin@gmail.com \
    --cc=ptesarik@suse.com \
    --cc=robin.murphy@arm.com \
    --cc=smostafa@google.com \
    --cc=steven.price@arm.com \
    --cc=svens@linux.ibm.com \
    --cc=will@kernel.org \
    --cc=x86@kernel.org \
    --cc=yilun.xu@linux.intel.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox