Re: [RFC/PATCH 2/4] powerpc/64/kexec: Fix MMU cleanup on radix

[Benjamin Herrenschmidt <benh@kernel.crashing.org>]

On Fri, 2016-07-08 at 12:55 +1000, Balbir Singh wrote:
> +
> > +/* For use by kexec */
> > +void mmu_cleanup_all(void)
> > +{
> > +     if (radix_enabled())
> > +             radix__mmu_cleanup_all();
> 
> 
> Should this be more than just radix -- cpu_has_feature(CPU_FTR_ARCH_300)?

I don't understand... We need to cleanup the radix if we use a radix, otherwise
we cleanup the hash ...

Basically this will switch back to hash mode before kexec.

> > +     else if (mmu_hash_ops.hpte_clear_all)
> > +             mmu_hash_ops.hpte_clear_all();
> > +}
> > diff --git a/arch/powerpc/mm/pgtable-radix.c b/arch/powerpc/mm/pgtable-radix.c
> > index 3ababda..f127baa 100644
> > --- a/arch/powerpc/mm/pgtable-radix.c
> > +++ b/arch/powerpc/mm/pgtable-radix.c
> > @@ -366,6 +366,16 @@ void radix__early_init_mmu_secondary(void)
> >       }
> >  }
> >  
> > +void radix__mmu_cleanup_all(void)
> > +{
> > +     unsigned long lpcr;
> > +     if (!firmware_has_feature(FW_FEATURE_LPAR)) {
> > +             lpcr = mfspr(SPRN_LPCR);
> > +             mtspr(SPRN_LPCR, lpcr & ~LPCR_UPRT);
> > +             mtspr(SPRN_PTCR, 0);
> 
> Free up the patb data structure here?

Why do we care freeing it ? We're about to kexec.

> We also need tlbie's to invalidate any caches pointing to the patb entries

Yes, that would be definitely a useful addition, I shuld have mentioned this
is a stub so we don't crash due to a NULL pointer, but more work is needed
to properly support kexec, which I'll let Aneesh do.

On the other hand for safety, the new kernel should also flush its TLB on
entry I reckon. Especially since I don't think we do the cleanup on crashdump.

Cheers,
Ben.