Bounce buffer pool increment issue

[aakarshcool15-crypto]

Hi,

I understand from below patch we can increase bounce buffer size beyond 4GB memory.
https://lore.kernel.org/all/0a08cea7-62a2-4b33-8d8b-dd14b3c74235@amd.com/

But looks like this patch has one issue. Alexey gave review comments on this patch which looks genuine. He mentioned SWIOTLB_ANY places the swiotlb pool above 4GB, a devices with a 32-bit DMA mask can't DMA to that bounce buffer, defeating the purpose of swiotlb.

He also mentioned there Conflict with Aneesh's patch series:
https://patchwork.kernel.org/project/linux-arm-kernel/cover/20260604083959.1265923-1-aneesh.kumar@kernel.org/

After Aneesh's series lands, CoCo guests lose the ability to allocate a large swiotlb pool above 4GB. Aneesh's series removes SWIOTLB_FORCE but does NOT add SWIOTLB_ANY for the CoCo path. The result is that pci_swiotlb_detect() leaves x86_swiotlb_flags = 0 for CoCo guests, no force, no ANY.

Can anyone answer what should be right approach to increase bounce buffer size after Aneesh series lands in upstream kernel?

Thanks in advance!!

[aik]

This is better be discussed in the public maillists.
I suspect SWIOTLB_ANY should be a new option for the "swiotlb=" kernel parameter rather than enforcing it widely like that.

[aakarshcool15-crypto]

Thanks Alexey.
how would you suggest to take it forward?
Should I post RFC for upstream folks for addition of SWIOTLB_ANY as new option for the "swiotlb=" kernel parameter?

[aik]

You can try posting the new kernel parameter, or may be add swiotlb-64 pool (and may be explore DMA_DIRECT_REMAP and DMA_COHERENT_POOL). Do not forget to address all comments from v3.