LinuxPPC-Dev Archive on lore.kernel.org
 help / color / mirror / Atom feed
From: Alistair Popple <alistair@popple.id.au>
To: Michael Ellerman <mpe@ellerman.id.au>
Cc: linuxppc-dev@ozlabs.org, mikey@neuling.org, npiggin@gmail.com,
	jniethe5@gmail.com
Subject: Re: [RFC PATCH 1/4] powerpc/64s: Don't init FSCR_DSCR in __init_FSCR()
Date: Fri, 29 May 2020 11:24:55 +1000	[thread overview]
Message-ID: <1626791.NDfB26j6xz@townsend> (raw)
In-Reply-To: <20200527145843.2761782-1-mpe@ellerman.id.au>

For what it's worth I tested this series on Mambo PowerNV and it seems to 
correctly enable/disable the prefix FSCR bit based on the cpu feature so feel 
free to add:

Tested-by: Alistair Popple <alistair@popple.id.au>

Mikey is going to test out pseries.

- Alistair

On Thursday, 28 May 2020 12:58:40 AM AEST Michael Ellerman wrote:
> __init_FSCR() was added originally in commit 2468dcf641e4 ("powerpc:
> Add support for context switching the TAR register") (Feb 2013), and
> only set FSCR_TAR.
> 
> At that point FSCR (Facility Status and Control Register) was not
> context switched, so the setting was permanent after boot.
> 
> Later we added initialisation of FSCR_DSCR to __init_FSCR(), in commit
> 54c9b2253d34 ("powerpc: Set DSCR bit in FSCR setup") (Mar 2013), again
> that was permanent after boot.
> 
> Then commit 2517617e0de6 ("powerpc: Fix context switch DSCR on
> POWER8") (Aug 2013) added a limited context switch of FSCR, just the
> FSCR_DSCR bit was context switched based on thread.dscr_inherit. That
> commit said "This clears the H/FSCR DSCR bit initially", but it
> didn't, it left the initialisation of FSCR_DSCR in __init_FSCR().
> However the initial context switch from init_task to pid 1 would clear
> FSCR_DSCR because thread.dscr_inherit was 0.
> 
> That commit also introduced the requirement that FSCR_DSCR be clear
> for user processes, so that we can take the facility unavailable
> interrupt in order to manage dscr_inherit.
> 
> Then in commit 152d523e6307 ("powerpc: Create context switch helpers
> save_sprs() and restore_sprs()") (Dec 2015) FSCR was added to
> thread_struct. However it still wasn't fully context switched, we just
> took the existing value and set FSCR_DSCR if the new thread had
> dscr_inherit set. FSCR was still initialised at boot to FSCR_DSCR |
> FSCR_TAR, but that value was not propagated into the thread_struct, so
> the initial context switch set FSCR_DSCR back to 0.
> 
> Finally commit b57bd2de8c6c ("powerpc: Improve FSCR init and context
> switching") (Jun 2016) added a full context switch of the FSCR, and
> added an initialisation of init_task.thread.fscr to FSCR_TAR |
> FSCR_EBB, but omitted FSCR_DSCR.
> 
> The end result is that swapper runs with FSCR_DSCR set because of the
> initialisation in __init_FSCR(), but no other processes do, they use
> the value from init_task.thread.fscr.
> 
> Having FSCR_DSCR set for swapper allows it to access SPR 3 from
> userspace, but swapper never runs userspace, so it has no useful
> effect. It's also confusing to have the value initialised in two
> places to two different values.
> 
> So remove FSCR_DSCR from __init_FSCR(), this at least gets us to the
> point where there's a single value of FSCR, even if it's still set in
> two places.
> 
> Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
> ---
>  arch/powerpc/kernel/cpu_setup_power.S | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/arch/powerpc/kernel/cpu_setup_power.S
> b/arch/powerpc/kernel/cpu_setup_power.S index a460298c7ddb..f91ecb10d0ae
> 100644
> --- a/arch/powerpc/kernel/cpu_setup_power.S
> +++ b/arch/powerpc/kernel/cpu_setup_power.S
> @@ -184,7 +184,7 @@ _GLOBAL(__restore_cpu_power9)
> 
>  __init_FSCR:
>  	mfspr	r3,SPRN_FSCR
> -	ori	r3,r3,FSCR_TAR|FSCR_DSCR|FSCR_EBB
> +	ori	r3,r3,FSCR_TAR|FSCR_EBB
>  	mtspr	SPRN_FSCR,r3
>  	blr





  parent reply	other threads:[~2020-05-29  1:26 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-05-27 14:58 [RFC PATCH 1/4] powerpc/64s: Don't init FSCR_DSCR in __init_FSCR() Michael Ellerman
2020-05-27 14:58 ` [RFC PATCH 2/4] powerpc/64s: Don't let DT CPU features set FSCR_DSCR Michael Ellerman
2020-05-27 14:58 ` [RFC PATCH 3/4] powerpc/64s: Save FSCR to init_task.thread.fscr after feature init Michael Ellerman
2020-05-27 14:58 ` [RFC PATCH 4/4] powerpc/64s: Don't set FSCR bits in INIT_THREAD Michael Ellerman
2020-05-28  8:09 ` [RFC PATCH 1/4] powerpc/64s: Don't init FSCR_DSCR in __init_FSCR() Nicholas Piggin
2020-05-29  1:24 ` Alistair Popple [this message]
2020-06-02  2:48   ` Michael Neuling
2020-06-09  5:29 ` Michael Ellerman

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=1626791.NDfB26j6xz@townsend \
    --to=alistair@popple.id.au \
    --cc=jniethe5@gmail.com \
    --cc=linuxppc-dev@ozlabs.org \
    --cc=mikey@neuling.org \
    --cc=mpe@ellerman.id.au \
    --cc=npiggin@gmail.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox