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
next prev parent 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