From: sashiko-bot@kernel.org
To: "Aneesh Kumar K.V (Arm)" <aneesh.kumar@kernel.org>
Cc: linux-s390@vger.kernel.org, "Vasily Gorbik" <gor@linux.ibm.com>,
"Alexander Gordeev" <agordeev@linux.ibm.com>,
"Christian Borntraeger" <borntraeger@linux.ibm.com>,
"Heiko Carstens" <hca@linux.ibm.com>
Subject: Re: [PATCH v3 3/4] dma: swiotlb: Centralize memory-encryption pool sizing
Date: Fri, 04 Sep 2026 10:36:44 +0000 [thread overview]
Message-ID: <20260904103644.CD15E1F00A3D@smtp.kernel.org> (raw)
In-Reply-To: <20260904101810.1193505-4-aneesh.kumar@kernel.org>
Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
- [High] Skipping SWIOTLB_POOL_CC_GUEST when a restricted DMA pool is present can result in SWIOTLB_POOL_NONE or SWIOTLB_POOL_MINIMAL being selected, breaking DMA for all other devices.
--
commit d8ab20a637a8736036e923dfa3f89a8da55215c3
Author: Aneesh Kumar K.V (Arm) <aneesh.kumar@kernel.org>
dma: swiotlb: Centralize memory-encryption pool sizing
This patch centralizes SWIOTLB memory-encryption pool sizing for guests into
the SWIOTLB core. It sizes the confidential guest pool to 6% of guest memory
by default and records the presence of restricted DMA pools to avoid selecting
the confidential-guest policy solely based on guest memory encryption.
> diff --git a/kernel/dma/swiotlb.c b/kernel/dma/swiotlb.c
> index 90e0bfd0715cf..c4611b2c45403 100644
> --- a/kernel/dma/swiotlb.c
> +++ b/kernel/dma/swiotlb.c
[ ... ]
> @@ -509,7 +553,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;
[Severity: High]
Does skipping SWIOTLB_POOL_CC_GUEST here leave the system without a proper
fallback for non-restricted devices?
Looking at swiotlb_select_pool_policy() in kernel/dma/swiotlb.c, if a
confidential guest boots with a restricted DMA pool present in the Device
Tree, and system RAM is small enough that SWIOTLB_INIT_ADDRESSING_LIMIT is
not set (e.g., <= 4GB), this check will skip SWIOTLB_POOL_CC_GUEST.
The function then falls through all the way to SWIOTLB_POOL_MINIMAL (a tiny
1MB/GB pool) or SWIOTLB_POOL_NONE. If it returns SWIOTLB_POOL_NONE,
swiotlb_init_remap() will exit without allocating a default SWIOTLB pool.
As a result, unassigned devices that still rely on the default pool for
bounce buffers will fail to map DMA memory, potentially leading to I/O
errors or boot panics.
Should this path safely fall back to SWIOTLB_POOL_DEFAULT when a restricted
DMA pool is present, to ensure a standard default pool is still allocated?
>
> if (cc_platform_has(CC_ATTR_HOST_MEM_ENCRYPT))
> return SWIOTLB_POOL_DEFAULT;
--
Sashiko AI review · https://sashiko.dev/#/patchset/20260904101810.1193505-1-aneesh.kumar@kernel.org?part=3
next prev parent reply other threads:[~2026-09-04 10:36 UTC|newest]
Thread overview: 17+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-09-04 10:18 [PATCH v3 0/4] dma: swiotlb: Centralize default pool policy and sizing Aneesh Kumar K.V (Arm)
2026-09-04 10:18 ` Aneesh Kumar K.V (Arm)
2026-09-04 10:18 ` [PATCH v3 1/4] dma: swiotlb: Centralize default pool policy selection Aneesh Kumar K.V (Arm)
2026-09-04 10:18 ` Aneesh Kumar K.V (Arm)
2026-09-04 10:40 ` sashiko-bot
2026-09-04 10:18 ` [PATCH v3 2/4] dma: swiotlb: Centralize minimal pool sizing Aneesh Kumar K.V (Arm)
2026-09-04 10:18 ` Aneesh Kumar K.V (Arm)
2026-09-04 10:31 ` sashiko-bot
2026-09-04 10:18 ` [PATCH v3 3/4] dma: swiotlb: Centralize memory-encryption " Aneesh Kumar K.V (Arm)
2026-09-04 10:18 ` Aneesh Kumar K.V (Arm)
2026-09-04 10:36 ` sashiko-bot [this message]
2026-09-09 9:28 ` Aneesh Kumar K.V
2026-09-04 10:18 ` [PATCH v3 4/4] dma: swiotlb: Remove SWIOTLB_ANY Aneesh Kumar K.V (Arm)
2026-09-04 10:18 ` Aneesh Kumar K.V (Arm)
2026-09-04 10:35 ` sashiko-bot
2026-09-09 6:28 ` Aneesh Kumar K.V
2026-09-09 6:31 ` Aneesh Kumar K.V
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=20260904103644.CD15E1F00A3D@smtp.kernel.org \
--to=sashiko-bot@kernel.org \
--cc=agordeev@linux.ibm.com \
--cc=aneesh.kumar@kernel.org \
--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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.