Nicholas Piggin <npig...@gmail.com> writes: > On Thu, 13 Apr 2017 16:27:34 +1000 > Michael Neuling <mi...@neuling.org> wrote: > >> On Thu, 2017-04-13 at 14:12 +1000, Benjamin Herrenschmidt wrote: >> > On Thu, 2017-04-13 at 09:28 +0530, Aneesh Kumar K.V wrote: >> > > > #endif >> > > > mtctr r12 >> > > > bctrl >> > > > +/* >> > > > + * cur_cpu_spec->cpu_restore would restore LPCR to a >> > > > + * sane value that is set at early boot time, >> > > > + * thereby clearing LPCR_UPRT. >> > > > + * LPCR_UPRT is required if we are running in Radix mode. >> > > > + * Set it here if that be the case. >> > > > + */ >> > > > +BEGIN_MMU_FTR_SECTION >> > > > + mfspr r3, SPRN_LPCR >> > > > + LOAD_REG_IMMEDIATE(r4, LPCR_UPRT) >> > > > + or r3, r3, r4 >> > > > + mtspr SPRN_LPCR, r3 >> > > > +END_MMU_FTR_SECTION_IFSET(MMU_FTR_TYPE_RADIX) >> > >> > We are probably better off saving the value somewhere during boot >> > and just "blasting" it whole back. >> >> We seem to touch LPCR in a bunch of places these days. Not sure when >> "sometimes >> during boot" should actually be. > > In the short term, what if we just save LPCR and restore it after calling > cpu_restore? As you say there are a lot of things that touch LPCR we're > not catching here.
Yeah can we save it on the way down and restore that value on the way back up? The real problem here is that cpu_restore() does not "restore" anything, it programs a set of fixed values. We should probably rework it so that it actually does a save/restore to avoid more bugs like this. cheers