Re: Why invalidate d-cache if MMU and d-cache are disabled by rule?

Re: Why invalidate d-cache if MMU and d-cache are disabled by rule?

[Catalin Marinas]

(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