Marek Szyprowski <[email protected]> writes: > On 07.08.2026 20:20, Jason Gunthorpe wrote: >> On Fri, Aug 07, 2026 at 06:13:49PM +0000, Mostafa Saleh wrote: >>> 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/[email protected]/. 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
