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

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

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.

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

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

-- 
Catalin