[Skiboot] [PATCH] Add in new OPAL call to flush the L2 and L3 caches.

[Rashmica Gupta]

On Mon, 2018-11-05 at 12:57 +1100, Oliver wrote:
> > 

...

> On Mon, Oct 29, 2018 at 5:19 PM Rashmica Gupta <rashmica.g at gmail.com>
> wrote:
> 
> As a final comment, it seems like we might be better off making this
> a
> multi-pass thing. Currently we walk the list of CPUs once and wait
> for
> the purge to finish on each before continuing. Since we don't really
> have a good error handling story (I guess you fall back to doing a
> dcbf loop in linux?) it might make sense to do something like:
> 
> for_each_cpu()
>    start_l2_purge()
> for_each_cpu()
>    wait_for_l2_purge()
> for_each_cpu()
>    start_l3_purge()
> for_each_cpu()
>    wait_for_l3_purge()
> 
> and bail out if we hit an error at any point. As a general rule we
> want OPAL calls to be handled in microseconds so since opal runs in
> real mode with interrupts disabled. I'm not sure how fast a purge is,
> but if it's a significant fraction of the 2 millisecond timeout
> window
> then we might end up in OPAL for dozens for milliseconds in the worst
> case. This might just be micro-optimising though since I expect this
> is only going to be called once in a blue moon, but it's something to
> consider.
> 

Good point... Even implemented as you suggested, i've seen it take 5-
6ms for the whole call... Perhaps I should split it up into 2 opal
calls: start_l2_l3_cache_purge() and poll_l2_l3_cache_purge()?

Or maybe with the format you suggested, start_cache_purge(pir,
cache_mask) and poll_cache_purge(pir, cache_mask).

> > 
> > _______________________________________________
> > Skiboot mailing list
> > Skiboot at lists.ozlabs.org
> > https://lists.ozlabs.org/listinfo/skiboot