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

[Aneesh Kumar K.V]

Marek Szyprowski <m.szyprowski at samsung.com> writes:

> On 07.10.2026 12:43, Will Deacon wrote:
>> On Wed, Oct 07, 2026 at 11:04:05AM +0100, Catalin Marinas wrote:
>>> On Tue, Oct 06, 2026 at 10:49:17PM +0100, Will Deacon wrote:
>>>> On Thu, Sep 24, 2026 at 11:37:54AM +0530, Aneesh Kumar K.V (Arm) wrote:
>>>>> @@ -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;
>>>> I think this check on the restricted DMA pool is too general -- the pool
>>>> could be tied to a specific DMA-capable peripheral and so treating its
>>>> presence as a global property isn't right.
>>> I agree it's a hack but that was the simplest way to avoid the pVMs
>>> getting a bounce buffer after this patch. More than happy to leave it
>>> out and reduce the buffer on cmdline or we come up with some better
>>> heuristics.
>> Hrm, that does mean that reverting just this part will regress pVMs
>> because they'll suddenly be allocating a tonne more memory for an
>> entirely unused swiotlb buffer. So I think I'd prefer to drop the entire
>> series until this has been worked out properly.
> I've dropped the entire series from dma-mapping-for-next. Aneesh, please respin
> it again and move the pKVM/restricted_dma_pool related code into the separate
> patch.
>

Once we agree on the correct way to detect the pKVM use case, I will
resend the series.

-aneesh