Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]


Groups > linux.kernel > #1698211 > unrolled thread

Re: [RFC v6 20/62] powerpc: store and restore the pkey state across context switches

Started byThiago Jung Bauermann <bauerman@linux.vnet.ibm.com>
First post2017-07-27 19:40 +0200
Last post2017-07-31 15:10 +0200
Articles 3 — 3 participants

Back to article view | Back to linux.kernel

This discussion starts older than the indexed window; earlier articles aren't shown. The article labeled Started by below is the oldest one visible, not the original post.


Contents

  Re: [RFC v6 20/62] powerpc: store and restore the pkey state across context switches Thiago Jung Bauermann <bauerman@linux.vnet.ibm.com> - 2017-07-27 19:40 +0200
    Re: [RFC v6 20/62] powerpc: store and restore the pkey state across  context switches Ram Pai <linuxram@us.ibm.com> - 2017-07-30 01:40 +0200
      Re: [RFC v6 20/62] powerpc: store and restore the pkey state across context switches Michael Ellerman <mpe@ellerman.id.au> - 2017-07-31 15:10 +0200

#1698211 — Re: [RFC v6 20/62] powerpc: store and restore the pkey state across context switches

FromThiago Jung Bauermann <bauerman@linux.vnet.ibm.com>
Date2017-07-27 19:40 +0200
SubjectRe: [RFC v6 20/62] powerpc: store and restore the pkey state across context switches
Message-ID<u7UVr-zr-1@gated-at.bofh.it>
Ram Pai <linuxram@us.ibm.com> writes:

> Store and restore the AMR, IAMR and UMOR register state of the task
> before scheduling out and after scheduling in, respectively.
>
> Signed-off-by: Ram Pai <linuxram@us.ibm.com>

s/UMOR/UAMOR/

> diff --git a/arch/powerpc/kernel/process.c b/arch/powerpc/kernel/process.c
> index 2ad725e..9429361 100644
> --- a/arch/powerpc/kernel/process.c
> +++ b/arch/powerpc/kernel/process.c
> @@ -1096,6 +1096,11 @@ static inline void save_sprs(struct thread_struct *t)
>  		t->tar = mfspr(SPRN_TAR);
>  	}
>  #endif
> +#ifdef CONFIG_PPC64_MEMORY_PROTECTION_KEYS
> +	t->amr = mfspr(SPRN_AMR);
> +	t->iamr = mfspr(SPRN_IAMR);
> +	t->uamor = mfspr(SPRN_UAMOR);
> +#endif
>  }
>
>  static inline void restore_sprs(struct thread_struct *old_thread,
> @@ -1131,6 +1136,14 @@ static inline void restore_sprs(struct thread_struct *old_thread,
>  			mtspr(SPRN_TAR, new_thread->tar);
>  	}
>  #endif
> +#ifdef CONFIG_PPC64_MEMORY_PROTECTION_KEYS
> +	if (old_thread->amr != new_thread->amr)
> +		mtspr(SPRN_AMR, new_thread->amr);
> +	if (old_thread->iamr != new_thread->iamr)
> +		mtspr(SPRN_IAMR, new_thread->iamr);
> +	if (old_thread->uamor != new_thread->uamor)
> +		mtspr(SPRN_UAMOR, new_thread->uamor);
> +#endif
>  }

Shouldn't the saving and restoring of the SPRs be guarded by a check for
whether memory protection keys are enabled? What happens when trying to
access these registers on a CPU which doesn't have them?

-- 
Thiago Jung Bauermann
IBM Linux Technology Center

[toc] | [next] | [standalone]


#1699396 — Re: [RFC v6 20/62] powerpc: store and restore the pkey state across context switches

