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.
