RE: [PATCH v4] x86/pci-dma: add a SWIOTLB_ANY flag to lift the low mem limitation

[Miao, Jun]

>On Thu, Jun 25, 2026 at 09:26:16AM +0800, Jun Miao wrote:
>> When high-speed NICs or multi-GPU setups are passed through into
>> confidential VMs, the SWIOTLB bounce buffer becomes the critical path
>> between private and shared memory. Restricting it to low memory limits
>> throughput and fails to scale for larger workloads.
>>
>> AMD SEV-SNP and Intel TDX guests run in a TEE where the hypervisor is
>untrusted.
>> DMA-capable devices require bounce buffers to mediate between
>> encrypted private memory and unencrypted shared memory. Confining
>> these buffers to low memory (<4GB) unnecessarily caps their size and
>degrades performance.
>>
>> Power SVM already supports this; x86 does not. See commit 8ba2ed1be9
>> ("swiotlb: add a SWIOTLB_ANY flag to lift the low memory restriction").
>>
>> [ aakarsh: completely trim down/rewrite changelog ]
>>
>> Tested-by: Aakarsh Jain <aakarsh.jain@xxxxxxxxxxxxxxxx>
>> Suggested-by: Borislav Petkov <bp@xxxxxxxxx>
>> Acked-by: Marek Szyprowski <m.szyprowski@xxxxxxxxxxx>
>> Reviewed-by: Aakarsh Jain <aakarsh.jain@xxxxxxxxxxxxxxxx>
>> Signed-off-by: Jun Miao <jun.miao@xxxxxxxxx>
>> ---
>
>Sashiko has a question:
>
>https://lore.kernel.org/r/20260625012616.2992535-1-jun.miao@xxxxxxxxx
>
>
Sashiko  said “Does x86 lack DMA-mask filtering during pool search?”:

Conclusion:  yes, it does (at least in the current common SWIOTLB search path).
Therefore, after enabling SWIOTLB_ANY, dma-direct with 32-bit DMA-mask devices is indeed more
likely to hit the case where a high-address bounce buffer is allocated first and then rejected by dma_capable().

I plan to modify SWIOTLB directly: in the direct DMA path, I’ll filter candidate pool/slot addresses by dma_capable() 
during the search phase, so we avoid the case where a high address is allocated first and then fails without retrying 
a low-memory buffer. At the same time, I’ll keep the IOMMU/Xen paths unchanged.

Warm regards
Jun Miao
>--
>Regards/Gruss,
>    Boris.
>
>https://people.kernel.org/tglx/notes-about-netiquette