FromRam Pai <linuxram@us.ibm.com>
Date2017-07-30 01:40 +0200
SubjectRe: [RFC v6 20/62] powerpc: store and restore the pkey state across context switches
Message-ID<u8JuV-Nu-1@gated-at.bofh.it>
In reply to#1698211
On Thu, Jul 27, 2017 at 02:32:59PM -0300, Thiago Jung Bauermann wrote:
> 
> Ram Pai <linuxram@us.ibm.com> writes:
> 
> > Store and restore the AMR, IAMR and UMOR register state of the task
> > before scheduling out and after scheduling in, respectively.
> >
> > Signed-off-by: Ram Pai <linuxram@us.ibm.com>
> 
> s/UMOR/UAMOR/
> 
> > diff --git a/arch/powerpc/kernel/process.c b/arch/powerpc/kernel/process.c
> > index 2ad725e..9429361 100644
> > --- a/arch/powerpc/kernel/process.c
> > +++ b/arch/powerpc/kernel/process.c
> > @@ -1096,6 +1096,11 @@ static inline void save_sprs(struct thread_struct *t)
> >  		t->tar = mfspr(SPRN_TAR);
> >  	}
> >  #endif
> > +#ifdef CONFIG_PPC64_MEMORY_PROTECTION_KEYS
> > +	t->amr = mfspr(SPRN_AMR);
> > +	t->iamr = mfspr(SPRN_IAMR);
> > +	t->uamor = mfspr(SPRN_UAMOR);
> > +#endif
> >  }
> >
> >  static inline void restore_sprs(struct thread_struct *old_thread,
> > @@ -1131,6 +1136,14 @@ static inline void restore_sprs(struct thread_struct *old_thread,
> >  			mtspr(SPRN_TAR, new_thread->tar);
> >  	}
> >  #endif
> > +#ifdef CONFIG_PPC64_MEMORY_PROTECTION_KEYS
> > +	if (old_thread->amr != new_thread->amr)
> > +		mtspr(SPRN_AMR, new_thread->amr);
> > +	if (old_thread->iamr != new_thread->iamr)
> > +		mtspr(SPRN_IAMR, new_thread->iamr);
> > +	if (old_thread->uamor != new_thread->uamor)
> > +		mtspr(SPRN_UAMOR, new_thread->uamor);
> > +#endif
> >  }
> 
> Shouldn't the saving and restoring of the SPRs be guarded by a check for
> whether memory protection keys are enabled? What happens when trying to
> access these registers on a CPU which doesn't have them?

Good point. need to guard it.  However; i think, these registers have been
available since power6.

RP

[toc] | [prev] | [next] | [standalone]


#1700030

FromMichael Ellerman <mpe@ellerman.id.au>
Date2017-07-31 15:10 +0200
Message-ID<u9iCm-6GI-9@gated-at.bofh.it>
In reply to#1699396
Ram Pai <linuxram@us.ibm.com> writes:
> On Thu, Jul 27, 2017 at 02:32:59PM -0300, Thiago Jung Bauermann wrote:
>> Ram Pai <linuxram@us.ibm.com> writes:
>> > diff --git a/arch/powerpc/kernel/process.c b/arch/powerpc/kernel/process.c
>> > index 2ad725e..9429361 100644
>> > --- a/arch/powerpc/kernel/process.c
>> > +++ b/arch/powerpc/kernel/process.c
>> > @@ -1096,6 +1096,11 @@ static inline void save_sprs(struct thread_struct *t)
>> >  		t->tar = mfspr(SPRN_TAR);
>> >  	}
>> >  #endif
>> > +#ifdef CONFIG_PPC64_MEMORY_PROTECTION_KEYS
>> > +	t->amr = mfspr(SPRN_AMR);
>> > +	t->iamr = mfspr(SPRN_IAMR);
>> > +	t->uamor = mfspr(SPRN_UAMOR);
>> > +#endif
>> >  }
>> >
>> >  static inline void restore_sprs(struct thread_struct *old_thread,
>> > @@ -1131,6 +1136,14 @@ static inline void restore_sprs(struct thread_struct *old_thread,
>> >  			mtspr(SPRN_TAR, new_thread->tar);
>> >  	}
>> >  #endif
>> > +#ifdef CONFIG_PPC64_MEMORY_PROTECTION_KEYS
>> > +	if (old_thread->amr != new_thread->amr)
>> > +		mtspr(SPRN_AMR, new_thread->amr);
>> > +	if (old_thread->iamr != new_thread->iamr)
>> > +		mtspr(SPRN_IAMR, new_thread->iamr);
>> > +	if (old_thread->uamor != new_thread->uamor)
>> > +		mtspr(SPRN_UAMOR, new_thread->uamor);
>> > +#endif
>> >  }
>> 
>> Shouldn't the saving and restoring of the SPRs be guarded by a check for
>> whether memory protection keys are enabled? What happens when trying to
>> access these registers on a CPU which doesn't have them?
>
> Good point. need to guard it.  However; i think, these registers have been
> available since power6.

The kernel runs on CPUs much older than that.

IAMR was added on Power8.

And performance is also an issue, so we should only switch them when we
need to.

cheers

[toc] | [prev] | [standalone]


Back to top | Article view | linux.kernel


csiph-web