From: Andy Lutomirski <luto@kernel.org>
To: "Bae, Chang Seok" <chang.seok.bae@intel.com>
Cc: Ingo Molnar <mingo@kernel.org>,
Thomas Gleixner <tglx@linutronix.de>,
Andrew Lutomirski <luto@kernel.org>,
"H. Peter Anvin" <hpa@zytor.com>, Andi Kleen <ak@linux.intel.com>,
Dave Hansen <dave.hansen@linux.intel.com>,
"Metzger, Markus T" <markus.t.metzger@intel.com>,
"Ravi V. Shankar" <ravi.v.shankar@intel.com>,
LKML <linux-kernel@vger.kernel.org>
Subject: Re: [v3 05/12] x86/fsgsbase/64: Preserve FS/GS state in __switch_to() if FSGSBASE is on
Date: Wed, 24 Oct 2018 12:21:20 -0700 [thread overview]
Message-ID: <CALCETrWZZ65pzmO_OwG0x3DWtLbLykB16DB5t8r3rkjg5VmzmA@mail.gmail.com> (raw)
In-Reply-To: <20181023184234.14025-6-chang.seok.bae@intel.com>
On Tue, Oct 23, 2018 at 11:43 AM Chang S. Bae <chang.seok.bae@intel.com> wrote:
>
> From: Andy Lutomirski <luto@kernel.org>
>
> With the new FSGSBASE instructions, we can efficiently read and write
> the FSBASE and GSBASE in __switch_to(). Use that capability to preserve
> the full state.
>
> This will enable user code to do whatever it wants with the new
> instructions without any kernel-induced gotchas. (There can still be
> architectural gotchas: movl %gs,%eax; movl %eax,%gs may change GSBASE
> if WRGSBASE was used, but users are expected to read the CPU manual
> before doing things like that.)
>
> This is a considerable speedup. It seems to save about 100 cycles
> per context switch compared to the baseline 4.6-rc1 behavior on my
> Skylake laptop.
>
> [ chang: 5~10% performance improvements were seen by a context switch
> benchmark that ran threads with different FS/GSBASE values. Minor
> edit on the changelog. ]
>
> Signed-off-by: Andy Lutomirski <luto@kernel.org>
> Signed-off-by: Chang S. Bae <chang.seok.bae@intel.com>
> Reviewed-by: Andi Kleen <ak@linux.intel.com>
> Cc: H. Peter Anvin <hpa@zytor.com>
> Cc: Thomas Gleixner <tglx@linutronix.de>
> Cc: Ingo Molnar <mingo@kernel.org>
> Cc: Dave Hansen <dave.hansen@linux.intel.com>
> ---
> arch/x86/kernel/process_64.c | 34 ++++++++++++++++++++++++++++------
> 1 file changed, 28 insertions(+), 6 deletions(-)
>
> diff --git a/arch/x86/kernel/process_64.c b/arch/x86/kernel/process_64.c
> index fcf18046c3d6..1d975cadc256 100644
> --- a/arch/x86/kernel/process_64.c
> +++ b/arch/x86/kernel/process_64.c
> @@ -238,8 +238,18 @@ static __always_inline void save_fsgs(struct task_struct *task)
> {
> savesegment(fs, task->thread.fsindex);
> savesegment(gs, task->thread.gsindex);
> - save_base_legacy(task, task->thread.fsindex, FS);
> - save_base_legacy(task, task->thread.gsindex, GS);
> + if (static_cpu_has(X86_FEATURE_FSGSBASE)) {
> + /*
> + * If FSGSBASE is enabled, we can't make any useful guesses
> + * about the base, and user code expects us to save the current
> + * value. Fortunately, reading the base directly is efficient.
> + */
> + task->thread.fsbase = rdfsbase();
> + task->thread.gsbase = rd_inactive_gsbase();
> + } else {
> + save_base_legacy(task, task->thread.fsindex, FS);
> + save_base_legacy(task, task->thread.gsindex, GS);
> + }
> }
>
> #if IS_ENABLED(CONFIG_KVM)
> @@ -318,10 +328,22 @@ static __always_inline void load_seg_legacy(unsigned short prev_index,
> static __always_inline void x86_fsgsbase_load(struct thread_struct *prev,
> struct thread_struct *next)
> {
> - load_seg_legacy(prev->fsindex, prev->fsbase,
> - next->fsindex, next->fsbase, FS);
> - load_seg_legacy(prev->gsindex, prev->gsbase,
> - next->gsindex, next->gsbase, GS);
> + if (static_cpu_has(X86_FEATURE_FSGSBASE)) {
> + /* Update the FS and GS selectors if they could have changed. */
> + if (unlikely(prev->fsindex || next->fsindex))
> + loadseg(FS, next->fsindex);
> + if (unlikely(prev->gsindex || next->gsindex))
> + loadseg(GS, next->gsindex);
> +
> + /* Update the bases. */
> + wrfsbase(next->fsbase);
> + wr_inactive_gsbase(next->gsbase);
Aha, I see what you're doing with the FSGSBASE-optimized version being
out of line. But it's way too unclear from the code. You should name
the helper wrgsbase_inactive or maybe __wrgsbase_inactive() to
emphasize that you're literally using the WRGSBASE instruction. (Or
it's Xen PV equivalent. Hmm.)
next prev parent reply other threads:[~2018-10-24 19:21 UTC|newest]
Thread overview: 34+ messages / expand[flat|nested] mbox.gz Atom feed top
2018-10-23 18:42 [v3 00/12] x86: Enable FSGSBASE instructions Chang S. Bae
2018-10-23 18:42 ` [v3 01/12] taint: Introduce a new taint flag (insecure) Chang S. Bae
2018-10-24 18:50 ` Andy Lutomirski
2018-10-23 18:42 ` [v3 02/12] x86/fsgsbase/64: Add 'unsafe_fsgsbase' to enable CR4.FSGSBASE Chang S. Bae
2018-10-24 18:51 ` Andy Lutomirski
2018-10-23 18:42 ` [v3 03/12] x86/fsgsbase/64: Add intrinsics/macros for FSGSBASE instructions Chang S. Bae
2018-10-24 18:53 ` Andy Lutomirski
2018-10-24 19:21 ` Andi Kleen
2018-10-25 23:14 ` Andy Lutomirski
2018-10-25 23:31 ` Linus Torvalds
2018-10-26 0:09 ` Andy Lutomirski
2018-10-23 18:42 ` [v3 04/12] x86/fsgsbase/64: Enable FSGSBASE instructions in the helper functions Chang S. Bae
2018-10-24 19:16 ` Andy Lutomirski
2018-10-24 19:41 ` [Xen-devel] " Andrew Cooper
2018-10-25 6:09 ` Juergen Gross
2018-10-25 23:08 ` Andrew Cooper
2018-10-25 23:11 ` Andy Lutomirski
2018-10-25 23:14 ` Andrew Cooper
2018-10-25 7:32 ` Bae, Chang Seok
2018-10-25 23:00 ` Andy Lutomirski
2018-10-25 23:03 ` Bae, Chang Seok
2018-10-25 23:16 ` Andy Lutomirski
2018-10-23 18:42 ` [v3 05/12] x86/fsgsbase/64: Preserve FS/GS state in __switch_to() if FSGSBASE is on Chang S. Bae
2018-10-24 19:21 ` Andy Lutomirski [this message]
2018-10-24 19:36 ` Bae, Chang Seok
2018-10-23 18:42 ` [v3 06/12] x86/fsgsbase/64: When copying a thread, use the FSGSBASE instructions if available Chang S. Bae
2018-10-23 18:42 ` [v3 07/12] x86/fsgsbase/64: Introduce the new FIND_PERCPU_BASE macro Chang S. Bae
2018-10-26 0:25 ` Andy Lutomirski
2018-10-26 0:59 ` Nadav Amit
2018-10-23 18:42 ` [v3 08/12] x86/fsgsbase/64: Use the per-CPU base as GSBASE at the paranoid_entry Chang S. Bae
2018-10-23 18:42 ` [v3 09/12] selftests/x86/fsgsbase: Test WRGSBASE Chang S. Bae
2018-10-23 18:42 ` [v3 10/12] x86/fsgsbase/64: Enable FSGSBASE by default and add a chicken bit Chang S. Bae
2018-10-23 18:42 ` [v3 11/12] x86/elf: Enumerate kernel FSGSBASE capability in AT_HWCAP2 Chang S. Bae
2018-10-23 18:42 ` [v3 12/12] x86/fsgsbase/64: Add documentation for FSGSBASE Chang S. Bae
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=CALCETrWZZ65pzmO_OwG0x3DWtLbLykB16DB5t8r3rkjg5VmzmA@mail.gmail.com \
--to=luto@kernel.org \
--cc=ak@linux.intel.com \
--cc=chang.seok.bae@intel.com \
--cc=dave.hansen@linux.intel.com \
--cc=hpa@zytor.com \
--cc=linux-kernel@vger.kernel.org \
--cc=markus.t.metzger@intel.com \
--cc=mingo@kernel.org \
--cc=ravi.v.shankar@intel.com \
--cc=tglx@linutronix.de \
/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;
as well as URLs for NNTP newsgroup(s).