Re: [PATCH v4 3/5] dma: swiotlb: Centralize memory-encryption pool sizing

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

Catalin Marinas <catalin.marinas@arm.com> writes:

> On Mon, Sep 14, 2026 at 12:31:32PM +0530, Aneesh Kumar K.V (Arm) wrote:
>> +/**
>> + * swiotlb_adjusted_size() - get the prospective adjusted SWIOTLB size
>> + *
>> + * Return the size that confidential-computing guest sizing would select for
>> + * the default pool, without changing the configured SWIOTLB size. An
>> + * explicit swiotlb= size is always preserved. An explicit area count is
>> + * included in the size calculation. Automatic area sizing is initialized
>> + * later from the running kernel's possible CPU map and any resulting size
>> + * adjustment is therefore not reflected in the returned size.
>> + */
>> +unsigned long __init swiotlb_adjusted_size(void)
>> +{
>> +	unsigned long nslabs, size = swiotlb_size_or_default();
>> +
>> +	if (swiotlb_default_size_changed() ||
>> +	    !cc_platform_has(CC_ATTR_GUEST_MEM_ENCRYPT))
>> +		return size;
>> +	/*
>> +	 * For SEV and TDX and CCA, 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.
>
> Nit: if SWIOTLB_ANY is passed, do we still allocate only from low
> memory? I think this comment made sense on x86 but it's not valid for
> s390, pseries with the changes so far.
>

I'll remove that part of the comment, as the code does not check the
adjusted size against the low-memory limit.

>
> Otherwise:
>
> Reviewed-by: Catalin Marinas <catalin.marinas@arm.com>

-aneesh