From: Catalin Marinas <catalin.marinas@arm.com>
To: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Cc: Mark Rutland <mark.rutland@arm.com>,
Will Deacon <will.deacon@arm.com>,
"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
James Morse <james.morse@arm.com>,
robin.murphy@arm.com,
"linux-arm-kernel@lists.infradead.org"
<linux-arm-kernel@lists.infradead.org>
Subject: Re: [PATCH] arm64: mm: take CWG into account in __inval_cache_range()
Date: Tue, 19 Apr 2016 17:09:13 +0100 [thread overview]
Message-ID: <20160419160913.GF8482@e104818-lin.cambridge.arm.com> (raw)
In-Reply-To: <CAKv+Gu890YWn-DU5Hevb1hHqOTLssWn9rWgdBj=oA9FsJhLF0Q@mail.gmail.com>
On Tue, Apr 19, 2016 at 05:38:56PM +0200, Ard Biesheuvel wrote:
> On 19 April 2016 at 17:32, Catalin Marinas <catalin.marinas@arm.com> wrote:
> > On Tue, Apr 19, 2016 at 04:48:32PM +0200, Ard Biesheuvel wrote:
> >> On 19 April 2016 at 16:13, Catalin Marinas <catalin.marinas@arm.com> wrote:
> >> > The best we could do is to warn if ARCH_DMA_MINALIGN is smaller than CWG
> >> > (as Robin suggested, we could do this only if we have non-coherent DMA
> >> > masters via arch_setup_dma_ops()). Quick hack below:
> >> >
> >> > -------------------------------8<-----------------------------------
> >> > diff --git a/arch/arm64/include/asm/cache.h b/arch/arm64/include/asm/cache.h
> >> > index 5082b30bc2c0..5967fcbb617a 100644
> >> > --- a/arch/arm64/include/asm/cache.h
> >> > +++ b/arch/arm64/include/asm/cache.h
> >> > @@ -28,7 +28,7 @@
> >> > * cache before the transfer is done, causing old data to be seen by
> >> > * the CPU.
> >> > */
> >> > -#define ARCH_DMA_MINALIGN L1_CACHE_BYTES
> >> > +#define ARCH_DMA_MINALIGN 128
> >> >
> >> > #ifndef __ASSEMBLY__
> >> >
> >> > @@ -37,7 +37,7 @@
> >> > static inline int cache_line_size(void)
> >> > {
> >> > u32 cwg = cache_type_cwg();
> >> > - return cwg ? 4 << cwg : L1_CACHE_BYTES;
> >> > + return cwg ? 4 << cwg : ARCH_DMA_MINALIGN;
> >>
> >> Unrelated, but this does not look right: if the CWG field is zero, we
> >> should either assume 2 KB, or iterate over all the CCSIDR values and
> >> take the maximum linesize.
> >
> > It may be a better guess but even that is not always relevant since
> > CCSIDR may not present the real hardware information. It's only meant to
> > give enough information to be able to do cache maintenance by set/way
> > and we've seen CPU implementations where this has nothing to do with the
> > actual cache geometry.
>
> I am aware of that discussion, but that was about inferring aliasing
> properties from the way size, which combines the linesize and the
> number of sets/ways, and the latter are apparently set to 1/1 in some
> cases so that any set/way operation simply affects the entire cache.
>
> However, the CCSIDR linesize field itself is mentioned in the
> description of CWG in the ARM ARM, as a suitable source of obtaining
> the maximum linesize in the system.
The ARM ARM confuses me. While CTR_EL0.CWG indeed talks about CCSIDR as
a fall back, the latter has a note:
The parameters NumSets, Associativity, and LineSize in these registers
define the architecturally visible parameters that are required for
the cache maintenance by Set/Way instructions. They are not guaranteed
to represent the actual microarchitectural features of a design. You
cannot make any inference about the actual sizes of caches based on
these parameters.
So it's not clear to me whether LineSize would give us the information
we need for cache maintenance by VA. But I'm not opposed to using this
on a CPU that doesn't have CWG (once we see one).
--
Catalin
prev parent reply other threads:[~2016-04-19 16:09 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-04-19 10:29 Ard Biesheuvel
2016-04-19 12:56 ` Mark Rutland
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 [this message]
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=20160419160913.GF8482@e104818-lin.cambridge.arm.com \
--to=catalin.marinas@arm.com \
--cc=ard.biesheuvel@linaro.org \
--cc=james.morse@arm.com \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-kernel@vger.kernel.org \
--cc=mark.rutland@arm.com \
--cc=robin.murphy@arm.com \
--cc=will.deacon@arm.com \
/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
all inboxes | Powered by JetHome®