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. _______________________________________________ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev