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

Marek Szyprowski [off-list ref] writes:

On 07.08.2026 20:20, Jason Gunthorpe wrote:

quoted

On Fri, Aug 07, 2026 at 06:13:49PM +0000, Mostafa Saleh wrote:

quoted

But the whole thing is best effort anyway, the kernel picks
IO_TLB_DEFAULT_SIZE which does not depend on the system topology or
how many devices or how much DMA they do.
SWIOTLB memory is wasted if unused so we should be careful around
that as it would be the other way around and users would have to
decrease it manually.

Yeah, it is why the arch code shouldn't really be sizing it directly,
it should be done in common code and, yes, we are probably going to
have to do something alot smarter to have the common code better
auto-tune this for the CC case..

What about the $subject patch? I assume that it is still needed to

restore the behavior that was altered by the "[PATCH v8 00/23]

dma-mapping: Track shared DMA state through direct, pool and swiotlb

paths?" patchset?

I would request that we pick this patch to fix the regression described
in https://lore.kernel.org/all/yq5azeyxyfol.fsf@kernel.org/ (local).

We can then work separately on improving the default swiotlb pool size
in generic code based on other metrics. I consider this patch
independent of that work.

Even with such an improvement, this patch would still be applicable: a
condition that resizes the swiotlb pool based on arm64_dma_phys_limit
should not apply when guest memory encryption is in use, because the
purpose of the swiotlb pool is different in that configuration.

-aneesh