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

[Will Deacon]

On Wed, May 06, 2015 at 05:14:06PM +0100, Mark Rutland wrote:
> > > 	cr = get_cr();
> > > 	set_cr(cr & ~(CR_I | CR_C | CR_W));
> > > 	flush_cache_all();
> > > 
> > > With the MMU on at this point the page table walkers can race with the
> > > set/way maintenance. It also relies on the compiler not making stack
> > > accesses between the SCTLR write and the completion of flush_cache_all,
> > > which is likely but not guranteed.
> > 
> > Yes, I suppose you're right, but there's really no other way to do
> > this other than coding up CPU specific code.
> > 
> > What we'd need to do is to code up a specific assembly routine which
> > disables the I and C control register flags, flushes the cache, jumps
> > to the physical alias and then disables the MMU all without touching
> > memory.  That's far too much effort.  Like I say, maybe we should just
> > bin Keystone for this crap...
> > 
> > I'm not interested in trying to "fix" this code any further - as I
> > said earlier, it took quite a while to get this code working on
> > Keystone, which is really all we care about.  Anyone else who copies
> > the abortion that TI made in Keystone should be shot. :)
> > 
> > While the community has the luxury of saying "we don't like it, it's
> > TI's problem" - which is what was done when the problems were first
> > pointed out by Will, the net result is that this problem became my
> > problem to try and sort out.
> > 
> > So, if you have a better idea how to fix this, I'm all ears.
> >
> > What I'm certain of though is that this is an improvement over what's
> > in the kernel today, and so should go in irrespective of whether it's
> > totally bullet-proof or not.
> 
> I don't disagree with that. :)
> 
> w.r.t. "better" ideas, my initial thought was that we could move the
> SCTLR.{C,M} clearing into lpae_pgtables_remap_asm, along with a call to
> v7_flush_dcache_all (as it should be in the physical mapping). So long
> as the kernel text was initially clean to the PoC I'd expect that to
> work, but I understood from your initial reply you'd tried that and
> something went wrong.
> 
> Perhaps we can look into that later.

I think a comment summarising the conclusion of this thread above the
cache flush and rmk's choice of adjective to describe the keystone SoC
would be sufficient.

Will