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

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

[Jun Miao]

Intel TDX guest wants to allocate a swiotlb buffer that is not restricted to
low memory for the trusted hypervisor scheme.  Adding a new flag will be used
in swiotlb_memblock_alloc() to allow allocation of SWIOTLB memory beyond low 
memory restriction.

Power SVM already supports this, but X86 still faces the same limitation.
Commit: 8ba2ed1be9 (swiotlb: add a SWIOTLB_ANY flag to lift the low memory restriction)

Reviewed-by: Aakarsh Jain <aakarsh.jain@oss.qualcomm.com>
Tested-by: Aakarsh Jain <aakarsh.jain@oss.qualcomm.com>
Signed-off-by: Jun Miao <jun.miao@intel.com>
---

V1 -> V2:
1.Updated commit message and description.
2.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.

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

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

[Marek Szyprowski]

On 12.02.2026 10:37, Jun Miao wrote:
> Intel TDX guest wants to allocate a swiotlb buffer that is not restricted to
> low memory for the trusted hypervisor scheme.  Adding a new flag will be used
> in swiotlb_memblock_alloc() to allow allocation of SWIOTLB memory beyond low
> memory restriction.
>
> Power SVM already supports this, but X86 still faces the same limitation.
> Commit: 8ba2ed1be9 (swiotlb: add a SWIOTLB_ANY flag to lift the low memory restriction)
>
> Reviewed-by: Aakarsh Jain <aakarsh.jain@oss.qualcomm.com>
> Tested-by: Aakarsh Jain <aakarsh.jain@oss.qualcomm.com>
> Signed-off-by: Jun Miao <jun.miao@intel.com>

Acked-by: Marek Szyprowski <m.szyprowski@samsung.com>

> ---
>
> V1 -> V2:
> 1.Updated commit message and description.
> 2.Add Reviewed and Tested.
>
> V1 Latest Feedback : https://protect2.fireeye.com/v1/url?k=f35668f3-92dd7dc5-f357e3bc-74fe485cbff1-e6ff63e2f942f6a7&q=1&e=66eee4e1-a18d-47f9-ad21-f3dfab1d6f09&u=https%3A%2F%2Flists.openwall.net%2Flinux-kernel%2F2026%2F02%2F11%2F483
>
> v2 -> v3:
> We can alloc 4GB with the dynamic swiotlb, rather than 1GB.
> 1G is not correct. So change the commit log.
>
> ---
>   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

Best regards
-- 
Marek Szyprowski, PhD
Samsung R&D Institute Poland

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

[Miao, Jun]

Hi Marek 
Thanks a lot for the ACK on the swiotlb. 
It is very important to confirm the functionality. I really appreciate your review @ Marek

Maybe x86 maintainers would also like to hear your thoughts on this, especially since architectures like powerpc already have support for this. 
Any additional feedback or suggestions on X86 might have would be greatly appreciated.

Best regards,
Jun Miao

>On 12.02.2026 10:37, Jun Miao wrote:
>> Intel TDX guest wants to allocate a swiotlb buffer that is not
>> restricted to low memory for the trusted hypervisor scheme.  Adding a
>> new flag will be used in swiotlb_memblock_alloc() to allow allocation
>> of SWIOTLB memory beyond low memory restriction.
>>
>> Power SVM already supports this, but X86 still faces the same limitation.
>> Commit: 8ba2ed1be9 (swiotlb: add a SWIOTLB_ANY flag to lift the low
>> memory restriction)
>>
>> Reviewed-by: Aakarsh Jain <aakarsh.jain@oss.qualcomm.com>
>> Tested-by: Aakarsh Jain <aakarsh.jain@oss.qualcomm.com>
>> Signed-off-by: Jun Miao <jun.miao@intel.com>
>
>Acked-by: Marek Szyprowski <m.szyprowski@samsung.com>
>
>> ---
>>
>> V1 -> V2:
>> 1.Updated commit message and description.
>> 2.Add Reviewed and Tested.
>>
>> V1 Latest Feedback :
>> https://protect2.fireeye.com/v1/url?k=f35668f3-92dd7dc5-f357e3bc-74fe4
>> 85cbff1-e6ff63e2f942f6a7&q=1&e=66eee4e1-a18d-47f9-ad21-
>f3dfab1d6f09&u=
>> https%3A%2F%2Flists.openwall.net%2Flinux-
>kernel%2F2026%2F02%2F11%2F483
>>
>> v2 -> v3:
>> We can alloc 4GB with the dynamic swiotlb, rather than 1GB.
>> 1G is not correct. So change the commit log.
>>
>> ---
>>   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
>
>Best regards
>--
>Marek Szyprowski, PhD
>Samsung R&D Institute Poland

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

