[PATCH] swiotlb: add a SWIOTLB_ANY flag to lift restricted low memory for encryption

[PATCH] swiotlb: add a SWIOTLB_ANY flag to lift restricted low memory for encryption

[Jun Miao]

TDX guest wants to allocate a swiotlb buffer that is not restricted
to low memory for the trusted hypervisor scheme. So that allow to pick
a location everywhere for hypervisors with guest memory encryption in
swiotlb_memblock_alloc() interface by adding a new flag.

Signed-off-by: Jun Miao <jun.miao@intel.com>
---
 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.43.0

RE: [PATCH] swiotlb: add a SWIOTLB_ANY flag to lift restricted low memory for encryption

[Miao, Jun]

Hi maintainers and Big shot,
I would like to further explain my original intention:
The purpose is to solve the problem found by customers when inserting 8 NVMe disks - There will be a swiotlb buffer full warning. 
When CONFIG_SWIOTLB_DYNAMIC is turned on, it is impossible to allocate more than 2G swiotlb buffer to meet the actual high throughput usage requirements. 

Warm regards
Jun Miao
>
>TDX guest wants to allocate a swiotlb buffer that is not restricted to low memory
>for the trusted hypervisor scheme. So that allow to pick a location everywhere for
>hypervisors with guest memory encryption in
>swiotlb_memblock_alloc() interface by adding a new flag.
>
>Signed-off-by: Jun Miao <jun.miao@intel.com>
>---
> 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.43.0

Re: [PATCH] swiotlb: add a SWIOTLB_ANY flag to lift restricted low memory for encryption

[Aakarsh Jain]

Hi Jun,

On 4/29/2025 10:23 PM, Jun Miao wrote:
> TDX guest wants to allocate a swiotlb buffer that is not restricted
> to low memory for the trusted hypervisor scheme. So that allow to pick
> a location everywhere for hypervisors with guest memory encryption in
> swiotlb_memblock_alloc() interface by adding a new flag.
> 
> Signed-off-by: Jun Miao <jun.miao@intel.com>
> ---
>   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


Thanks for working on this patch.

We ran into the same limitation where the SWIOTLB bounce buffer cannot
be increased beyond 1GB without this change.

I reviewed the change and tested it on our setup. With this patch 
applied, we are able to successfully configure and use SWIOTLB bounce 
buffer size greater than 1GB, and the previous allocation failures are 
resolved.

Since, I wanted to bring more visibility to this patch.

Feel free to add
Reviewed-by: Aakarsh Jain <aakarsh.jain@oss.qualcomm.com>
Tested-by: Aakarsh Jain <aakarsh.jain@oss.qualcomm.com>


Thanks,
Aakarsh

RE: [PATCH] swiotlb: add a SWIOTLB_ANY flag to lift restricted low memory for encryption

[Miao, Jun]

Hi Aakarsh,

I’m glad to hear that this patch helps solve a real issue on your side, as this was also a problem I encountered.
I appreciate your support and the Reviewed-by/Tested-by tags.

Hi Maintainers, 
I am not sure whether I should send a v2 of the patch to add the Reviewed-by/Tested-by tags myself?
or if the maintainer will add them when applying the patch ?

Also, if there are any incorrect or misleading descriptions in commit log? I would really appreciate your guidance and suggestions.

Thanks 
Jun Miao

>Hi Jun,
>
>On 4/29/2025 10:23 PM, Jun Miao wrote:
>> TDX guest wants to allocate a swiotlb buffer that is not restricted to
>> low memory for the trusted hypervisor scheme. So that allow to pick a
>> location everywhere for hypervisors with guest memory encryption in
>> swiotlb_memblock_alloc() interface by adding a new flag.
>>
>> Signed-off-by: Jun Miao <jun.miao@intel.com>
>> ---
>>   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
>
>
>Thanks for working on this patch.
>
>We ran into the same limitation where the SWIOTLB bounce buffer cannot be
>increased beyond 1GB without this change.
>
>I reviewed the change and tested it on our setup. With this patch applied, we are
>able to successfully configure and use SWIOTLB bounce buffer size greater than
>1GB, and the previous allocation failures are resolved.
>
>Since, I wanted to bring more visibility to this patch.
>
>Feel free to add
>Reviewed-by: Aakarsh Jain <aakarsh.jain@oss.qualcomm.com>
>Tested-by: Aakarsh Jain <aakarsh.jain@oss.qualcomm.com>
> 
Hi Aakarsh,

I’m glad to hear that this patch helps solve a real issue on your side, as this was also a problem I encountered.
I appreciate your support and the Reviewed-by/Tested-by tags.

Hi Maintainers, 
I am not sure whether I should send a v2 of the patch to add the Reviewed-by/Tested-by tags myself?
or if the maintainer will add them when applying the patch ?

Also, if there are any incorrect or misleading descriptions in commit log? I would really appreciate your guidance and suggestions.

Thanks 
Jun Miao

>
>Thanks,
>Aakarsh