[PATCH v2 2/3] arm64: memset-arm64: Use simple memset when cache is disabled

[Rasmus Villemoes]

On 10/08/2021 09.13, Stefan Roese wrote:
> The optimized memset uses the dc opcode, which causes problems when the
> cache is disabled. This patch adds a check if the cache is disabled and
> uses a very simple memset implementation in this case. Otherwise the
> optimized version is used.
> 
> Signed-off-by: Stefan Roese <sr at denx.de>
> 
> ---
> 
> Changes in v2:
> - New patch
> 
>  arch/arm/lib/memset-arm64.S | 30 ++++++++++++++++++++++++++++++
>  1 file changed, 30 insertions(+)
> 
> diff --git a/arch/arm/lib/memset-arm64.S b/arch/arm/lib/memset-arm64.S
> index 710f6f582cad..a474dcb53c83 100644
> --- a/arch/arm/lib/memset-arm64.S
> +++ b/arch/arm/lib/memset-arm64.S
> @@ -11,6 +11,7 @@
>   *
>   */
>  
> +#include <asm/macro.h>
>  #include "asmdefs.h"
>  
>  #define dstin	x0
> @@ -25,6 +26,35 @@ ENTRY (memset)
>  	PTR_ARG (0)
>  	SIZE_ARG (2)
>  
> +	/*
> +	 * The optimized memset uses the dc opcode, which causes problems
> +	 * when the cache is disabled. Let's check if the cache is disabled
> +	 * and use a very simple memset implementation in this case. Otherwise
> +	 * jump to the optimized version.
> +	 */
> +	switch_el x6, 3f, 2f, 1f
> +3:	mrs	x6, sctlr_el3
> +	b	0f
> +2:	mrs	x6, sctlr_el2
> +	b	0f
> +1:	mrs	x6, sctlr_el1
> +0:
> +	tst	x6, #CR_C
> +	bne	9f

How costly is this switch_el and access to a control register? For a
"big" memset of several 100s of bytes I'm sure it's a net win
regardless. But smaller memsets are much more common, and no individual
memset would show up in any boot time "profiling", but it is possible
that the extra cost added to those smaller memsets adds up to some
significant penalty.

> +	/*
> +	 * A very "simple" memset implementation without the use of the
> +	 * dc opcode. Can be run with caches disabled.
> +	 */
> +	mov	x3, #0x0
> +4:	strb	w1, [x0, x3]
> +	add	x3, x3, #0x1
> +	cmp	x2, x3
> +	bne	4b
> +	ret
> +9:
> +

So I can hardly claim to be fluent in aarch64, but AFAICT this does
return the destination pointer as it must (because it leaves x0
untouched throughout). However, it fails (by writing over all of memory)
when the size is 0, since it is essentially a do{}while and not a while{}.

Rasmus