[PATCH] swiotlb: Add swiotlb=off to disable SWIOTLB

[PATCH] swiotlb: Add swiotlb=off to disable SWIOTLB

[Florian Fainelli]

It may be useful to disable the SWIOTLB completely for testing or when a
platform is known not to have any DRAM addressing limitations what so
ever.

Signed-off-by: Florian Fainelli <f.fainelli@gmail.com>
---
 Documentation/admin-guide/kernel-parameters.txt | 1 +
 include/linux/swiotlb.h                         | 1 +
 kernel/dma/swiotlb.c                            | 9 +++++++++
 3 files changed, 11 insertions(+)

diff --git a/Documentation/admin-guide/kernel-parameters.txt b/Documentation/admin-guide/kernel-parameters.txt
index 04545725f187..b0223e48921e 100644
--- a/Documentation/admin-guide/kernel-parameters.txt
+++ b/Documentation/admin-guide/kernel-parameters.txt
@@ -5278,6 +5278,7 @@
 			force -- force using of bounce buffers even if they
 			         wouldn't be automatically used by the kernel
 			noforce -- Never use bounce buffers (for debugging)
+			off -- Completely disable SWIOTLB
 
 	switches=	[HW,M68k]
 
diff --git a/include/linux/swiotlb.h b/include/linux/swiotlb.h
index 5857a937c637..23f86243defe 100644
--- a/include/linux/swiotlb.h
+++ b/include/linux/swiotlb.h
@@ -15,6 +15,7 @@ enum swiotlb_force {
 	SWIOTLB_NORMAL,		/* Default - depending on HW DMA mask etc. */
 	SWIOTLB_FORCE,		/* swiotlb=force */
 	SWIOTLB_NO_FORCE,	/* swiotlb=noforce */
+	SWIOTLB_OFF,		/* swiotlb=off */
 };
 
 /*
diff --git a/kernel/dma/swiotlb.c b/kernel/dma/swiotlb.c
index c10e855a03bc..d7a4a789c7d3 100644
--- a/kernel/dma/swiotlb.c
+++ b/kernel/dma/swiotlb.c
@@ -126,6 +126,8 @@ setup_io_tlb_npages(char *str)
 	} else if (!strcmp(str, "noforce")) {
 		swiotlb_force = SWIOTLB_NO_FORCE;
 		io_tlb_nslabs = 1;
+	} else if (!strcmp(str, "off")) {
+		swiotlb_force = SWIOTLB_OFF;
 	}
 
 	return 0;
@@ -229,6 +231,9 @@ int __init swiotlb_init_with_tbl(char *tlb, unsigned long nslabs, int verbose)
 	unsigned long i, bytes;
 	size_t alloc_size;
 
+	if (swiotlb_force == SWIOTLB_OFF)
+		return 0;
+
 	bytes = nslabs << IO_TLB_SHIFT;
 
 	io_tlb_nslabs = nslabs;
@@ -284,6 +289,9 @@ swiotlb_init(int verbose)
 	unsigned char *vstart;
 	unsigned long bytes;
 
+	if (swiotlb_force == SWIOTLB_OFF)
+		goto out;
+
 	if (!io_tlb_nslabs) {
 		io_tlb_nslabs = (default_size >> IO_TLB_SHIFT);
 		io_tlb_nslabs = ALIGN(io_tlb_nslabs, IO_TLB_SEGSIZE);
@@ -302,6 +310,7 @@ swiotlb_init(int verbose)
 		io_tlb_start = 0;
 	}
 	pr_warn("Cannot allocate buffer");
+out:
 	no_iotlb_memory = true;
 }
 
-- 
2.25.1

Re: [PATCH] swiotlb: Add swiotlb=off to disable SWIOTLB

[Florian Fainelli]

On 3/18/2021 12:18 PM, Florian Fainelli wrote:
> It may be useful to disable the SWIOTLB completely for testing or when a
> platform is known not to have any DRAM addressing limitations what so
> ever.
> 
> Signed-off-by: Florian Fainelli <f.fainelli@gmail.com>

Christoph, in addition to this change, how would you feel if we
qualified the swiotlb_init() in arch/arm/mm/init.c with a:


if (memblock_end_of_DRAM() >= SZ_4G)
	swiotlb_init(1)

right now this is made unconditional whenever ARM_LPAE is enabled which
is the case for the platforms I maintain (ARCH_BRCMSTB) however we do
not really need a SWIOTLB so long as the largest DRAM physical address
does not exceed 4GB AFAICT.

Thanks!

> ---
>  Documentation/admin-guide/kernel-parameters.txt | 1 +
>  include/linux/swiotlb.h                         | 1 +
>  kernel/dma/swiotlb.c                            | 9 +++++++++
>  3 files changed, 11 insertions(+)
> 
> diff --git a/Documentation/admin-guide/kernel-parameters.txt b/Documentation/admin-guide/kernel-parameters.txt
> index 04545725f187..b0223e48921e 100644
> --- a/Documentation/admin-guide/kernel-parameters.txt
> +++ b/Documentation/admin-guide/kernel-parameters.txt
> @@ -5278,6 +5278,7 @@
>  			force -- force using of bounce buffers even if they
>  			         wouldn't be automatically used by the kernel
>  			noforce -- Never use bounce buffers (for debugging)
> +			off -- Completely disable SWIOTLB
>  
>  	switches=	[HW,M68k]
>  
> diff --git a/include/linux/swiotlb.h b/include/linux/swiotlb.h
> index 5857a937c637..23f86243defe 100644
> --- a/include/linux/swiotlb.h
> +++ b/include/linux/swiotlb.h
> @@ -15,6 +15,7 @@ enum swiotlb_force {
>  	SWIOTLB_NORMAL,		/* Default - depending on HW DMA mask etc. */
>  	SWIOTLB_FORCE,		/* swiotlb=force */
>  	SWIOTLB_NO_FORCE,	/* swiotlb=noforce */
> +	SWIOTLB_OFF,		/* swiotlb=off */
>  };
>  
>  /*
> diff --git a/kernel/dma/swiotlb.c b/kernel/dma/swiotlb.c
> index c10e855a03bc..d7a4a789c7d3 100644
> --- a/kernel/dma/swiotlb.c
> +++ b/kernel/dma/swiotlb.c
> @@ -126,6 +126,8 @@ setup_io_tlb_npages(char *str)
>  	} else if (!strcmp(str, "noforce")) {
>  		swiotlb_force = SWIOTLB_NO_FORCE;
>  		io_tlb_nslabs = 1;
> +	} else if (!strcmp(str, "off")) {
> +		swiotlb_force = SWIOTLB_OFF;
>  	}
>  
>  	return 0;
> @@ -229,6 +231,9 @@ int __init swiotlb_init_with_tbl(char *tlb, unsigned long nslabs, int verbose)
>  	unsigned long i, bytes;
>  	size_t alloc_size;
>  
> +	if (swiotlb_force == SWIOTLB_OFF)
> +		return 0;
> +
>  	bytes = nslabs << IO_TLB_SHIFT;
>  
>  	io_tlb_nslabs = nslabs;
> @@ -284,6 +289,9 @@ swiotlb_init(int verbose)
>  	unsigned char *vstart;
>  	unsigned long bytes;
>  
> +	if (swiotlb_force == SWIOTLB_OFF)
> +		goto out;
> +
>  	if (!io_tlb_nslabs) {
>  		io_tlb_nslabs = (default_size >> IO_TLB_SHIFT);
>  		io_tlb_nslabs = ALIGN(io_tlb_nslabs, IO_TLB_SEGSIZE);
> @@ -302,6 +310,7 @@ swiotlb_init(int verbose)
>  		io_tlb_start = 0;
>  	}
>  	pr_warn("Cannot allocate buffer");
> +out:
>  	no_iotlb_memory = true;
>  }
>  
> 

-- 
Florian

Re: [PATCH] swiotlb: Add swiotlb=off to disable SWIOTLB

[Robin Murphy]

On 2021-03-18 19:22, Florian Fainelli wrote:
> 
> 
> On 3/18/2021 12:18 PM, Florian Fainelli wrote:
>> It may be useful to disable the SWIOTLB completely for testing or when a
>> platform is known not to have any DRAM addressing limitations what so
>> ever.

Isn't that what "swiotlb=noforce" is for? If you're confident that we've 
really ironed out *all* the awkward corners that used to blow up if 
various internal bits were left uninitialised, then it would make sense 
to just tweak the implementation of what we already have.

I wouldn't necessarily disagree with adding "off" as an additional alias 
for "noforce", though, since it does come across as a bit wacky for 
general use.

>> Signed-off-by: Florian Fainelli <f.fainelli@gmail.com>
> 
> Christoph, in addition to this change, how would you feel if we
> qualified the swiotlb_init() in arch/arm/mm/init.c with a:
> 
> 
> if (memblock_end_of_DRAM() >= SZ_4G)
> 	swiotlb_init(1)

Modulo "swiotlb=force", of course ;)

Robin.

> right now this is made unconditional whenever ARM_LPAE is enabled which
> is the case for the platforms I maintain (ARCH_BRCMSTB) however we do
> not really need a SWIOTLB so long as the largest DRAM physical address
> does not exceed 4GB AFAICT.
> 
> Thanks!
> 
>> ---
>>   Documentation/admin-guide/kernel-parameters.txt | 1 +
>>   include/linux/swiotlb.h                         | 1 +
>>   kernel/dma/swiotlb.c                            | 9 +++++++++
>>   3 files changed, 11 insertions(+)
>>
>> diff --git a/Documentation/admin-guide/kernel-parameters.txt b/Documentation/admin-guide/kernel-parameters.txt
>> index 04545725f187..b0223e48921e 100644
>> --- a/Documentation/admin-guide/kernel-parameters.txt
>> +++ b/Documentation/admin-guide/kernel-parameters.txt
>> @@ -5278,6 +5278,7 @@
>>   			force -- force using of bounce buffers even if they
>>   			         wouldn't be automatically used by the kernel
>>   			noforce -- Never use bounce buffers (for debugging)
>> +			off -- Completely disable SWIOTLB
>>   
>>   	switches=	[HW,M68k]
>>   
>> diff --git a/include/linux/swiotlb.h b/include/linux/swiotlb.h
>> index 5857a937c637..23f86243defe 100644
>> --- a/include/linux/swiotlb.h
>> +++ b/include/linux/swiotlb.h
>> @@ -15,6 +15,7 @@ enum swiotlb_force {
>>   	SWIOTLB_NORMAL,		/* Default - depending on HW DMA mask etc. */
>>   	SWIOTLB_FORCE,		/* swiotlb=force */
>>   	SWIOTLB_NO_FORCE,	/* swiotlb=noforce */
>> +	SWIOTLB_OFF,		/* swiotlb=off */
>>   };
>>   
>>   /*
>> diff --git a/kernel/dma/swiotlb.c b/kernel/dma/swiotlb.c
>> index c10e855a03bc..d7a4a789c7d3 100644
>> --- a/kernel/dma/swiotlb.c
>> +++ b/kernel/dma/swiotlb.c
>> @@ -126,6 +126,8 @@ setup_io_tlb_npages(char *str)
>>   	} else if (!strcmp(str, "noforce")) {
>>   		swiotlb_force = SWIOTLB_NO_FORCE;
>>   		io_tlb_nslabs = 1;
>> +	} else if (!strcmp(str, "off")) {
>> +		swiotlb_force = SWIOTLB_OFF;
>>   	}
>>   
>>   	return 0;
>> @@ -229,6 +231,9 @@ int __init swiotlb_init_with_tbl(char *tlb, unsigned long nslabs, int verbose)
>>   	unsigned long i, bytes;
>>   	size_t alloc_size;
>>   
>> +	if (swiotlb_force == SWIOTLB_OFF)
>> +		return 0;
>> +
>>   	bytes = nslabs << IO_TLB_SHIFT;
>>   
>>   	io_tlb_nslabs = nslabs;
>> @@ -284,6 +289,9 @@ swiotlb_init(int verbose)
>>   	unsigned char *vstart;
>>   	unsigned long bytes;
>>   
>> +	if (swiotlb_force == SWIOTLB_OFF)
>> +		goto out;
>> +
>>   	if (!io_tlb_nslabs) {
>>   		io_tlb_nslabs = (default_size >> IO_TLB_SHIFT);
>>   		io_tlb_nslabs = ALIGN(io_tlb_nslabs, IO_TLB_SEGSIZE);
>> @@ -302,6 +310,7 @@ swiotlb_init(int verbose)
>>   		io_tlb_start = 0;
>>   	}
>>   	pr_warn("Cannot allocate buffer");
>> +out:
>>   	no_iotlb_memory = true;
>>   }
>>   
>>
> 

Re: [PATCH] swiotlb: Add swiotlb=off to disable SWIOTLB

[Florian Fainelli]

On 3/18/2021 12:34 PM, Robin Murphy wrote:
> On 2021-03-18 19:22, Florian Fainelli wrote:
>>
>>
>> On 3/18/2021 12:18 PM, Florian Fainelli wrote:
>>> It may be useful to disable the SWIOTLB completely for testing or when a
>>> platform is known not to have any DRAM addressing limitations what so
>>> ever.
> 
> Isn't that what "swiotlb=noforce" is for? If you're confident that we've
> really ironed out *all* the awkward corners that used to blow up if
> various internal bits were left uninitialised, then it would make sense
> to just tweak the implementation of what we already have.

swiotlb=noforce does prevent dma_direct_map_page() from resorting to the
swiotlb, however what I am also after is reclaiming these 64MB of
default SWIOTLB bounce buffering memory because my systems run with
large amounts of reserved memory into ZONE_MOVABLE and everything in
ZONE_NORMAL is precious at that point.

> 
> I wouldn't necessarily disagree with adding "off" as an additional alias
> for "noforce", though, since it does come across as a bit wacky for
> general use.
> 
>>> Signed-off-by: Florian Fainelli <f.fainelli@gmail.com>
>>
>> Christoph, in addition to this change, how would you feel if we
>> qualified the swiotlb_init() in arch/arm/mm/init.c with a:
>>
>>
>> if (memblock_end_of_DRAM() >= SZ_4G)
>>     swiotlb_init(1)
> 
> Modulo "swiotlb=force", of course ;)

Indeed, we would need to handle that case as well. Does it sound
reasonable to do that to you as well?
-- 
Florian

Re: [PATCH] swiotlb: Add swiotlb=off to disable SWIOTLB

[Robin Murphy]

On 2021-03-18 19:43, Florian Fainelli wrote:
> 
> 
> On 3/18/2021 12:34 PM, Robin Murphy wrote:
>> On 2021-03-18 19:22, Florian Fainelli wrote:
>>>
>>>
>>> On 3/18/2021 12:18 PM, Florian Fainelli wrote:
>>>> It may be useful to disable the SWIOTLB completely for testing or when a
>>>> platform is known not to have any DRAM addressing limitations what so
>>>> ever.
>>
>> Isn't that what "swiotlb=noforce" is for? If you're confident that we've
>> really ironed out *all* the awkward corners that used to blow up if
>> various internal bits were left uninitialised, then it would make sense
>> to just tweak the implementation of what we already have.
> 
> swiotlb=noforce does prevent dma_direct_map_page() from resorting to the
> swiotlb, however what I am also after is reclaiming these 64MB of
> default SWIOTLB bounce buffering memory because my systems run with
> large amounts of reserved memory into ZONE_MOVABLE and everything in
> ZONE_NORMAL is precious at that point.

It also forces io_tlb_nslabs to the minimum, so it should be claiming 
considerably less than 64MB. IIRC the original proposal *did* skip 
initialisation completely, but that turned up the aforementioned issues.

>> I wouldn't necessarily disagree with adding "off" as an additional alias
>> for "noforce", though, since it does come across as a bit wacky for
>> general use.
>>
>>>> Signed-off-by: Florian Fainelli <f.fainelli@gmail.com>
>>>
>>> Christoph, in addition to this change, how would you feel if we
>>> qualified the swiotlb_init() in arch/arm/mm/init.c with a:
>>>
>>>
>>> if (memblock_end_of_DRAM() >= SZ_4G)
>>>      swiotlb_init(1)
>>
>> Modulo "swiotlb=force", of course ;)
> 
> Indeed, we would need to handle that case as well. Does it sound
> reasonable to do that to you as well?

I wouldn't like it done to me personally, but for arm64, observe what 
mem_init() in arch/arm64/mm/init.c already does.

Robin.

Re: [PATCH] swiotlb: Add swiotlb=off to disable SWIOTLB

[Florian Fainelli]

On 3/18/2021 12:53 PM, Robin Murphy wrote:
> On 2021-03-18 19:43, Florian Fainelli wrote:
>>
>>
>> On 3/18/2021 12:34 PM, Robin Murphy wrote:
>>> On 2021-03-18 19:22, Florian Fainelli wrote:
>>>>
>>>>
>>>> On 3/18/2021 12:18 PM, Florian Fainelli wrote:
>>>>> It may be useful to disable the SWIOTLB completely for testing or
>>>>> when a
>>>>> platform is known not to have any DRAM addressing limitations what so
>>>>> ever.
>>>
>>> Isn't that what "swiotlb=noforce" is for? If you're confident that we've
>>> really ironed out *all* the awkward corners that used to blow up if
>>> various internal bits were left uninitialised, then it would make sense
>>> to just tweak the implementation of what we already have.
>>
>> swiotlb=noforce does prevent dma_direct_map_page() from resorting to the
>> swiotlb, however what I am also after is reclaiming these 64MB of
>> default SWIOTLB bounce buffering memory because my systems run with
>> large amounts of reserved memory into ZONE_MOVABLE and everything in
>> ZONE_NORMAL is precious at that point.
> 
> It also forces io_tlb_nslabs to the minimum, so it should be claiming
> considerably less than 64MB. IIRC the original proposal *did* skip
> initialisation completely, but that turned up the aforementioned issues.

AFAICT in that case we will have iotlb_n_slabs will set to 1, which will
still make us allocate io_tlb_n_slabs << IO_TLB_SHIFT bytes in
swiotlb_init(), which still gives us 64MB.

> 
>>> I wouldn't necessarily disagree with adding "off" as an additional alias
>>> for "noforce", though, since it does come across as a bit wacky for
>>> general use.
>>>
>>>>> Signed-off-by: Florian Fainelli <f.fainelli@gmail.com>
>>>>
>>>> Christoph, in addition to this change, how would you feel if we
>>>> qualified the swiotlb_init() in arch/arm/mm/init.c with a:
>>>>
>>>>
>>>> if (memblock_end_of_DRAM() >= SZ_4G)
>>>>      swiotlb_init(1)
>>>
>>> Modulo "swiotlb=force", of course ;)
>>
>> Indeed, we would need to handle that case as well. Does it sound
>> reasonable to do that to you as well?
> 
> I wouldn't like it done to me personally, but for arm64, observe what
> mem_init() in arch/arm64/mm/init.c already does.
> 
> Robin.

-- 
Florian

Re: [PATCH] swiotlb: Add swiotlb=off to disable SWIOTLB

[Robin Murphy]

On 2021-03-18 21:31, Florian Fainelli wrote:
> 
> 
> On 3/18/2021 12:53 PM, Robin Murphy wrote:
>> On 2021-03-18 19:43, Florian Fainelli wrote:
>>>
>>>
>>> On 3/18/2021 12:34 PM, Robin Murphy wrote:
>>>> On 2021-03-18 19:22, Florian Fainelli wrote:
>>>>>
>>>>>
>>>>> On 3/18/2021 12:18 PM, Florian Fainelli wrote:
>>>>>> It may be useful to disable the SWIOTLB completely for testing or
>>>>>> when a
>>>>>> platform is known not to have any DRAM addressing limitations what so
>>>>>> ever.
>>>>
>>>> Isn't that what "swiotlb=noforce" is for? If you're confident that we've
>>>> really ironed out *all* the awkward corners that used to blow up if
>>>> various internal bits were left uninitialised, then it would make sense
>>>> to just tweak the implementation of what we already have.
>>>
>>> swiotlb=noforce does prevent dma_direct_map_page() from resorting to the
>>> swiotlb, however what I am also after is reclaiming these 64MB of
>>> default SWIOTLB bounce buffering memory because my systems run with
>>> large amounts of reserved memory into ZONE_MOVABLE and everything in
>>> ZONE_NORMAL is precious at that point.
>>
>> It also forces io_tlb_nslabs to the minimum, so it should be claiming
>> considerably less than 64MB. IIRC the original proposal *did* skip
>> initialisation completely, but that turned up the aforementioned issues.
> 
> AFAICT in that case we will have iotlb_n_slabs will set to 1, which will
> still make us allocate io_tlb_n_slabs << IO_TLB_SHIFT bytes in
> swiotlb_init(), which still gives us 64MB.

Eh? When did 2KB become 64MB? IO_TLB_SHIFT is 11, so that's at most one 
page in anyone's money...

>>>> I wouldn't necessarily disagree with adding "off" as an additional alias
>>>> for "noforce", though, since it does come across as a bit wacky for
>>>> general use.
>>>>
>>>>>> Signed-off-by: Florian Fainelli <f.fainelli@gmail.com>
>>>>>
>>>>> Christoph, in addition to this change, how would you feel if we
>>>>> qualified the swiotlb_init() in arch/arm/mm/init.c with a:
>>>>>
>>>>>
>>>>> if (memblock_end_of_DRAM() >= SZ_4G)
>>>>>       swiotlb_init(1)
>>>>
>>>> Modulo "swiotlb=force", of course ;)
>>>
>>> Indeed, we would need to handle that case as well. Does it sound
>>> reasonable to do that to you as well?
>>
>> I wouldn't like it done to me personally, but for arm64, observe what
>> mem_init() in arch/arm64/mm/init.c already does.

In fact I should have looked more closely at that myself - checking 
debugfs on my 4GB arm64 board actually shows io_tlb_nslabs = 0, and 
indeed we are bypassing initialisation completely and (ab)using 
SWIOTLB_NO_FORCE to cover it up, so I guess it probably *is* safe now 
for the noforce option to do the same for itself and save even that one 
page.

Robin.

Re: [PATCH] swiotlb: Add swiotlb=off to disable SWIOTLB

[Florian Fainelli]

On 3/18/2021 4:35 PM, Robin Murphy wrote:
> On 2021-03-18 21:31, Florian Fainelli wrote:
>>
>>
>> On 3/18/2021 12:53 PM, Robin Murphy wrote:
>>> On 2021-03-18 19:43, Florian Fainelli wrote:
>>>>
>>>>
>>>> On 3/18/2021 12:34 PM, Robin Murphy wrote:
>>>>> On 2021-03-18 19:22, Florian Fainelli wrote:
>>>>>>
>>>>>>
>>>>>> On 3/18/2021 12:18 PM, Florian Fainelli wrote:
>>>>>>> It may be useful to disable the SWIOTLB completely for testing or
>>>>>>> when a
>>>>>>> platform is known not to have any DRAM addressing limitations
>>>>>>> what so
>>>>>>> ever.
>>>>>
>>>>> Isn't that what "swiotlb=noforce" is for? If you're confident that
>>>>> we've
>>>>> really ironed out *all* the awkward corners that used to blow up if
>>>>> various internal bits were left uninitialised, then it would make
>>>>> sense
>>>>> to just tweak the implementation of what we already have.
>>>>
>>>> swiotlb=noforce does prevent dma_direct_map_page() from resorting to
>>>> the
>>>> swiotlb, however what I am also after is reclaiming these 64MB of
>>>> default SWIOTLB bounce buffering memory because my systems run with
>>>> large amounts of reserved memory into ZONE_MOVABLE and everything in
>>>> ZONE_NORMAL is precious at that point.
>>>
>>> It also forces io_tlb_nslabs to the minimum, so it should be claiming
>>> considerably less than 64MB. IIRC the original proposal *did* skip
>>> initialisation completely, but that turned up the aforementioned issues.
>>
>> AFAICT in that case we will have iotlb_n_slabs will set to 1, which will
>> still make us allocate io_tlb_n_slabs << IO_TLB_SHIFT bytes in
>> swiotlb_init(), which still gives us 64MB.
> 
> Eh? When did 2KB become 64MB? IO_TLB_SHIFT is 11, so that's at most one
> page in anyone's money...

Yes, sorry incorrect shift applied here. Still, and I believe this is
what you mean below, architecture code setting swiotlb_force =
SWIOTLB_NO_FORCE does not result in not allocating the SWIOTLB, because
io_tlb_nslabs is still left set to 0 so swiotlb_init() will proceed with
allocating the default size.

> 
>>>>> I wouldn't necessarily disagree with adding "off" as an additional
>>>>> alias
>>>>> for "noforce", though, since it does come across as a bit wacky for
>>>>> general use.
>>>>>
>>>>>>> Signed-off-by: Florian Fainelli <f.fainelli@gmail.com>
>>>>>>
>>>>>> Christoph, in addition to this change, how would you feel if we
>>>>>> qualified the swiotlb_init() in arch/arm/mm/init.c with a:
>>>>>>
>>>>>>
>>>>>> if (memblock_end_of_DRAM() >= SZ_4G)
>>>>>>       swiotlb_init(1)
>>>>>
>>>>> Modulo "swiotlb=force", of course ;)
>>>>
>>>> Indeed, we would need to handle that case as well. Does it sound
>>>> reasonable to do that to you as well?
>>>
>>> I wouldn't like it done to me personally, but for arm64, observe what
>>> mem_init() in arch/arm64/mm/init.c already does.
> 
> In fact I should have looked more closely at that myself - checking
> debugfs on my 4GB arm64 board actually shows io_tlb_nslabs = 0, and
> indeed we are bypassing initialisation completely and (ab)using
> SWIOTLB_NO_FORCE to cover it up, so I guess it probably *is* safe now
> for the noforce option to do the same for itself and save even that one
> page.

OK, I can submit a patch that does that. 5.12-rc3 works correctly for me
here as well and only allocates SWIOTLB when needed which in our case is
either:

- we have DRAM at PA >= 4GB
- we have limited peripherals (Raspberry Pi 4 derivative) that can only
address the lower 1GB

Now let's see if we can get ARM 32-bit to match :)
-- 
Florian

Re: [PATCH] swiotlb: Add swiotlb=off to disable SWIOTLB

[Konrad Rzeszutek Wilk]

> > 
> > In fact I should have looked more closely at that myself - checking
> > debugfs on my 4GB arm64 board actually shows io_tlb_nslabs = 0, and
> > indeed we are bypassing initialisation completely and (ab)using
> > SWIOTLB_NO_FORCE to cover it up, so I guess it probably *is* safe now
> > for the noforce option to do the same for itself and save even that one
> > page.
> 
> OK, I can submit a patch that does that. 5.12-rc3 works correctly for me
> here as well and only allocates SWIOTLB when needed which in our case is
> either:
> 
> - we have DRAM at PA >= 4GB
> - we have limited peripherals (Raspberry Pi 4 derivative) that can only
> address the lower 1GB
> 
> Now let's see if we can get ARM 32-bit to match :)

Whatever patch you come up with, if it is against SWIOTLB please base it on top of
devel/for-linus-5.12 in https://git.kernel.org/pub/scm/linux/kernel/git/konrad/swiotlb.git/

Thx
> -- 
> Florian