[U-Boot] [PATCH 1/2] armv8: add hooks for all cache-wide operations

[Stephen Warren]

On 10/18/2016 09:28 AM, york sun wrote:
> On 10/17/2016 04:35 PM, Stephen Warren wrote:
>> From: Stephen Warren <swarren at nvidia.com>
>>
>> SoC-specific logic may be required for all forms of cache-wide
>> operations; invalidate and flush of both dcache and icache (note that
>> only 3 of the 4 possible combinations make sense, since the icache never
>> contains dirty lines). This patch adds an optional hook for all
>> implemented cache-wide operations, and renames the one existing hook to
>> better represent exactly which operation it is implementing. A dummy
>> no-op implementation of each hook is provided. These dummy
>> implementations are moved into C code, since there's no need to
>> implement them in assembly.
>>
> Stephen,
>
> Moving this function to C may pose an issue. I had a debug a couple of
> years ago that calling a C function put the stack into cache after
> flushing L1/L2. That's why I used asm function to flush L3.

Assuming the stack is located in cachable memory, the CPU is free (per 
the definition of the ARM architecture) to pull it into the cache at any 
time the cache is enabled (and perhaps even when it isn't enabled, at 
the very least for the icache on ARMv8 if not other cases too). 
Implementation in C vs. assembly has absolutely no effect here. I guess 
your statement assumes that C functions will write data to the stack and 
assembly functions never will. There's no strict 1:1 correlation between 
those two things; assembly code can touch the stack just like C code. If 
there's an assumption it won't, it needs to be documented in the header 
defining these hook functions.

I assume you're specifically talking about dirtying the dcache between 
the point when dcache flushing starts and the point when the dcache is 
disabled? If so, flush_dcache_all() itself would have to be manually 
coded in assembly to avoid using the stack, as would dcache_disable() 
and set_sctlr(). I think this is why dcache_disable() currently disables 
the dcache first (thus preventing it acquiring new dirty data) and then 
flushes the dcache afterwards (thus guaranteeing that all dirty data is 
flushed with no race condition). This implies that your change to swap 
the order of those two functions isn't correct. I'm pretty sure I'm 
correct in saying that the dcache can hit even if it's disabled, hence 
disabling the dcache while it contains dirty data won't lead to issues?