[Aakarsh Jain]

Hi,

Kindly requesting feedback from the x86 maintainers on this patch at 
your earliest convenience.

Thanks,
Aakarsh

On 3/18/2026 3:54 PM, Miao, Jun wrote:
> Hi Marek
> Thanks a lot for the ACK on the swiotlb.
> It is very important to confirm the functionality. I really appreciate your review @ Marek
> 
> Maybe x86 maintainers would also like to hear your thoughts on this, especially since architectures like powerpc already have support for this.
> Any additional feedback or suggestions on X86 might have would be greatly appreciated.
> 
> Best regards,
> Jun Miao
> 
>> On 12.02.2026 10:37, Jun Miao wrote:
>>> Intel TDX guest wants to allocate a swiotlb buffer that is not
>>> restricted to low memory for the trusted hypervisor scheme.  Adding a
>>> new flag will be used in swiotlb_memblock_alloc() to allow allocation
>>> of SWIOTLB memory beyond low memory restriction.
>>>
>>> Power SVM already supports this, but X86 still faces the same limitation.
>>> Commit: 8ba2ed1be9 (swiotlb: add a SWIOTLB_ANY flag to lift the low
>>> memory restriction)
>>>
>>> Reviewed-by: Aakarsh Jain <aakarsh.jain@oss.qualcomm.com>
>>> Tested-by: Aakarsh Jain <aakarsh.jain@oss.qualcomm.com>
>>> Signed-off-by: Jun Miao <jun.miao@intel.com>
>>
>> Acked-by: Marek Szyprowski <m.szyprowski@samsung.com>
>>
>>> ---
>>>
>>> V1 -> V2:
>>> 1.Updated commit message and description.
>>> 2.Add Reviewed and Tested.
>>>
>>> V1 Latest Feedback :
>>> https://protect2.fireeye.com/v1/url?k=f35668f3-92dd7dc5-f357e3bc-74fe4
>>> 85cbff1-e6ff63e2f942f6a7&q=1&e=66eee4e1-a18d-47f9-ad21-
>> f3dfab1d6f09&u=
>>> https%3A%2F%2Flists.openwall.net%2Flinux-
>> kernel%2F2026%2F02%2F11%2F483
>>>
>>> v2 -> v3:
>>> We can alloc 4GB with the dynamic swiotlb, rather than 1GB.
>>> 1G is not correct. So change the commit log.
>>>
>>> ---
>>>    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
>>
>> Best regards
>> --
>> Marek Szyprowski, PhD
>> Samsung R&D Institute Poland
> 

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

[Borislav Petkov]

On Thu, Feb 12, 2026 at 05:37:01PM +0800, Jun Miao wrote:

+ Rick.

> Intel TDX guest wants to allocate a swiotlb buffer that is not restricted to
> low memory for the trusted hypervisor scheme.  Adding a new flag will be used
> in swiotlb_memblock_alloc() to allow allocation of SWIOTLB memory beyond low 
> memory restriction.
> 
> Power SVM already supports this, but X86 still faces the same limitation.

So?

