Re: [PATCH v3] x86/pci-dma: add a SWIOTLB_ANY flag to lift the low mem limitation
From: Aakarsh Jain
Date: Wed Jun 24 2026 - 01:58:37 EST
Hi Borislav,
On 6/24/2026 10:41 AM, Borislav Petkov wrote:
On Wed, Jun 24, 2026 at 03:23:39AM +0000, Miao, Jun wrote:I tested this patch on a SEV-SNP guest and it works as expected. The SWIOTLB buffer is now allocated above the 4 GB low-memory boundary, confirming that the SWIOTLB_ANY flag takes effect on SNP as well. I was also able to scale the bounce buffer size up to support larger networking workloads.
On Wed, Jun 24, 2026 at 01:53:39AM +0000, Miao, Jun wrote:
Good suggestion and thank you for testing the ADM SEV-SNP.
I don't think anyone tested it on SNP yet.
I only know that SEV-SNP is a more advanced, third-generation feature.
Are we using "SEV" here as a shorthand for these?
You have SEV, SEV-ES and SEV-SNP in the order of their appearance and in the
order they have gotten additional features. SNP is the one which is has
addressed the most if not all? confidential VM attack vectors. And that's the
one I care about as the other two are just the prerequisites to the SNP thing.
In my opinion only anyway.
When using confidential VMs, users want to pass through both the high-speed
network interface card (NIC) or an 8-GPUs setup into the CVMs. During data
transfer, the SWIOTLB bounce buffer becomes a critical "hot path" acting as
an intermediary for convertor between private and shared memory.
consequently, the capacity requirement increases—otherwise, network or data
transfer performance would be adversely affected.
Yes, that makes more sense. Pls add it to the commit message.
What I mean to convey is that in TEE environments based on AMD SEV or Intel TDX,
the core issue is the lack of trust in the hypervisor's VMM.
Then say it this way. Trusted hypervisor sounds like we trust the HV. Which we
absolutely do not.
When using confidential VMs, users want to pass through both the high-speed
network interface card (NIC) or an 8-GPUs setup into the CVMs. During data
transfer, the SWIOTLB bounce buffer becomes a critical "hot path" acting as
an intermediary for convertor between private and shared memory.
consequently, the capacity requirement increases—otherwise, network or data
transfer performance would be adversely affected
Confidential VMs include AMD SEV and Intel TDX guests want to allocate
a swiotlb buffer that is not restricted to low memory in TEE.
Sounds better, yes.
Except that we still need to test it on SNP.
Adding some folks on Cc who can do that and take a look at your patch and vet
it for SNP - my guest is still broken. :-\
From kernel dmesg logs:
root@ubuntu:/home/ubuntu# dmesg | grep -i sev
[ 21.191917] Memory Encryption Features active: AMD SEV SEV-ES SEV-SNP
[ 21.192883] SEV: Status: SEV SEV-ES SEV-SNP
[ 21.401897] SEV: APIC: wakeup_secondary_cpu() replaced with wakeup_cpu_via_vmgexit()
[ 22.117267] SEV: Using SNP CPUID table, 28 entries present.
[ 22.117884] SEV: SNP running at VMPL0.
[ 24.164260] SEV: SNP guest platform devices initialized.
[ 28.815142] systemd[1]: Detected confidential virtualization sev-snp.
[ 30.063831] sev-guest sev-guest: Initialized SEV guest driver (using VMPCK0 communication key)
root@ubuntu:/home/ubuntu# dmesg | grep -i "IO TLB"
[ 6.743607] software IO TLB: area num 4.
[ 24.164169] software IO TLB: mapped [mem 0x0000001df9c00000-0x0000001ff9c00000] (8192MB)
[ 24.331266] software IO TLB: Memory encryption is active and system is using DMA bounce buffers
root@ubuntu:/home/ubuntu#
Thanks,
Aakarsh> Thx.