On 16/11/16 18:58, Aneesh Kumar K.V wrote:
> Balbir Singh <bsinghar...@gmail.com> writes:
>
>> AMOR should be setup in HV mode, we set it up once
>> and let the generic kernel handle IAMR. This patch is
>> used to enable storage keys in a following patch as
>> defined in ISA 3. We don't setup AMOR in DD1, since we
>> can't setup IAMR in DD1 (bits have to be 0). If we setup
>> AMOR some other code could potentially try to set IAMR
>> (guest kernel for example).
>>
>> Reported-by: Aneesh Kumar K.V <aneesh.ku...@linux.vnet.ibm.com>
>> Signed-off-by: Balbir Singh <bsinghar...@gmail.com>
>> ---
>> arch/powerpc/mm/pgtable-radix.c | 23 +++++++++++++++++++++++
>> 1 file changed, 23 insertions(+)
>>
>> diff --git a/arch/powerpc/mm/pgtable-radix.c
>> b/arch/powerpc/mm/pgtable-radix.c
>> index ed7bddc..7aa104d 100644
>> --- a/arch/powerpc/mm/pgtable-radix.c
>> +++ b/arch/powerpc/mm/pgtable-radix.c
>> @@ -320,6 +320,27 @@ static void update_hid_for_radix(void)
>> cpu_relax();
>> }
>>
>> +/*
>> + * In HV mode, we init AMOR so that the hypervisor
>> + * and guest can setup IMAR, enable key 0 and set
>> + * it to 1
>> + * AMOR = 1100....00 (Mask for key 0 is 11)
>> + */
>> +static void radix_init_amor(void)
>> +{
>> + unsigned long amor_mask = 0xc000000000000000;
>> + unsigned long amor;
>
> I guess michael mentioned this in another email, why two variables ?
>
Left overs from when we did the OR'ing of the mask. But luckily
the compiler does the right thing when generating code
Balbir
