On 10.08.2026 12:20, Will Deacon wrote: > On Mon, Aug 10, 2026 at 02:59:42PM +0530, Aneesh Kumar K.V wrote: >> 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]/. > I really don't think we need it. CCA hardware isn't exactly widespread > and the KVM host side patches don't appear close to being merged.
Does this mean that the branch for-next/coco [1] won't go to v7.3-rc1? I've used it as a base for the mentioned DMA-mapping patchset. [1] https://git.kernel.org/pub/scm/linux/kernel/git/arm64/linux.git/log/?h=for-next/coco > We have time to fix this properly, rather than papering over it in the > arch code. > > Please consider this a NAK from the arm64 side on this patch. Best regards -- Marek Szyprowski, PhD Samsung R&D Institute Poland
