All of lore.kernel.org
 help / color / mirror / Atom feed
From: Peter Zijlstra <peterz@infradead.org>
To: Andy Lutomirski <luto@kernel.org>
Cc: X86 ML <x86@kernel.org>, Borislav Petkov <bp@alien8.de>,
	LKML <linux-kernel@vger.kernel.org>,
	Dave Hansen <dave.hansen@linux.intel.com>,
	Adrian Hunter <adrian.hunter@intel.com>,
	Alexander Shishkin <alexander.shishkin@linux.intel.com>,
	Arnaldo Carvalho de Melo <acme@kernel.org>,
	Linus Torvalds <torvalds@linux-foundation.org>,
	Josh Poimboeuf <jpoimboe@redhat.com>,
	Joerg Roedel <joro@8bytes.org>, Jiri Olsa <jolsa@redhat.com>,
	Andi Kleen <ak@linux.intel.com>
Subject: Re: [PATCH v2 3/3] x86/pti/64: Remove the SYSCALL64 entry trampoline
Date: Fri, 7 Sep 2018 14:36:51 +0200	[thread overview]
Message-ID: <20180907123651.GZ24106@hirez.programming.kicks-ass.net> (raw)
In-Reply-To: <CALCETrUZm3KsonYVd5sn=LhoGZ2ciO7xT_Fz=jD_HZ04tB9o=Q@mail.gmail.com>

On Wed, Sep 05, 2018 at 02:31:28PM -0700, Andy Lutomirski wrote:
> On Tue, Sep 4, 2018 at 12:04 AM, Peter Zijlstra <peterz@infradead.org> wrote:
> > On Mon, Sep 03, 2018 at 03:59:44PM -0700, Andy Lutomirski wrote:

> >> There is a possible alternative approach: we could instead move the
> >> trampoline within 2G of the entry text and make a separate copy for
> >> each CPU.  Then we could use a direct jump to rejoin the normal
> >> entry path.
> >
> > Can we have a few words on why this solution and not this alternative? I
> > mean, you raise the possibility, but then surely you chose not to
> > implement that. Might as well share that with us.
> 
> I can give some pros and cons.  With the other approach:
> 
>  - We avoid a pipeline stall.
>  - We execute from an extra page and read from another extra page
> during the syscall.  (The latter is because we need to use a relative
> addressing mode to find sp1 -- it's the same *cacheline* we'd use
> anyway, but we're accessing it using an alias, so it's an extra TLB
> entry.)
>  - We use more memory.  This would be one page per CPU for a simple
> implementation and 64-ish bytes per CPU or one page per node for a
> more complex implementation.
>  - More code complexity.
> 
> I'm not convinced this is a good tradeoff.

Fair enough, thanks!

  reply	other threads:[~2018-09-07 12:39 UTC|newest]

Thread overview: 24+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-09-03 22:59 [PATCH v2 0/3] x86/pti: Get rid of entry trampolines and add some docs Andy Lutomirski
2018-09-03 22:59 ` [PATCH v2 1/3] x86/entry/64: Document idtentry Andy Lutomirski
2018-09-06  9:50   ` Borislav Petkov
2018-09-08  9:33   ` [tip:x86/pti] " tip-bot for Andy Lutomirski
2018-09-03 22:59 ` [PATCH v2 2/3] x86/entry/64: Use the TSS sp2 slot for SYSCALL/SYSRET scratch space Andy Lutomirski
2018-09-07  8:00   ` Borislav Petkov
2018-09-08  9:34   ` [tip:x86/pti] " tip-bot for Andy Lutomirski
2018-09-03 22:59 ` [PATCH v2 3/3] x86/pti/64: Remove the SYSCALL64 entry trampoline Andy Lutomirski
2018-09-04  7:04   ` Peter Zijlstra
2018-09-05 21:31     ` Andy Lutomirski
2018-09-07 12:36       ` Peter Zijlstra [this message]
2018-09-07 19:54       ` Thomas Gleixner
2018-09-08  0:04         ` Linus Torvalds
2018-09-08  4:32           ` Andy Lutomirski
2018-09-08  6:36             ` Thomas Gleixner
2018-09-08  6:33           ` Thomas Gleixner
2018-09-07  9:35   ` Borislav Petkov
2018-09-07 16:40   ` Josh Poimboeuf
2018-09-08  4:35     ` Andy Lutomirski
2018-09-08  9:35   ` [tip:x86/pti] " tip-bot for Andy Lutomirski
2018-09-08  9:57   ` tip-bot for Andy Lutomirski
2018-09-12 19:33   ` tip-bot for Andy Lutomirski
2018-09-12 19:36   ` tip-bot for Andy Lutomirski
2018-09-04  3:43 ` [PATCH v2 0/3] x86/pti: Get rid of entry trampolines and add some docs Linus Torvalds

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=20180907123651.GZ24106@hirez.programming.kicks-ass.net \
    --to=peterz@infradead.org \
    --cc=acme@kernel.org \
    --cc=adrian.hunter@intel.com \
    --cc=ak@linux.intel.com \
    --cc=alexander.shishkin@linux.intel.com \
    --cc=bp@alien8.de \
    --cc=dave.hansen@linux.intel.com \
    --cc=jolsa@redhat.com \
    --cc=joro@8bytes.org \
    --cc=jpoimboe@redhat.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=luto@kernel.org \
    --cc=torvalds@linux-foundation.org \
    --cc=x86@kernel.org \
    /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.