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

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

On Thu, Aug 13, 2026 at 11:02:17AM +0530, Aneesh Kumar K.V wrote:
> Catalin Marinas <catalin.marinas@arm.com> writes:
> > 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.
> 
> 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.

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

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

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

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