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

[Marek Szyprowski]

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 <m.szyprowski@xxxxxxxxxxx> 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/yq5azeyxyfol.fsf@xxxxxxxxxx/.
> 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