Linux s390 Architecture development
 help / color / mirror / Atom feed
From: Aneesh Kumar K.V <aneesh.kumar@kernel.org>
To: sashiko-reviews@lists.linux.dev
Cc: Christian Borntraeger <borntraeger@linux.ibm.com>,
	Vasily Gorbik <gor@linux.ibm.com>,
	linux-s390@vger.kernel.org, Heiko Carstens <hca@linux.ibm.com>,
	Alexander Gordeev <agordeev@linux.ibm.com>
Subject: Re: [PATCH v5 4/6] dma: swiotlb: Centralize memory-encryption pool sizing
Date: Tue, 22 Sep 2026 12:32:04 +0530	[thread overview]
Message-ID: <yq5amrt93h1v.fsf@kernel.org> (raw)
In-Reply-To: <20260921065215.8B56C1F00893@smtp.kernel.org>

sashiko-bot@kernel.org writes:

> Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
> - [High] swiotlb: 64-bit division build error and 32-bit multiplication overflow
> --
>
> commit 7f27b828f817aa2b9787b04060d6febbcd685bcf
> Author: Aneesh Kumar K.V (Arm) <aneesh.kumar@kernel.org>
>
> dma: swiotlb: Centralize memory-encryption pool sizing
>
> The patch moves the x86 guest-sizing policy into the SWIOTLB core, sizing
> the SWIOTLB_POOL_CC_GUEST pool to 6% of guest memory. It also provides a
> way for early users like the crash kernel to view the adjusted pool size
> before SWIOTLB initialization.
>
>> diff --git a/kernel/dma/swiotlb.c b/kernel/dma/swiotlb.c
>> --- a/kernel/dma/swiotlb.c
>> +++ b/kernel/dma/swiotlb.c
>> @@ -480,6 +481,46 @@ static bool __init swiotlb_kmalloc_needs_bounce(void)
>>  
>> +/**
>> + * swiotlb_adjusted_size() - get the prospective adjusted SWIOTLB size
>> + *
> [ ... ]
>> + */
>> +unsigned long __init swiotlb_adjusted_size(void)
>> +{
>> +	unsigned long nslabs, size = swiotlb_size_or_default();
>> +
>> +	if (swiotlb_default_size_changed() ||
>> +	    !cc_platform_has(CC_ATTR_GUEST_MEM_ENCRYPT))
>> +		return size;
>
> [Severity: High]
> This is a pre-existing issue, but returning `size` directly here bypasses
> area-aware alignment for explicitly configured sizes and non-CC_GUEST setups.
>
> Could this discrepancy, along with the behavior of `swiotlb_aligned_nslabs()`
> during early boot, cause the crash kernel to under-reserve memory?
>
> The crash kernel reserves low memory based on the prospective size from
> `swiotlb_adjusted_size()` (or explicit `swiotlb=` sizes). However, early
> in boot, `default_nareas` is 0, so `swiotlb_aligned_nslabs()` merely aligns
> to segments and skips the area-aware power-of-two rounding:
>
> kernel/dma/swiotlb.c:swiotlb_aligned_nslabs() {
> 	...
> 	if (!default_nareas)
> 		return nslabs;
>
> 	if (nslabs < IO_TLB_SEGSIZE * default_nareas)
> 		nslabs = IO_TLB_SEGSIZE * default_nareas;
> 	else if (!is_power_of_2(nslabs))
> 		nslabs = roundup_pow_of_two(nslabs);
> 	...
> }
>
> Later, `swiotlb_init_remap()` initializes `default_nareas` and calls
> `swiotlb_adjust_nareas()`, triggering `round_up_default_nslabs()` to round
> the pool up to the next power of two.
>
> As a result, the allocated SWIOTLB pool can be up to ~50% larger than the
> reserved size (e.g., 600MB rounded to 1024MB). When the crash kernel
> attempts to allocate this rounded-up size, will it exceed its reserved
> memory and OOM?
>

I added a new patch that consolidates the slab rounding and addresses
this issue.

>
>> +	/*
>> +	 * For SEV and TDX and CCA, all DMA has to occur via
> [ ... ]
>> +	 * 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 = memblock_phys_mem_size() * 6 / 100;
>> +	size = clamp_val(size, IO_TLB_DEFAULT_SIZE, SZ_1G);
>
> [Severity: High]
> Does this calculation cause an undefined reference to `__udivdi3` on 32-bit
> PAE builds, and overflow on 32-bit non-PAE builds?
>
> The guest sizing logic has been relocated into `kernel/dma/swiotlb.c`, which
> is compiled for all architectures. On 32-bit kernels with PAE, `phys_addr_t`
> is 64-bit, so `memblock_phys_mem_size() * 6 / 100` performs a 64-bit division
> by 100. GCC will emit a call to `__udivdi3`, which is missing from the
> kernel's libgcc, causing a fatal build link error.
>
> On 32-bit kernels without PAE, `phys_addr_t` is 32-bit. If physical memory
> exceeds ~715MB (`UINT_MAX / 6`), the multiplication `memblock_phys_mem_size()
> * 6` overflows the 32-bit integer, resulting in a silently truncated and
> incorrect pool size.
>
> Should this be refactored to cast the operand to `u64` and use `div_u64()` to
> be safe across all platforms?
>

Switched to div_u64() as shown below.

unsigned long __init swiotlb_adjusted_size(void)
{
	unsigned long nslabs;
	u64 size = swiotlb_size_or_default();

	if (!swiotlb_cmdline_size_set &&
	    cc_platform_has(CC_ATTR_GUEST_MEM_ENCRYPT)) {
		/*
		 * 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);
	}

	nslabs = swiotlb_calc_nslabs(size, default_nareas);

	return nslabs << IO_TLB_SHIFT;
}

-aneesh

  reply	other threads:[~2026-09-22  7:02 UTC|newest]

Thread overview: 28+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-09-21  6:36 [PATCH v5 0/6] dma: swiotlb: Centralize default pool policy and sizing Aneesh Kumar K.V (Arm)
2026-09-21  6:36 ` [PATCH v5 1/6] dma: swiotlb: Centralize default pool policy selection Aneesh Kumar K.V (Arm)
2026-09-21  6:56   ` sashiko-bot
2026-09-21 15:25   ` Robin Murphy
2026-09-22  5:32     ` Aneesh Kumar K.V
2026-09-21  6:36 ` [PATCH v5 2/6] dma: swiotlb: Track whether the pool size was explicitly set Aneesh Kumar K.V (Arm)
2026-09-21  6:44   ` sashiko-bot
2026-09-21 12:50   ` Catalin Marinas
2026-09-21 15:45   ` Robin Murphy
2026-09-22  5:42     ` Aneesh Kumar K.V
2026-09-21  6:36 ` [PATCH v5 3/6] dma: swiotlb: Centralize minimal pool sizing Aneesh Kumar K.V (Arm)
2026-09-21  6:45   ` sashiko-bot
2026-09-21 12:52   ` Catalin Marinas
2026-09-21 16:49   ` Robin Murphy
2026-09-22  6:56     ` Aneesh Kumar K.V
2026-09-21  6:36 ` [PATCH v5 4/6] dma: swiotlb: Centralize memory-encryption " Aneesh Kumar K.V (Arm)
2026-09-21  6:52   ` sashiko-bot
2026-09-22  7:02     ` Aneesh Kumar K.V [this message]
2026-09-23 12:47   ` Robin Murphy
2026-09-23 14:28     ` Aneesh Kumar K.V
2026-09-21  6:36 ` [PATCH v5 5/6] dma: swiotlb: Add an overridable architecture pool opt-out Aneesh Kumar K.V (Arm)
2026-09-21  6:51   ` sashiko-bot
2026-09-22  7:04     ` Aneesh Kumar K.V
2026-09-23 13:04   ` Robin Murphy
2026-09-23 14:18     ` Aneesh Kumar K.V
2026-09-21  6:36 ` [PATCH v5 6/6] dma: swiotlb: Remove SWIOTLB_ANY Aneesh Kumar K.V (Arm)
2026-09-21  6:48   ` sashiko-bot
2026-09-23 13:12   ` Robin Murphy

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=yq5amrt93h1v.fsf@kernel.org \
    --to=aneesh.kumar@kernel.org \
    --cc=agordeev@linux.ibm.com \
    --cc=borntraeger@linux.ibm.com \
    --cc=gor@linux.ibm.com \
    --cc=hca@linux.ibm.com \
    --cc=linux-s390@vger.kernel.org \
    --cc=sashiko-reviews@lists.linux.dev \
    /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