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

[Aakarsh Jain <aakarsh.jain@oss.qualcomm.com>]

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:
>>> 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. :-\
> 
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.

 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.
>