> Commit: 8ba2ed1be9 (swiotlb: add a SWIOTLB_ANY flag to lift the low memory restriction)
> Reviewed-by: Aakarsh Jain <aakarsh.jain@oss.qualcomm.com>
> Tested-by: Aakarsh Jain <aakarsh.jain@oss.qualcomm.com>
> Signed-off-by: Jun Miao <jun.miao@intel.com>
> ---
> 
> V1 -> V2:
> 1.Updated commit message and description.
> 2.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.
> 
> ---
>  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;

This is not TDX-specific but introduces a change for all encrypted guests.

-- 
Regards/Gruss,
    Boris.

https://people.kernel.org/tglx/notes-about-netiquette

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

[Miao, Jun]

>On Thu, Feb 12, 2026 at 05:37:01PM +0800, Jun Miao wrote:
>
>+ Rick.
>
>> Intel TDX guest wants to allocate a swiotlb buffer that is not
>> restricted to low memory for the trusted hypervisor scheme.  Adding a
>> new flag will be used in swiotlb_memblock_alloc() to allow allocation
>> of SWIOTLB memory beyond low memory restriction.
>>
>> Power SVM already supports this, but X86 still faces the same limitation.
>
>So?
 
Hi, Boris.
Right,  please see  8ba2ed1be90f ("swiotlb: add a SWIOTLB_ANY flag to lift the low memory restriction")

Warm regards
Jun Miao
>
>> Commit: 8ba2ed1be9 (swiotlb: add a SWIOTLB_ANY flag to lift the low
>> memory restriction)
>> Reviewed-by: Aakarsh Jain <aakarsh.jain@oss.qualcomm.com>
>> Tested-by: Aakarsh Jain <aakarsh.jain@oss.qualcomm.com>
>> Signed-off-by: Jun Miao <jun.miao@intel.com>
>> ---
>>
>> V1 -> V2:
>> 1.Updated commit message and description.
>> 2.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.
>>
>> ---
>>  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;
>
>This is not TDX-specific but introduces a change for all encrypted guests.
>
>--
>Regards/Gruss,
>    Boris.
>
>https://people.kernel.org/tglx/notes-about-netiquette

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

[Borislav Petkov]

On Wed, Jun 24, 2026 at 01:22:33AM +0000, Miao, Jun wrote:
> >> 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;
> >
> >This is not TDX-specific but introduces a change for all encrypted guests.
^^^^^^^^^^^^

You need to read the whole email.

-- 
Regards/Gruss,
    Boris.

https://people.kernel.org/tglx/notes-about-netiquette

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

[Miao, Jun]

Warm regards
Jun Miao
>On Wed, Jun 24, 2026 at 01:22:33AM +0000, Miao, Jun wrote:
>> >> 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;
>> >
>> >This is not TDX-specific but introduces a change for all encrypted guests.
>^^^^^^^^^^^^
>
>You need to read the whole email.
Oh, I am so sorry . Aakarsh sent a single email to me writing that:

Hi Jun,

I think the commit message should indeed be updated to reflect that this change benefits all x86 encrypted guests, not just TDX. The condition `CC_ATTR_GUEST_MEM_ENCRYPT` covers AMD SEV, SEV-ES, SEV-SNP, and Intel TDX. I have tested this on AMD SEV-SNP and it works correctly.

Thanks,
Aakarsh

I replied to him as follows, could you take a look and see how my revisions turned out?
Thank you all for pointing this out.

Good suggestion and thank you for testing the ADM SEV-SNP.  
I will try V4 adding those to commit with your encouragement O(∩_∩)O. Like this ?

Confidential Virtual Machines (CVMs) include Intel TDX and AMD SEV, SEV-ES, SEV-SNP 
want to allocate a swiotlb buffer that is not restricted to low memory for
the trusted hypervisor scheme.  Adding a new flag will be used in swiotlb_memblock_alloc() 
to allow allocation of SWIOTLB memory beyond low memory restriction.

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

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

[Borislav Petkov]

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.

