Re: [PATCH] arm64: swiotlb: Keep the default size for protected guests

On 10/08/2026 6:00 am, Michael Kelley wrote:
> From: Aneesh Kumar K.V <[email protected]> Sent: Friday, August 7, 2026 11:01 AM
>>
>> Jason Gunthorpe <[email protected]> writes:
>>
>>> On Fri, Aug 07, 2026 at 02:18:31PM +0100, Will Deacon wrote:
>>>
>>>>> I was under the impression that there is a possibility of using swiotlb
>>>>> instead of restricted-dma-pool with pKVM.
>>>>
>>>> Yes, that patch enables swiotlb as a possibility for protected guests
>>>> but with your patch we avoid shrinking the swiotlb buffer even when
>>>> restricted dma pools are being used and that's a waste of memory.
>>>
>>> I also thought we switched pkvm to use CC-like swiotlb as part of the
>>> alignment in this rework? Mostafa ?
>>>
>>>>> If that is not the case, then we could change:
>>>>>
>>>>> !cc_platform_has(CC_ATTR_GUEST_MEM_ENCRYPT) &&
>>>>>
>>>>> to
>>>>>
>>>>> !is_realm_world() &&
>>>>
>>>> Perhaps, or you could just pass the swiotlb= option if the defaults don't
>>>> work for you. Can you give more details about the slots exhaustion you're
>>>> seeing under CCA?
>>>
>>> We see badness with swiotlb too, it basically doesn't work out of the
>>> box if you have to use it 100% for real devices. It easily runs out
>>> of memory.
>>>
>>> Auto tuning to higher levels makes sense to me, but I'd rather the
>>> core code handled adjusting its size to the estimated need, not arch
>>> code.
>>
>> Agreed
> 
> Nobody has mentioned it on this thread, but arch code under x86 has
> a heuristic for sizing the swiotlb for SEV-SNP and TDX. The heuristic is 6%
> of guest memory, with a max of 1 GiB. See mem_encrypt_setup_arch().
> The heuristic originally went into the 5.11 kernel nearly 6 years ago for
> the original SEV support and hasn't changed since. See commit
> e998879d4fb79, which doesn't give much of an explanation. I don't
> think this is necessarily a good heuristic -- it tends to waste a lot of
> memory, but there are also a few cases where it isn't enough memory.
> After a few years of experience with SEV and TDX, nobody seems to
> have tried to come up with something better, so maybe it's not all that
> bad.
> 
> No doubt the heuristic should move into common code so CCA, SEV,
> and TDX all use the same one.

Indeed that would probably make sense as a future refactoring, as I 
would assume the general expectations of CoCo environments should be 
largely independent from the specific technology of either "Co" :)

However, note that currently the arch checks are effectively serving 
opposite purposes - x86 is specifically *increasing* the default SWIOTLB 
size for SEV/TDX, while the arm64 check (and RISC-V copy), is about 
*reducing* the default size if we think we (mostly) don't need it.

Thanks,
Robin.