L1 & L2 cache flush sequence on CortexA5 MPcore w.r.t low power modes

[linux@arm.linux.org.uk (Russell King - ARM Linux)]

On Mon, May 14, 2012 at 06:15:33PM +0100, Lorenzo Pieralisi wrote:
> On Mon, May 14, 2012 at 05:39:09PM +0100, Russell King - ARM Linux wrote:
> > From what you're saying - and from my understanding of your cache behaviours,
> > even the sequence:
> > - clean cache
> > - disable C bit
> > - clean cache
> > is buggy.
> 
> No, that's correct, works fine on A9 and A15. Second clean is mostly nops.

It's racy.  Consider this:

	- clean cache
	- cache speculatively prefetches a dirty cache line from another CPU
	- disable C bit

At this point, you lose access to that dirty data.  If that dirty data is
used inbetween disabling the C bit and cleaning the cache for the second
time, you have data corruption issues.

Another point which needs to be checked is whether dirty cache lines in
a CPUs cache which has had the C bit disabled still take part in the
coherency protocol with other CPUs.  If the answer is no, then that's a
_major_ problem for the hot unplug code paths.  That effectively means
that we have a window where a CPU going down actively _corrupts_ the
data visible to other CPUs.

As I have said, given what you've mentioned, it is impossible to safely
disable the cache on a SMP system.  In order to do it safely, you need to
have a way to disable new allocations into the cache _without_ disabling
the ability for the cache to be searched.

And if we could do that, then the sequence becomes a simple and race free:

	- disable new allocations
	- clean cache
	- disable cache