[PATCH 5/6] ARM: re-implement physical address space switching

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

On Wed, May 06, 2015 at 11:37:37AM +0100, Mark Rutland wrote:
> Hi Russell,
> 
> > > It turns out that I was incorrect in my assertion, and the reordering I
> > > suggested above can't happen. The ARMv7 ARM states:
> > > 
> > > 	Any direct write to a system control register is guaranteed not
> > > 	to affect any instruction that appears, in program
> > > 	order, before the instruction that performed the direct write
> > > 
> > > Which means that the STMFD cannot be affected by the later cp15 write to
> > > the SCTLR, and so the DSB does not need to be moved before the MCR.
> > > 
> > > I apologise for adding to the confusion there.
> > 
> > So does this mean this patch gets an ack now?
> 
> I assumed there was going to be a respin for the CR_W change?
> 
> There's also the dodginess w.r.t. the page table walkers that I can't
> see is solvable short of disabling the MMU prior to the flush, though I
> understand you've NAKed that approach.

Why?  Are you saying that after:

+       mrc     p15, 0, r8, c1, c0, 0           @ read control reg
+       bic     ip, r8, #CR_M                   @ disable caches and MMU
+       mcr     p15, 0, ip, c1, c0, 0
+       dsb
+       isb

the page table walkers are still actively walking the page table?

That to me sounds like a hardware bug.  The point of this is to shut
down the MMU, _then_ update the page tables, and _then_ to re-enable
the MMU to explicitly avoid problems with the page table walkers.

>From what you're saying, this is just not possible, and we should
just throw Keystone SoCs in the bin...

-- 
FTTC broadband for 0.8mile line: currently at 10.5Mbps down 400kbps up
according to speedtest.net.