[PATCH v5 18/26] powerpc/book3s64/keys/kuap: Reset AMR/IAMR values on kexec

[Michael Ellerman]

"Aneesh Kumar K.V" <aneesh.kumar at linux.ibm.com> writes:
> On 7/6/20 5:59 PM, Michael Ellerman wrote:
>> "Aneesh Kumar K.V" <aneesh.kumar at 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