From: Ingo Molnar <mingo@kernel.org>
To: Andy Lutomirski <luto@amacapital.net>
Cc: Denys Vlasenko <dvlasenk@redhat.com>,
Brian Gerst <brgerst@gmail.com>,
Denys Vlasenko <vda.linux@googlemail.com>,
Linus Torvalds <torvalds@linux-foundation.org>,
Steven Rostedt <rostedt@goodmis.org>,
Borislav Petkov <bp@alien8.de>, "H. Peter Anvin" <hpa@zytor.com>,
Oleg Nesterov <oleg@redhat.com>,
Frederic Weisbecker <fweisbec@gmail.com>,
Alexei Starovoitov <ast@plumgrid.com>,
Will Drewry <wad@chromium.org>, Kees Cook <keescook@chromium.org>,
X86 ML <x86@kernel.org>,
"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>
Subject: Re: [PATCH] x86: vdso32/syscall.S: do not load __USER32_DS to %ss
Date: Wed, 25 Mar 2015 10:28:45 +0100 [thread overview]
Message-ID: <20150325092845.GA1809@gmail.com> (raw)
In-Reply-To: <CALCETrU=fWvyOf-yWG=UQL4jfhbp1vwzPpBd+eeTLjk94xX+8A@mail.gmail.com>
* Andy Lutomirski <luto@amacapital.net> wrote:
> Now we can do a fun hack on top. On Intel, we have
> sysenter/sysexitl and, on AMD, we have syscall/sysretl. But, if I
> read the docs right, Intel has sysretl, too. So we can ditch
> sysexit entirely, since this mechanism no longer has any need to
> keep the entry and exit conventions matching.
So this only affects 32-bit vdsos, because on 64-bit both Intel and
AMD have and use SYSCALL/SYSRET.
So my question would be: what's the performance difference between
INT80 and sysenter entries on 32-bit, on modern CPUs?
If it's not too horrible (say below 100 cycles) then we could say that
we start out the simplification and robustification by switching Intel
over to INT80 + SYSRET on 32-bit, and once we know the 32-bit SYSRET
and all the other simplifications work fine we implement the
SYSENTER-hack on top of that?
Is there any user-space code that relies on being able to execute an
open coded SYSENTER, or are we shielded via the vDSO?
Doing it this way would make it a lot more practical to pull off, as
the incentive to implement the SYSENTER hack on Intel CPUs will be
significant: dozens of cycles on 32-bit. Also, I have no problem with
putting some pressure on Intel developers, for the absolutely
indefensible horror interface that SYSENTER turned out to be! ;-)
Thanks,
Ingo
next prev parent reply other threads:[~2015-03-25 9:28 UTC|newest]
Thread overview: 16+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-03-23 16:47 [PATCH] x86: vdso32/syscall.S: do not load __USER32_DS to %ss Denys Vlasenko
2015-03-23 19:37 ` Andy Lutomirski
2015-03-23 20:38 ` Andy Lutomirski
2015-03-23 21:55 ` Denys Vlasenko
2015-03-24 6:34 ` Ingo Molnar
2015-03-24 14:08 ` Denys Vlasenko
2015-03-24 15:50 ` Ingo Molnar
2015-03-24 16:55 ` Brian Gerst
2015-03-24 20:17 ` Denys Vlasenko
2015-03-24 21:40 ` Andy Lutomirski
2015-03-25 9:28 ` Ingo Molnar [this message]
2015-03-25 15:03 ` Denys Vlasenko
2015-03-25 15:17 ` Andy Lutomirski
2015-03-25 14:55 ` Denys Vlasenko
2015-03-25 15:12 ` Andy Lutomirski
2015-03-25 0:59 ` Brian Gerst
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=20150325092845.GA1809@gmail.com \
--to=mingo@kernel.org \
--cc=ast@plumgrid.com \
--cc=bp@alien8.de \
--cc=brgerst@gmail.com \
--cc=dvlasenk@redhat.com \
--cc=fweisbec@gmail.com \
--cc=hpa@zytor.com \
--cc=keescook@chromium.org \
--cc=linux-kernel@vger.kernel.org \
--cc=luto@amacapital.net \
--cc=oleg@redhat.com \
--cc=rostedt@goodmis.org \
--cc=torvalds@linux-foundation.org \
--cc=vda.linux@googlemail.com \
--cc=wad@chromium.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.