From: Thomas Gleixner <tglx@linutronix.de>
To: Andy Lutomirski <luto@amacapital.net>
Cc: Andy Lutomirski <luto@kernel.org>,
Dave Hansen <dave.hansen@linux.intel.com>,
"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
"linux-mm@kvack.org" <linux-mm@kvack.org>,
moritz.lipp@iaik.tugraz.at,
Daniel Gruss <daniel.gruss@iaik.tugraz.at>,
michael.schwarz@iaik.tugraz.at,
Linus Torvalds <torvalds@linux-foundation.org>,
Kees Cook <keescook@google.com>, Hugh Dickins <hughd@google.com>,
X86 ML <x86@kernel.org>, Borislav Petkov <bp@alien8.de>,
Josh Poimboeuf <jpoimboe@redhat.com>
Subject: Re: KAISER memory layout (Re: [PATCH 06/23] x86, kaiser: introduce user-mapped percpu areas)
Date: Thu, 2 Nov 2017 13:45:31 +0100 (CET) [thread overview]
Message-ID: <alpine.DEB.2.20.1711021343380.2090@nanos> (raw)
In-Reply-To: <89E52C9C-DBAB-4661-8172-0F6307857870@amacapital.net>
On Thu, 2 Nov 2017, Andy Lutomirski wrote:
> > On Nov 2, 2017, at 12:48 PM, Thomas Gleixner <tglx@linutronix.de> wrote:
> >
> >> On Thu, 2 Nov 2017, Andy Lutomirski wrote:
> >> I think we're far enough along here that it may be time to nail down
> >> the memory layout for real. I propose the following:
> >>
> >> The user tables will contain the following:
> >>
> >> - The GDT array.
> >> - The IDT.
> >> - The vsyscall page. We can make this be _PAGE_USER.
> >
> > I rather remove it for the kaiser case.
> >
> >> - The TSS.
> >> - The per-cpu entry stack. Let's make it one page with guard pages
> >> on either side. This can replace rsp_scratch.
> >> - cpu_current_top_of_stack. This could be in the same page as the TSS.
> >> - The entry text.
> >> - The percpu IST (aka "EXCEPTION") stacks.
> >
> > Do you really want to put the full exception stacks into that user mapping?
> > I think we should not do that. There are two options:
> >
> > 1) Always use the per-cpu entry stack and switch to the proper IST after
> > the CR3 fixup
>
> Can't -- it's microcode, not software, that does that switch.
Well, yes. The micro code does the stack switch to ISTs but software tells
it to do so. We write the IDT IIRC.
> > 2) Have separate per-cpu entry stacks for the ISTs and switch to the real
> > ones after the CR3 fixup.
>
> How is that simpler?
Simpler is not the question. I want to avoid mapping the whole IST stacks.
Thanks,
tglx
next prev parent reply other threads:[~2017-11-02 12:45 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-11-02 9:41 KAISER memory layout (Re: [PATCH 06/23] x86, kaiser: introduce user-mapped percpu areas) Andy Lutomirski
2017-11-02 11:48 ` Thomas Gleixner
2017-11-02 12:00 ` Andy Lutomirski
2017-11-02 12:45 ` Thomas Gleixner [this message]
2017-11-02 15:36 ` Andy Lutomirski
2017-11-02 16:03 ` Thomas Gleixner
2017-11-02 16:36 ` Dave Hansen
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=alpine.DEB.2.20.1711021343380.2090@nanos \
--to=tglx@linutronix.de \
--cc=bp@alien8.de \
--cc=daniel.gruss@iaik.tugraz.at \
--cc=dave.hansen@linux.intel.com \
--cc=hughd@google.com \
--cc=jpoimboe@redhat.com \
--cc=keescook@google.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=luto@amacapital.net \
--cc=luto@kernel.org \
--cc=michael.schwarz@iaik.tugraz.at \
--cc=moritz.lipp@iaik.tugraz.at \
--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 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).