From: Akshay Adiga <akshay.adiga@linux.vnet.ibm.com>
To: Michael Ellerman <mpe@ellerman.id.au>
Cc: linuxppc-dev@ozlabs.org, npiggin@gmail.com
Subject: Re: [PATCH v4 2/9] powerpc/powernv/idle: Restore AMR/UAMOR/AMOR after idle
Date: Wed, 13 Mar 2019 11:41:29 +0530 [thread overview]
Message-ID: <20190313061129.GA4047@aks.ibm> (raw)
In-Reply-To: <20190228144917.16876-2-mpe@ellerman.id.au>
On Fri, Mar 01, 2019 at 01:49:10AM +1100, Michael Ellerman wrote:
> In order to implement KUAP (Kernel Userspace Access Protection) on
> Power9 we will be using the AMR, and therefore indirectly the
> UAMOR/AMOR.
>
> So save/restore these regs in the idle code.
>
> Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
> ---
> arch/powerpc/kernel/idle_book3s.S | 27 +++++++++++++++++++++++----
> 1 file changed, 23 insertions(+), 4 deletions(-)
>
> v4: New.
>
> diff --git a/arch/powerpc/kernel/idle_book3s.S b/arch/powerpc/kernel/idle_book3s.S
> index 36178000a2f2..4a860d3b9229 100644
> --- a/arch/powerpc/kernel/idle_book3s.S
> +++ b/arch/powerpc/kernel/idle_book3s.S
> @@ -170,8 +170,11 @@ END_FTR_SECTION_IFCLR(CPU_FTR_ARCH_300)
> bne- core_idle_lock_held
> blr
>
> -/* Reuse an unused pt_regs slot for IAMR */
> +/* Reuse some unused pt_regs slots for AMR/IAMR/UAMOR/UAMOR */
> +#define PNV_POWERSAVE_AMR _TRAP
> #define PNV_POWERSAVE_IAMR _DAR
> +#define PNV_POWERSAVE_UAMOR _DSISR
> +#define PNV_POWERSAVE_AMOR RESULT
>
> /*
> * Pass requested state in r3:
> @@ -205,8 +208,16 @@ END_FTR_SECTION_IFCLR(CPU_FTR_ARCH_300)
> SAVE_NVGPRS(r1)
>
> BEGIN_FTR_SECTION
> + mfspr r4, SPRN_AMR
> mfspr r5, SPRN_IAMR
> + mfspr r6, SPRN_UAMOR
> + std r4, PNV_POWERSAVE_AMR(r1)
> std r5, PNV_POWERSAVE_IAMR(r1)
> + std r6, PNV_POWERSAVE_UAMOR(r1)
> +BEGIN_FTR_SECTION_NESTED(42)
> + mfspr r7, SPRN_AMOR
> + std r7, PNV_POWERSAVE_AMOR(r1)
> +END_FTR_SECTION_NESTED_IFSET(CPU_FTR_HVMODE, 42)
> END_FTR_SECTION_IFSET(CPU_FTR_ARCH_207S)
Can we save/restore for ARCH_300S only ?
I checked the user manual "POWER8 Processor User’s Manual for the
Single-Chip Module" v1.3 dated 16 March 2016. In section 9.7.2.2,
It mentions that AMOR and UAMOR will be preserved by hardware.
Excrept :
" When an SMT thread switch is enabled, the napping thread’s
resources can be given to other threads to improve core
performance. Software must restore the architected state
of the dormant thread upon exiting nap mode except for
the following architected facilities, which are preserved
by the hardware:
- SLB State
- All Hypervisor Special Registers (includes PURR, SPURR, AMOR,
UAMOR, AMR, ACOP)
"
Keeping 207S has no harm, its just that we may spend a few
more cycles saving and restoring the sprs.
>
> mfcr r5
> @@ -935,12 +946,20 @@ END_FTR_SECTION_IFSET(CPU_FTR_HVMODE)
> REST_GPR(2, r1)
>
> BEGIN_FTR_SECTION
> - /* IAMR was saved in pnv_powersave_common() */
> + /* These regs were saved in pnv_powersave_common() */
> + ld r4, PNV_POWERSAVE_AMR(r1)
> ld r5, PNV_POWERSAVE_IAMR(r1)
> + ld r6, PNV_POWERSAVE_UAMOR(r1)
> + mtspr SPRN_AMR, r4
> mtspr SPRN_IAMR, r5
> + mtspr SPRN_UAMOR, r6
> +BEGIN_FTR_SECTION_NESTED(42)
> + ld r7, PNV_POWERSAVE_AMOR(r1)
> + mtspr SPRN_AMOR, r7
> +END_FTR_SECTION_NESTED_IFSET(CPU_FTR_HVMODE, 42)
> /*
> - * We don't need an isync here because the upcoming mtmsrd is
> - * execution synchronizing.
> + * We don't need an isync here after restoring IAMR because the upcoming
> + * mtmsrd is execution synchronizing.
> */
> END_FTR_SECTION_IFSET(CPU_FTR_ARCH_207S)
>
> --
> 2.20.1
>
next prev parent reply other threads:[~2019-03-13 6:13 UTC|newest]
Thread overview: 11+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-02-28 14:49 [PATCH v4 1/9] powerpc/powernv/idle: Restore IAMR after idle Michael Ellerman
2019-02-28 14:49 ` [PATCH v4 2/9] powerpc/powernv/idle: Restore AMR/UAMOR/AMOR " Michael Ellerman
2019-03-13 6:11 ` Akshay Adiga [this message]
2019-02-28 14:49 ` [PATCH v4 3/9] powerpc: Add framework for Kernel Userspace Protection Michael Ellerman
2019-02-28 14:49 ` [PATCH v4 4/9] powerpc: Add skeleton for Kernel Userspace Execution Prevention Michael Ellerman
2019-02-28 14:49 ` [PATCH v4 5/9] powerpc: Add a framework for Kernel Userspace Access Protection Michael Ellerman
2019-02-28 14:49 ` [PATCH v4 6/9] powerpc/64: Setup KUP on secondary CPUs Michael Ellerman
2019-02-28 14:49 ` [PATCH v4 7/9] powerpc/mm/radix: Use KUEP API for Radix MMU Michael Ellerman
2019-02-28 14:49 ` [PATCH v4 8/9] powerpc/lib: Refactor __patch_instruction() to use __put_user_asm() Michael Ellerman
2019-02-28 14:49 ` [PATCH v4 9/9] powerpc/64s: Implement KUAP for Radix MMU Michael Ellerman
2019-02-28 19:43 ` kbuild test robot
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=20190313061129.GA4047@aks.ibm \
--to=akshay.adiga@linux.vnet.ibm.com \
--cc=linuxppc-dev@ozlabs.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.