Re: [PATCH v6 6/8] dma: swiotlb: Centralize memory-encryption pool sizing

[sashiko-bot@kernel.org]

Thank you for your contribution! Sashiko AI review found 2 potential issue(s) to consider:
- [High] dma: swiotlb: missing fallback disables default pool on CC guests with restricted DMA
- [High] x86: crash_reserve: low memory reservation undersized for CC guests
--

commit b7ccaf6e292795b26ab1ca8eb765bb8952de98b5
Author: Aneesh Kumar K.V (Arm) <aneesh.kumar@kernel.org>

dma: swiotlb: Centralize memory-encryption pool sizing

Memory-encrypted guests use shared or unencrypted memory for DMA and may
route all DMA through SWIOTLB. The default pool can therefore be too
small for I/O-intensive workloads.

> diff --git a/arch/x86/mm/mem_encrypt.c b/arch/x86/mm/mem_encrypt.c
> index 95bae74fdab23..912f22ca838f8 100644
> --- a/arch/x86/mm/mem_encrypt.c
> +++ b/arch/x86/mm/mem_encrypt.c
[ ... ]
> @@ -114,27 +111,6 @@ void __init mem_encrypt_setup_arch(void)
>  	if (!cc_platform_has(CC_ATTR_GUEST_MEM_ENCRYPT))
>  		return;
>  
> -	/*
> -	 * For SEV and TDX, all DMA has to occur via shared/unencrypted pages.
> -	 * Kernel uses SWIOTLB to make this happen without changing device
> -	 * drivers. However, depending on the workload being run, the
> -	 * default 64MB of SWIOTLB may not be enough and SWIOTLB may
> -	 * run out of buffers for DMA, resulting in I/O errors and/or
> -	 * performance degradation especially with high I/O workloads.
> -	 *
> -	 * Adjust the default size of SWIOTLB using a percentage of guest
> -	 * memory for SWIOTLB buffers. Also, as the SWIOTLB bounce buffer
> -	 * memory is allocated from low memory, ensure that the adjusted size
> -	 * is within the limits of low available memory.
> -	 *
> -	 * The percentage of guest memory used here for SWIOTLB buffers
> -	 * is more of an approximation of the static adjustment which
> -	 * 64MB for <1G, and ~128M to 256M for 1G-to-4G, i.e., the 6%
> -	 */
> -	size = total_mem * 6 / 100;
> -	size = clamp_val(size, IO_TLB_DEFAULT_SIZE, SZ_1G);
> -	swiotlb_adjust_size(size);
> -

[Severity: High]
Does moving this SWIOTLB adjustment run too late for crashkernel reservation?

When this was called during mem_encrypt_setup_arch(), the SWIOTLB size was
adjusted before arch_reserve_crashkernel() called crash_low_size_default().

Now the dynamic guest sizing is evaluated later, so crash_low_size_default()
only sees the unadjusted 64MB default.

If the crash kernel is provided with a large amount of memory (e.g.,
crashkernel=4G,high), its own dynamically calculated SWIOTLB size could
exhaust the 256MB of low memory reserved by the main kernel.

Could this lead to out-of-memory errors in the low memory zone and break
kdump functionality on x86 memory-encrypted guests?

>  	/* Set restricted memory access for virtio. */
>  	virtio_set_mem_acc_cb(virtio_require_restricted_mem_acc);
>  }
> diff --git a/kernel/dma/swiotlb.c b/kernel/dma/swiotlb.c
> index 75ee63cd354e2..e626cca63ad11 100644
> --- a/kernel/dma/swiotlb.c
> +++ b/kernel/dma/swiotlb.c
[ ... ]
> @@ -496,7 +516,8 @@ swiotlb_select_pool_policy(unsigned int flags)
>  	if (swiotlb_force_disable)
>  		return SWIOTLB_POOL_NONE;
>  
> -	if (cc_platform_has(CC_ATTR_GUEST_MEM_ENCRYPT))
> +	if (cc_platform_has(CC_ATTR_GUEST_MEM_ENCRYPT) &&
> +	    !restricted_dma_pool_present)
>  		return SWIOTLB_POOL_CC_GUEST;
>  
>  	if (cc_platform_has(CC_ATTR_HOST_MEM_ENCRYPT))

[Severity: High]
Does this disable the default SWIOTLB pool entirely for confidential guests
with a restricted DMA pool?

If restricted_dma_pool_present is true on a confidential guest, this condition
fails.

If no other conditions match later in swiotlb_select_pool_policy()
(for instance, if there are no addressing limits because guest RAM is small,
such as on arm64 CCA), the function falls through and returns
SWIOTLB_POOL_NONE.

Could this result in devices not explicitly assigned to the restricted DMA pool
failing to map memory, leading to device malfunction or a system panic?

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20260924060756.1325156-1-aneesh.kumar@kernel.org?part=6