All of lore.kernel.org
 help / color / mirror / Atom feed
From: Aneesh Kumar K.V <aneesh.kumar@kernel.org>
To: Marek Szyprowski <m.szyprowski@samsung.com>,
	Catalin Marinas <catalin.marinas@arm.com>
Cc: linux-arm-kernel@lists.infradead.org,
	linux-kernel@vger.kernel.org, iommu@lists.linux.dev,
	Will Deacon <will@kernel.org>,
	Robin Murphy <robin.murphy@arm.com>,
	suzuki.poulose@arm.com, steven.price@arm.com
Subject: Re: [PATCH] arm64: swiotlb: Don’t shrink default buffer when bounce is forced
Date: Tue, 17 Mar 2026 10:59:13 +0530	[thread overview]
Message-ID: <yq5av7ev6n2u.fsf@kernel.org> (raw)
In-Reply-To: <cd026591-c278-4f89-9d21-1a2125a85a44@samsung.com>

Marek Szyprowski <m.szyprowski@samsung.com> writes:

> On 06.02.2026 07:11, Aneesh Kumar K.V wrote:
>> Catalin Marinas <catalin.marinas@arm.com> writes:
>>> On Tue, Jan 20, 2026 at 12:31:02PM +0530, Aneesh Kumar K.V (Arm) wrote:
>>>> arm64 reduces the default swiotlb size (for unaligned kmalloc()
>>>> bouncing) when it detects that no swiotlb bouncing is needed.
>>>>
>>>> If swiotlb bouncing is explicitly forced via the command line
>>>> (swiotlb=force), this heuristic must not apply. Add a swiotlb helper to
>>>> query the forced-bounce state and use it to skip the resize when
>>>> bouncing is forced.
>>> I think the logic you proposed in reply to Robin might work better but
>>> have you actually hit a problem that triggered this patch? Do people
>>> passing swiotlb=force expect a specific size for the buffer?
>>>
>> This issue was observed while implementing swiotlb for a trusted device.
>> I was testing the protected swiotlb space using the swiotlb=force
>> option, which causes the device to use swiotlb even in protected mode.
>> As per Robin, an end user using the swiotlb=force option will also
>> specify a custom swiotlb size
>
> Does the above mean that it works fine when user provides both 
> swiotlb=force and custom swiotlb size, so no changes in the code are 
> actually needed?
>

swiotlb_adjust_size() checks whether the default_nslabs value has
changed and avoids updating the SWIOTLB size based on different
subsystem logic.

void __init swiotlb_adjust_size(unsigned long size)
{
	/*
	 * If swiotlb parameter has not been specified, give a chance to
	 * architectures such as those supporting memory encryption to
	 * adjust/expand SWIOTLB size for their use.
	 */
	if (default_nslabs != IO_TLB_DEFAULT_SIZE >> IO_TLB_SHIFT)
		return;


To handle swiotlb_force alone we can do

modified   kernel/dma/swiotlb.c
@@ -209,6 +209,8 @@ unsigned long swiotlb_size_or_default(void)
 
 void __init swiotlb_adjust_size(unsigned long size)
 {
+	unsigned long nslabs;
+
 	/*
 	 * If swiotlb parameter has not been specified, give a chance to
 	 * architectures such as those supporting memory encryption to
@@ -218,7 +220,13 @@ void __init swiotlb_adjust_size(unsigned long size)
 		return;
 
 	size = ALIGN(size, IO_TLB_SIZE);
-	default_nslabs = ALIGN(size >> IO_TLB_SHIFT, IO_TLB_SEGSIZE);
+	nslabs = ALIGN(size >> IO_TLB_SHIFT, IO_TLB_SEGSIZE);
+	/*
+	 * Don't allow to reduce size if we are forcing swiotlb bounce.
+	 */
+	if (swiotlb_force_bounce && nslabs < default_nslabs)
+		return;
+	default_nslabs = nslabs;
 	if (round_up_default_nslabs())
 		size = default_nslabs << IO_TLB_SHIFT;
 	pr_info("SWIOTLB bounce buffer size adjusted to %luMB", size >> 20);



      reply	other threads:[~2026-03-17  5:29 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-01-20  7:01 [PATCH] arm64: swiotlb: Don’t shrink default buffer when bounce is forced Aneesh Kumar K.V (Arm)
2026-01-20  9:25 ` Anshuman Khandual
2026-01-20 13:20 ` Robin Murphy
2026-01-21  6:10   ` Aneesh Kumar K.V
2026-02-04 18:52 ` Catalin Marinas
2026-02-06  6:11   ` Aneesh Kumar K.V
2026-03-04 10:00     ` Marek Szyprowski
2026-03-17  5:29       ` Aneesh Kumar K.V [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=yq5av7ev6n2u.fsf@kernel.org \
    --to=aneesh.kumar@kernel.org \
    --cc=catalin.marinas@arm.com \
    --cc=iommu@lists.linux.dev \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=m.szyprowski@samsung.com \
    --cc=robin.murphy@arm.com \
    --cc=steven.price@arm.com \
    --cc=suzuki.poulose@arm.com \
    --cc=will@kernel.org \
    /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.