public inbox for linux-arm-kernel@lists.infradead.org
 help / color / mirror / Atom feed
From: mark.rutland@arm.com (Mark Rutland)
To: linux-arm-kernel@lists.infradead.org
Subject: [PATCH] arm64: mm: take CWG into account in __inval_cache_range()
Date: Tue, 19 Apr 2016 13:56:16 +0100	[thread overview]
Message-ID: <20160419125615.GA20991@leverpostej> (raw)
In-Reply-To: <1461061773-19571-1-git-send-email-ard.biesheuvel@linaro.org>

Hi,

On Tue, Apr 19, 2016 at 12:29:33PM +0200, Ard Biesheuvel wrote:
> Currently, the arm64 implementation of __inval_cache_range() [aka
> __dma_inv_range()] takes CTR_EL0.Dminline into account for two purposes:
> - the stride to use for doing by-VA cache maintenance,
> - to check whether the start and end arguments are unaligned with respect
>   to the cache line size, in which case the unaligned extremes need to be
>   cleaned before being invalidated, to avoid corrupting adjacent unrelated
>   memory contents.
>
> In the second case, the use of Dminline is incorrect, and should use the
> CWG field instead, since an invalidate operation could result in cache
> lines that are larger than Dminline to be evicted at any level of the
> cache hierarchy.

Have you seen this in practice, or was this found by inspection?

I agree that we need to round addresses to CWG boundaries when
performing maintenance to the PoC to prevent subsequent asynchronous
writebacks of data falling in the same CWG, which could clobber data at
the PoC.

However, if we have unrelated data in the same CWG, surely we have no
guarantee that said data will not be dirtied in caches by other kernel
code, and thus we may still have issues with asynchronous writebacks?

Is sharing a CWG broken by design, or is there some caveat I'm missing
that prevents/prohibits unrelated data from being dirtied?

Thanks,
Mark.

> So introduce a macro cache_cwg_size to retrieve the CWG value, and use it
> to clean as many cachelines as required on either end of the [start, end)
> interval.
> 
> Signed-off-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
> ---
>  arch/arm64/mm/cache.S       | 34 ++++++++++++++++++++++------------
>  arch/arm64/mm/proc-macros.S | 13 +++++++++++++
>  2 files changed, 35 insertions(+), 12 deletions(-)
> 
> diff --git a/arch/arm64/mm/cache.S b/arch/arm64/mm/cache.S
> index 6df07069a025..e5067e87e1b5 100644
> --- a/arch/arm64/mm/cache.S
> +++ b/arch/arm64/mm/cache.S
> @@ -120,19 +120,29 @@ ENTRY(__inval_cache_range)
>   *	- end     - virtual end address of region
>   */
>  __dma_inv_range:
> -	dcache_line_size x2, x3
> -	sub	x3, x2, #1
> -	tst	x1, x3				// end cache line aligned?
> -	bic	x1, x1, x3
> -	b.eq	1f
> -	dc	civac, x1			// clean & invalidate D / U line
> -1:	tst	x0, x3				// start cache line aligned?
> -	bic	x0, x0, x3
> +	dcache_line_size x2, x3			// get Dminline in x2
> +	sub	x3, x2, #1			// Dminline mask in x3
> +	bic	x0, x0, x3			// align start down to line size
> +
> +	cache_cwg_size x4, x3			// get CWG
> +	sub	x3, x4, #1			// CWG mask in x3
> +
> +	tst	x1, x3				// end CWG aligned?
>  	b.eq	2f
> -	dc	civac, x0			// clean & invalidate D / U line
> -	b	3f
> -2:	dc	ivac, x0			// invalidate D / U line
> -3:	add	x0, x0, x2
> +	bic	x5, x1, x3
> +0:	dc	civac, x5			// clean & invalidate D / U line
> +	add	x5, x5, x2
> +	tst	x5, x3
> +	b.ne	0b
> +	b	2f
> +
> +1:	dc	civac, x0			// clean & invalidate D / U line
> +	add	x0, x0, x2
> +2:	tst	x0, x3				// start CWG aligned?
> +	b.ne	1b
> +
> +	dc	ivac, x0			// invalidate D / U line
> +	add	x0, x0, x2
>  	cmp	x0, x1
>  	b.lo	2b
>  	dsb	sy
> diff --git a/arch/arm64/mm/proc-macros.S b/arch/arm64/mm/proc-macros.S
> index e6a30e1268a8..872299ce3081 100644
> --- a/arch/arm64/mm/proc-macros.S
> +++ b/arch/arm64/mm/proc-macros.S
> @@ -54,6 +54,19 @@
>  	.endm
>  
>  /*
> + * cache_cwg_size - get the maximum cache line size from the CTR register
> + */
> +	.macro	cache_cwg_size, reg, tmp
> +	mrs	\tmp, ctr_el0			// read CTR
> +	ubfm	\tmp, \tmp, #24, #27		// CTR_EL0.CWG [27:24]
> +	mov	\reg, #9			// use architectural default of
> +	cmp	\tmp, xzr			// 2 KB (2^9 words) if CWG is
> +	csel	\tmp, \tmp, \reg, ne		// not provided
> +	mov	\reg, #4			// bytes per word
> +	lsl	\reg, \reg, \tmp		// actual cache line size
> +	.endm
> +
> +/*
>   * tcr_set_idmap_t0sz - update TCR.T0SZ so that we can load the ID map
>   */
>  	.macro	tcr_set_idmap_t0sz, valreg, tmpreg
> -- 
> 2.5.0
> 

  reply	other threads:[~2016-04-19 12:56 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-04-19 10:29 [PATCH] arm64: mm: take CWG into account in __inval_cache_range() Ard Biesheuvel
2016-04-19 12:56 ` Mark Rutland [this message]
2016-04-19 13:08   ` Ard Biesheuvel
2016-04-19 14:13     ` Catalin Marinas
2016-04-19 14:48       ` Ard Biesheuvel
2016-04-19 15:32         ` Catalin Marinas
2016-04-19 15:38           ` Ard Biesheuvel
2016-04-19 16:09             ` Catalin Marinas

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20160419125615.GA20991@leverpostej \
    --to=mark.rutland@arm.com \
    --cc=linux-arm-kernel@lists.infradead.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox