mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
From: Kohei Enju <enju.kohei@fujitsu.com>
To: "Aneesh Kumar K.V" <aneesh.kumar@kernel.org>
Cc: Catalin Marinas <catalin.marinas@arm.com>,
	 Will Deacon <will@kernel.org>,
	iommu@lists.linux.dev, linux-kernel@vger.kernel.org,
	 Robin Murphy <robin.murphy@arm.com>,
	Marek Szyprowski <m.szyprowski@samsung.com>,
	 Jonathan Corbet <corbet@lwn.net>,
	Shuah Khan <skhan@linuxfoundation.org>,
	 Randy Dunlap <rdunlap@infradead.org>,
	Mark Rutland <mark.rutland@arm.com>,
	 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>,
	Dan Williams <dan.j.williams@intel.com>,
	 Xu Yilun <yilun.xu@linux.intel.com>,
	Madhavan Srinivasan <maddy@linux.ibm.com>,
	 Michael Ellerman <mpe@ellerman.id.au>,
	Nicholas Piggin <npiggin@gmail.com>,
	 "Christophe Leroy (CS GROUP)" <chleroy@kernel.org>,
	"Ritesh Harjani (IBM)" <ritesh.list@gmail.com>,
	 Shrikanth Hegde <sshegde@linux.ibm.com>,
	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>,
	Stefano Stabellini <sstabellini@kernel.org>,
	 Russell King <linux@armlinux.org.uk>,
	Huacai Chen <chenhuacai@kernel.org>,
	 WANG Xuerui <kernel@xen0n.name>,
	Thomas Bogendoerfer <tsbogend@alpha.franken.de>,
	 Jiaxun Yang <jiaxun.yang@flygoat.com>,
	Paul Walmsley <pjw@kernel.org>,
	 Palmer Dabbelt <palmer@dabbelt.com>,
	Albert Ou <aou@eecs.berkeley.edu>,
	 Alexandre Ghiti <alex@ghiti.fr>,
	Andy Lutomirski <luto@kernel.org>,
	 Peter Zijlstra <peterz@infradead.org>,
	Thomas Gleixner <tglx@kernel.org>,
	 Ingo Molnar <mingo@redhat.com>, Borislav Petkov <bp@alien8.de>,
	 Dave Hansen <dave.hansen@linux.intel.com>,
	"H. Peter Anvin" <hpa@zytor.com>,
	 linux-arm-kernel@lists.infradead.org, loongarch@lists.linux.dev,
	linux-mips@vger.kernel.org,  linuxppc-dev@lists.ozlabs.org,
	linux-riscv@lists.infradead.org, linux-s390@vger.kernel.org,
	 x86@kernel.org
Subject: Re: [PATCH v6 6/8] dma: swiotlb: Centralize memory-encryption pool sizing
Date: Wed, 11 Nov 2026 20:53:00 +0900	[thread overview]
Message-ID: <avRKiCBs81XSYMqW@FCCLS0092175.localdomain> (raw)
In-Reply-To: <yq5a8q3d9oe6.fsf@kernel.org>

Hi Aneesh,

On 11/01 09:47, Aneesh Kumar K.V wrote:
[...]
> >
> > Hi Aneesh,
> >
> > I can reproduce the CCA regression discussed in this thread:
> >   https://lore.kernel.org/all/yq5azeyxyfol.fsf@kernel.org/#t
> >
> > The guest runs out of SWIOTLB slots, causing disk I/O to fail and
> > preventing the guest from booting.
> >
> > I would like to test the fix on real CCA hardware. Could you please Cc
> > me when you respin the series? I follow LKML, but I may still miss the
> > posting by chance.
> >
> 
> The conclusion was to either use CONFIG_SWIOTLB_DYNAMIC or swiotlb kernel command line
> option

Thanks for the clarification.

After reading this whole thread, I agree that dynamic sizing would be
appropriate.

However, currently some distributions do not enable
CONFIG_SWIOTLB_DYNAMIC. Users of such distributions would therefore need
to rebuild their kernels with the option enabled. This is not a
practical solution for many users, particularly cloud users who use
kernels provided by their distributions or cloud providers.

Specifying swiotlb= on the kernel command line is also not particularly
user-friendly. It requires users or cloud providers to choose a fixed
value in advance, without automatically taking into account properties
of the VM, such as its memory size or whether it is a confidential
guest.

I do not think the existing heuristic used for x86 CoCo guests is
necessarily optimal, but a fixed swiotlb= value chosen by each user may
be even less appropriate.

Overall, I would prefer the dynamic sizing approach. However, I believe
the initial pool size still matters.

Also, as Catalin pointed out earlier in the following message:

    https://lore.kernel.org/all/ann6noRzoPLL9kDY@arm.com/

the arm64 adjustment also reduces the target size used for dynamic
pool allocation, since both the initial pool and dynamic allocation
currently use default_nslabs.

I am testing the patch below to decouple the initial pool size from the
dynamic allocation target. It adds swiotlb_adjust_initial_size() for
callers that only want to reduce the initial allocation, while keeping
the existing swiotlb_adjust_size() semantics for callers that want to
adjust both sizes.

Thanks,
Kohei

--->8---
diff --git a/arch/arm64/mm/init.c b/arch/arm64/mm/init.c
index 4e7682dfe366..80a2c171895f 100644
--- a/arch/arm64/mm/init.c
+++ b/arch/arm64/mm/init.c
@@ -349,7 +349,7 @@ void __init arch_mm_preinit(void)
                unsigned long size =
                        DIV_ROUND_UP(memblock_phys_mem_size(), 1024);

-               swiotlb_adjust_size(min(swiotlb_default_pool_size(), size));
+               swiotlb_adjust_initial_size(min(swiotlb_default_pool_size(), size));
        }

        swiotlb_init(true, flags);
diff --git a/arch/riscv/mm/init.c b/arch/riscv/mm/init.c
index 070ee69eabb3..7dd9fcec90a5 100644
--- a/arch/riscv/mm/init.c
+++ b/arch/riscv/mm/init.c
@@ -189,7 +189,7 @@ void __init arch_mm_preinit(void)
                 */
                unsigned long size =
                        DIV_ROUND_UP(memblock_phys_mem_size(), 1024);
-               swiotlb_adjust_size(min(swiotlb_default_pool_size(), size));
+               swiotlb_adjust_initial_size(min(swiotlb_default_pool_size(), size));
                swiotlb = true;
                swiotlb_flags |= SWIOTLB_ANY;
        }
diff --git a/include/linux/swiotlb.h b/include/linux/swiotlb.h
index 5f24edf47b68..c1984ee12355 100644
--- a/include/linux/swiotlb.h
+++ b/include/linux/swiotlb.h
@@ -190,6 +190,7 @@ size_t swiotlb_max_mapping_size(struct device *dev);
 bool is_swiotlb_allocated(void);
 bool is_swiotlb_active(struct device *dev);
 void __init swiotlb_adjust_size(unsigned long size);
+void __init swiotlb_adjust_initial_size(unsigned long size);
 phys_addr_t default_swiotlb_base(void);
 phys_addr_t default_swiotlb_limit(void);
 #else
@@ -232,6 +233,10 @@ static inline void swiotlb_adjust_size(unsigned long size)
 {
 }

+static inline void swiotlb_adjust_initial_size(unsigned long size)
+{
+}
+
 static inline phys_addr_t default_swiotlb_base(void)
 {
        return 0;
diff --git a/kernel/dma/swiotlb.c b/kernel/dma/swiotlb.c
index 2c57b49ac7c0..211fefb32fb5 100644
--- a/kernel/dma/swiotlb.c
+++ b/kernel/dma/swiotlb.c
@@ -99,6 +99,7 @@ static struct io_tlb_mem io_tlb_default_mem;
 #endif /* CONFIG_SWIOTLB_DYNAMIC */

 static unsigned long default_nslabs = IO_TLB_DEFAULT_SIZE >> IO_TLB_SHIFT;
+static unsigned long dynamic_nslabs = IO_TLB_DEFAULT_SIZE >> IO_TLB_SHIFT;
 static unsigned long default_nareas;
 static bool swiotlb_cmdline_size_set __initdata;

@@ -152,6 +153,8 @@ static void swiotlb_adjust_nareas(unsigned int nareas)
                nareas = roundup_pow_of_two(nareas);

        default_nareas = nareas;
+       dynamic_nslabs =
+               swiotlb_calc_nslabs(dynamic_nslabs << IO_TLB_SHIFT, nareas);

        pr_info("area num %d.\n", nareas);
        nslabs = swiotlb_calc_nslabs(default_nslabs << IO_TLB_SHIFT, nareas);
@@ -254,6 +257,7 @@ setup_io_tlb_npages(char *str)
                /* avoid tail segment of size < IO_TLB_SEGSIZE */
                default_nslabs =
                        ALIGN(simple_strtoul(str, &str, 0), IO_TLB_SEGSIZE);
+               dynamic_nslabs = default_nslabs;
                swiotlb_cmdline_size_set = true;
        }
        if (*str == ',')
