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

[Catalin Marinas <catalin.marinas@arm.com>]

On Wed, Aug 12, 2026 at 04:38:03PM +0530, Aneesh Kumar K.V wrote:
> Catalin Marinas <catalin.marinas@arm.com> writes:
> > On Tue, Aug 11, 2026 at 07:10:56PM +0530, Aneesh Kumar K.V (Arm) wrote:
> >> 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.

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

Let's not single out pKVM but rather the reason it does not want one -
it relies heavily on restricted mem. If you started a pKVM guest
without rmem in DT, I assume it will need swiotlb to function properly.
It's not a great heuristic (devices may not use rmem) but it preserves
the current behaviour and can be overridden on the command line.

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

It's still not clear to me why we went for CC_ATTR_MEM_ENCRYPT instead
of CC_ATTR_GUEST_MEM_ENCRYPT.

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

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.

-- 
Catalin