From: Catalin Marinas <catalin.marinas@arm.com>
To: Jason Mielke <jmielkeway@gmail.com>
Cc: linux-arm-kernel@lists.infradead.org, linux-arm@lists.infradead.org
Subject: Re: Why invalidate d-cache if MMU and d-cache are disabled by rule?
Date: Mon, 10 Aug 2020 10:49:23 +0100 [thread overview]
Message-ID: <20200810094923.GA27780@gaia> (raw)
In-Reply-To: <CA+aKwRRi36GzjEPeaZCLrbjTyKPWTQyo4wkD9j-pid9p0cZEtQ@mail.gmail.com>
(adding linux-arm-kernel for kernel questions)
On Sun, Aug 09, 2020 at 05:08:01PM +0200, Jason Mielke wrote:
> Trying to understand the
>
> preserve_boot_args
>
> function in
>
> arch/arm64/kernel/head.S
>
> The function has a call to invalidate the 32 bytes of dcache area
>
> SYM_CODE_START_LOCAL(preserve_boot_args)
> mov x21, x0 // x21=FDT
>
> adr_l x0, boot_args // record the contents of
> stp x21, x1, [x0] // x0 .. x3 at kernel entry
> stp x2, x3, [x0, #16]
>
> dmb sy // needed before dc ivac with
> // MMU off
>
> mov x1, #0x20 // 4 x 8 bytes
> b __inval_dcache_area // tail call
> SYM_CODE_END(preserve_boot_args)
>
> This even though the MMU and d-cache must be disabled
That's because when the MMU will be enabled, the cache may contain stale
data for this address and a subsequent load may not see what was
actually written with the MMU/caches disabled.
Some examples:
- the CPU on reset does not guarantee that the cache won't contain stale
information
- a boot-loader may have turned the MMU on, before Linux and caches were
populated
- if running as a guest, the hypervisor probably already maps large
chunks of memory as cacheable with the MMU enabled
So in all the above examples, the cache may have stale entries prior to
the store with the MMU disabled.
--
Catalin
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
parent reply other threads:[~2020-08-10 9:50 UTC|newest]
Thread overview: expand[flat|nested] mbox.gz Atom feed
[parent not found: <CA+aKwRRi36GzjEPeaZCLrbjTyKPWTQyo4wkD9j-pid9p0cZEtQ@mail.gmail.com>]
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=20200810094923.GA27780@gaia \
--to=catalin.marinas@arm.com \
--cc=jmielkeway@gmail.com \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-arm@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