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

[Aneesh Kumar K.V <aneesh.kumar@kernel.org>]

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.


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


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

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

This is done for x86 to handle SME. SME also requires an unencrypted
swiotlb pool

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

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

-aneesh