"Aneesh Kumar K.V" <aneesh.ku...@linux.ibm.com> writes: > On 7/6/20 5:59 PM, Michael Ellerman wrote: >> "Aneesh Kumar K.V" <aneesh.ku...@linux.ibm.com> writes: >>> As we kexec across kernels that use AMR/IAMR for different purposes >>> we need to ensure that new kernels get kexec'd with a reset value >>> of AMR/IAMR. For ex: the new kernel can use key 0 for kernel mapping and >>> the old >>> AMR value prevents access to key 0. >>> >>> This patch also removes reset if IAMR and AMOR in kexec_sequence. Reset of >>> AMOR >>> is not needed and the IAMR reset is partial (it doesn't do the reset >>> on secondary cpus) and is redundant with this patch. >> >> I like the idea of cleaning this stuff up. >> >> But I think tying it into kup/kuep/kuap and the MMU features and ifdefs >> and so on is overly complicated. >> >> We should just have eg: >> >> void reset_sprs(void) >> { >> if (early_cpu_has_feature(CPU_FTR_ARCH_206)) { >> mtspr(SPRN_AMR, 0); >> mtspr(SPRN_UAMOR, 0); >> } >> >> if (early_cpu_has_feature(CPU_FTR_ARCH_207S)) { >> mtspr(SPRN_IAMR, 0); >> } >> } >> >> And call that from the kexec paths. > > Will fix. Should that be early_cpu_has_feature()? cpu_has_feature() > should work there right?
Yeah I guess. I was thinking if we crashed before code patching was done, but if that happens we can't kdump anyway. So I'm probably being over paranoid. cheers