Re: [RFC PATCH] dma: swiotlb: Size shared default pools for memory encryption

Catalin Marinas [off-list ref] writes:

On Tue, Aug 11, 2026 at 07:10:56PM +0530, Aneesh Kumar K.V (Arm) wrote:

quoted

Systems with memory encryption use swiotlb to provide shared or
unencrypted buffers for device DMA. Confidential guests may route all
DMA through these buffers, while SME hosts use them for devices that
cannot address encrypted memory. The default swiotlb pool can therefore
be exhausted under I/O-intensive workloads.

Let architectures mark the default swiotlb pool as shared before
swiotlb_init().

I thought we wanted even this decision to be moved out of the arch code.

Architectures may want to use an unencrypted swiotlb pool for different
reasons, one of them being CC_ATTR_GUEST_MEM_ENCRYPT. x86 hosts also
require unencrypted pool to support SME. We can cover both cases using
CC_ATTR_MEM_ENCRYPT. However, pKVM does not want an unencrypted SWIOTLB
pool. So I was thinking it would be much cleaner to let the architecture
code drive that decision.

quoted

Move the existing x86 sizing policy into generic swiotlb
code and add early pool marking for arm64 Realm guests, powerpc secure
guests, s390 protected-virtualization guests, and x86 memory-encryption
platforms. Use CC_ATTR_MEM_ENCRYPT on x86 to include host SME, whose
swiotlb pool must also be decrypted for devices that cannot address
encrypted memory.

That's a functional change for x86. For now, I'd keep it to
CC_ATTR_GUEST_MEM_ENCRYPT.

BTW, why does arm64 report CC_ATTR_MEM_ENCRYPT instead of the GUEST
option in realms?

quoted

Move the powerpc secure-guest swiotlb enablement before initialization
so that the shared pool is allocated with the required flags. pKVM
guests continue to use a restricted DMA pool instead of the default
swiotlb pool.

Signed-off-by: Aneesh Kumar K.V (Arm) <aneesh.kumar@kernel.org>
---
 arch/arm64/mm/init.c                 |  6 ++-
 arch/powerpc/mm/mem.c                |  7 +++
 arch/powerpc/platforms/pseries/svm.c | 10 ----
 arch/s390/mm/init.c                  |  2 +
 arch/x86/mm/mem_encrypt.c            | 27 ++--------
 include/linux/swiotlb.h              |  7 ++-
 kernel/dma/swiotlb.c                 | 73 ++++++++++++++++++++++------
 7 files changed, 82 insertions(+), 50 deletions(-)

diff --git a/arch/arm64/mm/init.c b/arch/arm64/mm/init.c
index e308a7cabd12..4c022e8aed43 100644
--- a/arch/arm64/mm/init.c
+++ b/arch/arm64/mm/init.c

@@ -338,8 +338,12 @@ void __init arch_setup_zero_pages(void)
 void __init arch_mm_preinit(void)
 {
 	unsigned int flags = SWIOTLB_VERBOSE;
+	/* pKVM uses restricted-dma-pool */
+	bool cc_guest = is_realm_world();
 
-	if (max_pfn <= PFN_DOWN(arm64_dma_phys_limit)) {
+	if (cc_guest) {
+		swiotlb_mark_default_cc_shared();
+	} else if (max_pfn <= PFN_DOWN(arm64_dma_phys_limit)) {
 		/*
 		 * If no bouncing needed for ZONE_DMA, reduce the swiotlb
 		 * buffer for kmalloc() bouncing to 1MB per 1GB of RAM.

With your other reworking, doesn't the core code know the swiotlb will
be shared? Can it not make the decision to resize at that point based
solely on CC_ATTR_GUEST_MEM_ENCRYPT?

I also wonder whether we could address Will's pKVM request not to
allocate a bounce buffer once pKVM guests will start reporting
CC_ATTR_GUEST_MEM_ENCRYPT. Some simple heuristic: if a
restricted-dma-pool is advertised in DT (it will end up in
rmem_swiotlb_setup()), skip resizing the default swiotlb. It's not
perfect but the bounce buffer can be overridden on the command line.

For the same reason I mentioned above, architectures may have different
reasons for setting cc_shared = true. IMHO, it is cleaner to let the
architecture code make that decision before swiotlb_init().

-aneesh