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 S1751427AbdK0JOd (ORCPT <rfc822;w@1wt.eu>);
        Mon, 27 Nov 2017 04:14:33 -0500
Received: from merlin.infradead.org ([205.233.59.134]:48146 "EHLO
        merlin.infradead.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org
        with ESMTP id S1751277AbdK0JOb (ORCPT
        <rfc822;linux-kernel@vger.kernel.org>);
        Mon, 27 Nov 2017 04:14:31 -0500
Date: Mon, 27 Nov 2017 10:14:24 +0100
From: Peter Zijlstra <peterz@infradead.org>
To: Andy Lutomirski <luto@kernel.org>
Cc: Ingo Molnar <mingo@kernel.org>,
        "linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
        Dave Hansen <dave.hansen@linux.intel.com>,
        Thomas Gleixner <tglx@linutronix.de>,
        "H . Peter Anvin" <hpa@zytor.com>, Borislav Petkov <bp@alien8.de>,
        Linus Torvalds <torvalds@linux-foundation.org>
Subject: Re: [PATCH 30/43] x86/mm/kaiser: Map espfix structures
Message-ID: <20171127091424.zvfg7fsr7v2kfxnl@hirez.programming.kicks-ass.net>
References: <20171124091448.7649-1-mingo@kernel.org>
 <20171124091448.7649-31-mingo@kernel.org>
 <20171124134740.6dmv6nfo5ihrkj3f@hirez.programming.kicks-ass.net>
 <CALCETrVyBC=kk4zLLYyQ_YTg5gaMpOGzpr9p7u_mBOGff=PuUA@mail.gmail.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <CALCETrVyBC=kk4zLLYyQ_YTg5gaMpOGzpr9p7u_mBOGff=PuUA@mail.gmail.com>
User-Agent: NeoMutt/20170609 (1.8.3)
Sender: linux-kernel-owner@vger.kernel.org
List-ID: <linux-kernel.vger.kernel.org>
X-Mailing-List: linux-kernel@vger.kernel.org

On Fri, Nov 24, 2017 at 08:17:06AM -0800, Andy Lutomirski wrote:
> On Fri, Nov 24, 2017 at 5:47 AM, Peter Zijlstra <peterz@infradead.org> wrote:
> > On Fri, Nov 24, 2017 at 10:14:35AM +0100, Ingo Molnar wrote:
> >> From: Dave Hansen <dave.hansen@linux.intel.com>
> >>
> >> There is some rather arcane code to help when an IRET returns
> >> to 16-bit segments.  It is referred to as the "espfix" code.
> >> This consists of a few per-cpu variables:
> >>
> >>       espfix_stack: tells us where the stack is allocated
> >>                     (the bottom)
> >>       espfix_waddr: tells us to where %rsp may be pointed
> >>                     (the top)
> >>
> >> These are in addition to the stack itself.  All three things must
> >> be mapped for the espfix code to function.
> >>
> >> Note: the espfix code runs with a kernel GSBASE, but user
> >> (shadow) page tables.  A switch to the kernel page tables could
> >> be performed instead of mapping these structures, but mapping
> >> them is simpler and less likely to break the assembly.  To switch
> >> over to the kernel copy, additional temporary storage would be
> >> required which is in short supply in this context.
> >
> > With Andy's patches that should actually be doable, no?
> 
> I don't think it has much to do with my patches.  We can freely spill
> to the stack in the espfix64 code, though.

Ah, I was thinking of how you made scratch space easier for the SYSENTER
stuff.

But if we can freely spill here, should we not do the kernel switch
instead of doing this user mapping? The way I understand things, the
less of these magic mappings we have the better.