> Confidential Virtual Machines (CVMs) include Intel TDX and AMD SEV, SEV-ES, SEV-SNP 
> want to allocate a swiotlb buffer that is not restricted to low memory for

Why do they want that? The "why" is what I am missing in all this text.

> the trusted hypervisor scheme.

What is the "trusted hypervisor scheme"?

> Adding a new flag will be used in swiotlb_memblock_alloc() to allow
> allocation of SWIOTLB memory beyond low memory restriction.

That you don't need to explain - that's visible from the diff.

Thx.

-- 
Regards/Gruss,
    Boris.

https://people.kernel.org/tglx/notes-about-netiquette

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

[Miao, Jun]

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

>
>> Confidential Virtual Machines (CVMs) include Intel TDX and AMD SEV,
>> SEV-ES, SEV-SNP want to allocate a swiotlb buffer that is not
>> restricted to low memory for
>
>Why do they want that? The "why" is what I am missing in all this text.

This was an oversight on my part. I failed to explain the usage context:

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.

>
>> the trusted hypervisor scheme.
>
>What is the "trusted hypervisor scheme"?

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.

>
>> Adding a new flag will be used in swiotlb_memblock_alloc() to allow
>> allocation of SWIOTLB memory beyond low memory restriction.
>
>That you don't need to explain - that's visible from the diff.

Ok drop it!
What about the commit description like this in V4 ?

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.

Power SVM already supports this, but X86 still faces the same limitation.
Commit: 8ba2ed1be9 ( "swiotlb: add a SWIOTLB_ANY flag to lift the low memory restriction" )

>
>Thx.
>
>--
>Regards/Gruss,
>    Boris.
>
>https://people.kernel.org/tglx/notes-about-netiquette

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

[Borislav Petkov]

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

Thx.

-- 
Regards/Gruss,
    Boris.

https://people.kernel.org/tglx/notes-about-netiquette

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

[Aakarsh Jain]

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

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

[Borislav Petkov]

On Wed, Jun 24, 2026 at 11:24:42AM +0530, Aakarsh Jain 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.

Ok, pls send a Tested-by when Jun sends a new version of the patch.

Thx.

-- 
Regards/Gruss,
    Boris.

https://people.kernel.org/tglx/notes-about-netiquette

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

[Miao, Jun]

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

Hi Boris,
Thanks for getting involved and showing your support, I look forward to further updates from CC folks :-) 

I would also like to further thank Aakarsh for the detailed dmesg information about SEV-SNP:
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
... ...
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)

Warm regards
Jun Miao

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

[Alexey Kardashevskiy]

On 12/2/26 20:37, Jun Miao wrote:
> Intel TDX guest wants to allocate a swiotlb buffer that is not restricted to
> low memory for the trusted hypervisor scheme.  Adding a new flag will be used
> in swiotlb_memblock_alloc() to allow allocation of SWIOTLB memory beyond low
> memory restriction.

What about those devices with DMA masks < 64bit which needed swiotlb in the first place?

The DMA layer on coco VMs shares coherent memory (from anywhere), why focus on swiotlb alone?

Here is ongoing work to get rid of SWIOTLB_FORCE and do other things with swiotlb:
https://lore.kernel.org/r/20260604083959.1265923-1-aneesh.kumar@kernel.org

so this patch is likely to conflict with that series. Thanks,

> Power SVM already supports this, but X86 still faces the same limitation.
> Commit: 8ba2ed1be9 (swiotlb: add a SWIOTLB_ANY flag to lift the low memory restriction)
> 
> Reviewed-by: Aakarsh Jain <aakarsh.jain@oss.qualcomm.com>
> Tested-by: Aakarsh Jain <aakarsh.jain@oss.qualcomm.com>
> Signed-off-by: Jun Miao <jun.miao@intel.com>
> ---
> 
> V1 -> V2:
> 1.Updated commit message and description.
> 2.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.
> 
> ---
>   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

-- 
Alexey