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

On Thu, Aug 13, 2026 at 11:02:17AM +0530, Aneesh Kumar K.V wrote:

Catalin Marinas [off-list ref] writes:

quoted

On Wed, Aug 12, 2026 at 04:38:03PM +0530, Aneesh Kumar K.V wrote:

quoted

Catalin Marinas [off-list ref] writes:

quoted

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.

Yes but in one case it did not do resizing. With your proposal, it now
does swiotlb resizing even for SME.

Isn't that a bug with x86 SME? I would expect both SME and SEV to
require that swiotlb resize.

Maybe, but that's for a different discussion (and we may want different
sizing). Better to keep the semantics unchanged for now.

quoted

quoted

quoted

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

This is getting fixed in  
https://lore.kernel.org/all/20260701054926.825925-9-aneesh.kumar@kernel.org/ (local)

You might want to bring this early together with the swiotlb adjustment
here.

quoted

quoted

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().

The arch code already reports cc_platform_has(), can we not rely on
this in the core code instead of specific is_realm_world() and a new
SWIOTLB_INIT_CC_SHARED flag or function call?

We have three different decisions that shouldn't be driven by a single
flag from the arch code:

1. allocate default pool
2. make default pool shared
3. resize default pool

(1) is traditionally driven by arch code and that's fine. For (2), the
core code has the information via CC_ATTR_*. For (3), we can enlarge it
based on CC_ATTR_GUEST_MEM_ENCRYPT in combination with rmem (but not
CC_ATTR_MEM_ENCRYPT to keep the current x86 behaviour).

Okay, if the presence of restricted-dma-pool is taken as a hint, we can
definitely move that to generic code.

I still think not resizing the swiotlb pool on the host for SME is an
x86 bug. However, I'll keep it compatible with the current behavior and
use CC_ATTR_GUEST_MEM_ENCRYPT for now. We can handle host SME in a
separate patch if needed.

Sound good.

quoted

I think we should also move the reduction based on
CONFIG_DMA_BOUNCE_UNALIGNED_KMALLOC into the core code. Riscv copied the
same heuristic as arm64, so there's precedent for sharing.

I already have a patch doing that.

Great. Now you have a 3-patch series for the generic swiotlb sizing ;)

-- 
Catalin