On Mon, 24 Apr 2017 10:13:23 +1000 Benjamin Herrenschmidt <b...@kernel.crashing.org> wrote:
> On Sun, 2017-04-23 at 19:57 +1000, Nicholas Piggin wrote: > > On Sun, 23 Apr 2017 10:39:11 +1000 > > Benjamin Herrenschmidt <b...@kernel.crashing.org> wrote: > > > > > On Sun, 2017-04-23 at 09:14 +1000, Nicholas Piggin wrote: > > > > I think we were going to take another look at moving the setup > > > > code > > > > later, but I think that might wait until 4.13. > > > > > > Except without that we won't boot a post-P9 CPU right ? So we'll > > > end up > > > having to chase distros to backport it :-( Oh well... > > > > Okay, well what if we just move the TLB flushing to somewhere like > > early_init_mmu(_secondary) for power CPUs first? > > > > Non-local tlbie does not seem to have this requirement, so would it > > make it more robust just to execute that once during boot with the > > primary thread? > > I wouldn't do a broadcast before we have LPCR setup... but for no > obvious reason. Also I'm not sure our boot time cleanup does things > properly vs hash & radix. I think we really need 2 passes. > > Oh well.. > > My main worry is the fact that on future chip we won't be setting up > LPCR properly. We should at least assume an unknown chip is P9, is that > what you do with your cpu-features patches ? cpu-features patches set up LPCR based on ISAv3 compatible MMU property (among other things). In case that does not match, we currently don't do anything graceful. Actually those patches I think are missing the TLB flush though, which I will add as a per-cpu local flush in the MMU setup path.