* [PATCH v4] x86/pci-dma: add a SWIOTLB_ANY flag to lift the low mem limitation
@ 2026-06-25 1:26 Jun Miao
2026-06-25 3:14 ` Michael Kelley
2026-07-12 0:55 ` Borislav Petkov
0 siblings, 2 replies; 3+ messages in thread
From: Jun Miao @ 2026-06-25 1:26 UTC (permalink / raw)
To: bp, tglx, mingo, dave.hansen, m.szyprowski, robin.murphy,
rick.p.edgecombe
Cc: x86, linux-kernel, aakarsh.jain, michael.roth, fan.du, jun.miao
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@oss.qualcomm.com>
Suggested-by: Borislav Petkov <bp@alien8.de>
Acked-by: Marek Szyprowski <m.szyprowski@samsung.com>
Reviewed-by: Aakarsh Jain <aakarsh.jain@oss.qualcomm.com>
Signed-off-by: Jun Miao <jun.miao@intel.com>
---
v1 -> v2:
- Updated commit message and description.
- Add Reviewed and Tested.
V1 Latest Feedback : https://lists.openwall.net/linux-kernel/2026/02/11/483
v2 -> v3:
- We can alloc 4GB with the dynamic swiotlb, rather than 1GB.
1G is not correct. So change the commit log.
v3 -> v4:
- Not only TDX-specific but all encrypted guests include SEV.
- SEV-SNP guest passed the test with the help of Aakarsh.
Tested-by: Aakarsh Jain <aakarsh.jain@oss.qualcomm.com>
- Add "Acked-by: Marek Szyprowski"
- Explain the usage case in the commit log following Boris`s suggestion.
---
arch/x86/kernel/pci-dma.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/x86/kernel/pci-dma.c b/arch/x86/kernel/pci-dma.c
index 6267363e0189..73b9320c4a7d 100644
--- a/arch/x86/kernel/pci-dma.c
+++ b/arch/x86/kernel/pci-dma.c
@@ -61,7 +61,7 @@ static void __init pci_swiotlb_detect(void)
*/
if (cc_platform_has(CC_ATTR_GUEST_MEM_ENCRYPT)) {
x86_swiotlb_enable = true;
- x86_swiotlb_flags |= SWIOTLB_FORCE;
+ x86_swiotlb_flags |= SWIOTLB_ANY | SWIOTLB_FORCE;
}
}
#else
--
2.47.1
^ permalink raw reply [flat|nested] 3+ messages in thread
* RE: [PATCH v4] x86/pci-dma: add a SWIOTLB_ANY flag to lift the low mem limitation
2026-06-25 1:26 [PATCH v4] x86/pci-dma: add a SWIOTLB_ANY flag to lift the low mem limitation Jun Miao
@ 2026-06-25 3:14 ` Michael Kelley
2026-07-12 0:55 ` Borislav Petkov
1 sibling, 0 replies; 3+ messages in thread
From: Michael Kelley @ 2026-06-25 3:14 UTC (permalink / raw)
To: Jun Miao, bp, tglx, mingo, dave.hansen, m.szyprowski,
robin.murphy, rick.p.edgecombe
Cc: x86, linux-kernel, aakarsh.jain, michael.roth, fan.du
From: Jun Miao <jun.miao@intel.com> Sent: Wednesday, June 24, 2026 6:26 PM
>
> 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@oss.qualcomm.com>
> Suggested-by: Borislav Petkov <bp@alien8.de>
> Acked-by: Marek Szyprowski <m.szyprowski@samsung.com>
> Reviewed-by: Aakarsh Jain <aakarsh.jain@oss.qualcomm.com>
> Signed-off-by: Jun Miao <jun.miao@intel.com>
I tested this change in Intel TDX and AMD SEV-SNP VMs in the
Azure cloud, which are running on Hyper-V and with a paravisor.
The SEV-SNP VM operates in vTOM mode.
I was able to allocate a 4 GiB swiotlb, whereas prior to this patch
specifying 4 GiB resulted in a memory allocation failure and a
downgrade to 2 GiB. All bounce buffered DMA operations from
the Hyper-V synthetic SCSI and NIC controllers worked correctly,
as did DMA operations from a PCI pass-thru NVMe controller in
the TDX VM.
Reviewed-by: Michael Kelley <mhklinux@outlook.com>
Tested-by: Michael Kelley <mhklinux@outlook.com>
> ---
>
> v1 -> v2:
> - Updated commit message and description.
> - Add Reviewed and Tested.
> V1 Latest Feedback : https://lists.openwall.net/linux-kernel/2026/02/11/483
>
> v2 -> v3:
> - We can alloc 4GB with the dynamic swiotlb, rather than 1GB.
> 1G is not correct. So change the commit log.
>
> v3 -> v4:
> - Not only TDX-specific but all encrypted guests include SEV.
> - SEV-SNP guest passed the test with the help of Aakarsh.
> Tested-by: Aakarsh Jain <aakarsh.jain@oss.qualcomm.com>
>
> - Add "Acked-by: Marek Szyprowski"
> - Explain the usage case in the commit log following Boris`s suggestion.
>
> ---
> arch/x86/kernel/pci-dma.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/arch/x86/kernel/pci-dma.c b/arch/x86/kernel/pci-dma.c
> index 6267363e0189..73b9320c4a7d 100644
> --- a/arch/x86/kernel/pci-dma.c
> +++ b/arch/x86/kernel/pci-dma.c
> @@ -61,7 +61,7 @@ static void __init pci_swiotlb_detect(void)
> */
> if (cc_platform_has(CC_ATTR_GUEST_MEM_ENCRYPT)) {
> x86_swiotlb_enable = true;
> - x86_swiotlb_flags |= SWIOTLB_FORCE;
> + x86_swiotlb_flags |= SWIOTLB_ANY | SWIOTLB_FORCE;
> }
> }
> #else
> --
> 2.47.1
>
^ permalink raw reply [flat|nested] 3+ messages in thread
* Re: [PATCH v4] x86/pci-dma: add a SWIOTLB_ANY flag to lift the low mem limitation
2026-06-25 1:26 [PATCH v4] x86/pci-dma: add a SWIOTLB_ANY flag to lift the low mem limitation Jun Miao
2026-06-25 3:14 ` Michael Kelley
@ 2026-07-12 0:55 ` Borislav Petkov
1 sibling, 0 replies; 3+ messages in thread
From: Borislav Petkov @ 2026-07-12 0:55 UTC (permalink / raw)
To: Jun Miao
Cc: tglx, mingo, dave.hansen, m.szyprowski, robin.murphy,
rick.p.edgecombe, x86, linux-kernel, aakarsh.jain, michael.roth,
fan.du
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@oss.qualcomm.com>
> Suggested-by: Borislav Petkov <bp@alien8.de>
> Acked-by: Marek Szyprowski <m.szyprowski@samsung.com>
> Reviewed-by: Aakarsh Jain <aakarsh.jain@oss.qualcomm.com>
> Signed-off-by: Jun Miao <jun.miao@intel.com>
> ---
Sashiko has a question:
https://lore.kernel.org/r/20260625012616.2992535-1-jun.miao@intel.com
--
Regards/Gruss,
Boris.
https://people.kernel.org/tglx/notes-about-netiquette
^ permalink raw reply [flat|nested] 3+ messages in thread
end of thread, other threads:[~2026-07-12 0:56 UTC | newest]
Thread overview: 3+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2026-06-25 1:26 [PATCH v4] x86/pci-dma: add a SWIOTLB_ANY flag to lift the low mem limitation Jun Miao
2026-06-25 3:14 ` Michael Kelley
2026-07-12 0:55 ` Borislav Petkov
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox