From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <linux-kernel-owner@vger.kernel.org>
Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand
        id S1755013AbdKBMpg (ORCPT <rfc822;w@1wt.eu>);
        Thu, 2 Nov 2017 08:45:36 -0400
Received: from Galois.linutronix.de ([146.0.238.70]:54118 "EHLO
        Galois.linutronix.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org
        with ESMTP id S1751898AbdKBMpe (ORCPT
        <rfc822;linux-kernel@vger.kernel.org>);
        Thu, 2 Nov 2017 08:45:34 -0400
Date: Thu, 2 Nov 2017 13:45:31 +0100 (CET)
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)
In-Reply-To: <89E52C9C-DBAB-4661-8172-0F6307857870@amacapital.net>
Message-ID: <alpine.DEB.2.20.1711021343380.2090@nanos>
References: <CALCETrXLJfmTg1MsQHKCL=WL-he_5wrOqeX2OatQCCqVE003VQ@mail.gmail.com> <alpine.DEB.2.20.1711021235290.2090@nanos> <89E52C9C-DBAB-4661-8172-0F6307857870@amacapital.net>
User-Agent: Alpine 2.20 (DEB 67 2015-01-07)
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Sender: linux-kernel-owner@vger.kernel.org
List-ID: <linux-kernel.vger.kernel.org>
X-Mailing-List: linux-kernel@vger.kernel.org

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