@@ -290,7 +294,7 @@ unsigned long swiotlb_default_pool_size(void)
        return default_nslabs << IO_TLB_SHIFT;
 }

-void __init swiotlb_adjust_size(unsigned long size)
+void __init swiotlb_adjust_initial_size(unsigned long size)
 {
        /*
         * If swiotlb parameter has not been specified, give a chance to
@@ -305,6 +309,12 @@ void __init swiotlb_adjust_size(unsigned long size)
        pr_info("SWIOTLB bounce buffer size adjusted to %luMB", size >> 20);
 }

+void __init swiotlb_adjust_size(unsigned long size)
+{
+       swiotlb_adjust_initial_size(size);
+       dynamic_nslabs = default_nslabs;
+}
+
 void swiotlb_print_info(void)
 {
        struct io_tlb_pool *mem = &io_tlb_default_mem.defpool;
@@ -507,6 +517,7 @@ void __init swiotlb_init_remap(bool addressing_limit, unsigned int flags,
                pr_info("SWIOTLB bounce buffer size adjusted %lu -> %lu slabs",
                        default_nslabs, nslabs);
                default_nslabs = nslabs;
+               dynamic_nslabs = default_nslabs;
        }

        alloc_size = PAGE_ALIGN(array_size(sizeof(*mem->slots), nslabs));
@@ -889,7 +900,7 @@ static void swiotlb_dyn_alloc(struct work_struct *work)
                container_of(work, struct io_tlb_mem, dyn_alloc);
        struct io_tlb_pool *pool;

-       pool = swiotlb_alloc_pool(NULL, mem, IO_TLB_MIN_SLABS, default_nslabs,
+       pool = swiotlb_alloc_pool(NULL, mem, IO_TLB_MIN_SLABS, dynamic_nslabs,
                                  default_nareas, mem->phys_limit, GFP_KERNEL);
        if (!pool) {
                pr_warn_ratelimited("Failed to allocate new pool");


  reply	other threads:[~2026-11-11 11:53 UTC|newest]

Thread overview: 28+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <CGME20260924060823eucas1p1d27fbf57221c9b4c0e9831a9b0cdd7d3@eucas1p1.samsung.com>
2026-09-24  6:07 ` [PATCH v6 0/8] dma: swiotlb: Centralize default pool policy and sizing Aneesh Kumar K.V (Arm)
2026-09-24  6:07   ` [PATCH v6 1/8] dma: swiotlb: Rename swiotlb_size_or_default() Aneesh Kumar K.V (Arm)
2026-09-24  6:07   ` [PATCH v6 2/8] dma: swiotlb: Consolidate slab rounding Aneesh Kumar K.V (Arm)
2026-09-24  6:07   ` [PATCH v6 3/8] dma: swiotlb: Track whether the pool size was explicitly set Aneesh Kumar K.V (Arm)
2026-09-24  6:07   ` [PATCH v6 4/8] dma: swiotlb: Centralize default pool policy selection Aneesh Kumar K.V (Arm)
2026-09-24  6:07   ` [PATCH v6 5/8] dma: swiotlb: Centralize minimal pool sizing Aneesh Kumar K.V (Arm)
2026-09-24  6:07   ` [PATCH v6 6/8] dma: swiotlb: Centralize memory-encryption " Aneesh Kumar K.V (Arm)
2026-10-06 21:49     ` Will Deacon
2026-10-07 10:04       ` Catalin Marinas
2026-10-07 10:43         ` Will Deacon
2026-10-07 11:13           ` Catalin Marinas
2026-10-07 12:15           ` Aneesh Kumar K.V
2026-10-08  5:33             ` Aneesh Kumar K.V
2026-10-08 12:51               ` Catalin Marinas
2026-10-08 14:32                 ` Aneesh Kumar K.V
2026-10-08 15:32                   ` Marek Szyprowski
2026-10-09 10:18                     ` Will Deacon
2026-10-30 10:50                   ` Kohei Enju
2026-11-01  4:17                     ` Aneesh Kumar K.V
2026-11-11 11:53                       ` Kohei Enju [this message]
2026-10-08 10:05           ` Marek Szyprowski
2026-10-08 11:42             ` Aneesh Kumar K.V
2026-10-07 12:17         ` Aneesh Kumar K.V
2026-09-24  6:07   ` [PATCH v6 7/8] dma: swiotlb: Add an overridable architecture pool opt-out Aneesh Kumar K.V (Arm)
2026-09-24  6:07   ` [PATCH v6 8/8] dma: swiotlb: Remove SWIOTLB_ANY Aneesh Kumar K.V (Arm)
2026-09-25  8:57   ` [PATCH v6 0/8] dma: swiotlb: Centralize default pool policy and sizing Marek Szyprowski
2026-10-06 21:42   ` Marek Szyprowski
2026-10-06 21:52     ` Will Deacon

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=avRKiCBs81XSYMqW@FCCLS0092175.localdomain \
    --to=enju.kohei@fujitsu.com \
    --cc=Suzuki.Poulose@arm.com \
    --cc=agordeev@linux.ibm.com \
    --cc=aik@amd.com \
    --cc=alex@ghiti.fr \
    --cc=aneesh.kumar@kernel.org \
    --cc=aou@eecs.berkeley.edu \
    --cc=borntraeger@linux.ibm.com \
    --cc=bp@alien8.de \
    --cc=catalin.marinas@arm.com \
    --cc=chenhuacai@kernel.org \
    --cc=chleroy@kernel.org \
    --cc=corbet@lwn.net \
    --cc=dan.j.williams@intel.com \
    --cc=dave.hansen@linux.intel.com \
    --cc=gerald.schaefer@linux.ibm.com \
    --cc=gor@linux.ibm.com \
    --cc=hca@linux.ibm.com \
    --cc=hpa@zytor.com \
    --cc=iommu@lists.linux.dev \
    --cc=jgg@ziepe.ca \
    --cc=jiaxun.yang@flygoat.com \
    --cc=jiri@resnulli.us \
    --cc=kernel@xen0n.name \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-mips@vger.kernel.org \
    --cc=linux-riscv@lists.infradead.org \
    --cc=linux-s390@vger.kernel.org \
    --cc=linux@armlinux.org.uk \
    --cc=linuxppc-dev@lists.ozlabs.org \
    --cc=loongarch@lists.linux.dev \
    --cc=luto@kernel.org \
    --cc=m.szyprowski@samsung.com \
    --cc=maddy@linux.ibm.com \
    --cc=mark.rutland@arm.com \
    --cc=maz@kernel.org \
    --cc=mingo@redhat.com \
    --cc=mpe@ellerman.id.au \
    --cc=npiggin@gmail.com \
    --cc=palmer@dabbelt.com \
    --cc=peterz@infradead.org \
    --cc=pjw@kernel.org \
    --cc=ptesarik@suse.com \
    --cc=rdunlap@infradead.org \
    --cc=ritesh.list@gmail.com \
    --cc=robin.murphy@arm.com \
    --cc=skhan@linuxfoundation.org \
    --cc=smostafa@google.com \
    --cc=sshegde@linux.ibm.com \
    --cc=sstabellini@kernel.org \
    --cc=steven.price@arm.com \
    --cc=svens@linux.ibm.com \
    --cc=tglx@kernel.org \
    --cc=tsbogend@alpha.franken.de \
    --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

all inboxes | Powered by JetHome®