Received: by 10.223.176.46 with SMTP id f43csp3188702wra; Mon, 22 Jan 2018 09:47:45 -0800 (PST) X-Google-Smtp-Source: AH8x224G6bP/DD1+Pgolq6lj5Xtv8AtHUPvUXlALfXwxlCcP3HEid+YOME0r42qS1bt877HHQ/st X-Received: by 10.107.11.130 with SMTP id 2mr9558616iol.80.1516643265870; Mon, 22 Jan 2018 09:47:45 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1516643265; cv=none; d=google.com; s=arc-20160816; b=p+dlQ7R7A/EpPaFUI1gL7tkC0rKolnUNPG39CeCofzeafKLMOpiTwhda1CIkrVQWBU XwxFbX8YeHH/V3XG6mjEvexfA+azH6VDU10oQ4Ie4Rw2QF9sWQuEa1ab+Qj+xdMXZfwq sb9HhZeJ1OW8qoIRd45dYguhhwbZh+O42bcHDRnYiFNaYlQXM3SS7a+DGIjVFJv81Df9 Bx2AsUPyeC7StjcF0h5XWlyGXwk+YkM45CloZp+Qw9bXSriP/isEuh8C2B055Tjwgzbs gcsqe9Em6GLxgeSvlNLp51Ful8Kd+c+VReIKu3z4fYaWE0NnshT0vopV8wuTDWm0JAOo zzuA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:cc:to:subject:message-id:date:from :references:in-reply-to:mime-version:dmarc-filter :arc-authentication-results; bh=w/OGcBPUT2fVLB1zO3YtaFlp9A3q9iWVHxFY/5bLd+8=; b=Exlj5TH8sYiRlAq8P9nViG0hw4UD09b0oPRo0YGalDPnJk9mFp2nB0VzDtJc9ynoGR yPW2DvvCjJ2e98ycmayltqM9EfT3AgvMD1ei8hDp02L1i694fU7ZKf+poN5da9UX0AFX lI64YAZCcl9ukEZvB7ljZVlJc++njxOpWWrIviuIAij2CN+VP3TAGhDWqsvYi/pjWMcJ ejh5/Jc7PdyDcSo1+pnx8D3ic5b2F0uQhmj0HJV3HFF/JGbqODcGmhojlfvLy9eWUo2e wW5SeMmNMN1zXI8CzEY9f643Sg54khT6EcWhEgFyeZujsNr75oaTK4f2R9Z7h1BJ4Uo1 IqqQ== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id k63si12926222iof.149.2018.01.22.09.47.32; Mon, 22 Jan 2018 09:47:45 -0800 (PST) Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1751273AbeAVRrA (ORCPT + 99 others); Mon, 22 Jan 2018 12:47:00 -0500 Received: from mail.kernel.org ([198.145.29.99]:47970 "EHLO mail.kernel.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751102AbeAVRqp (ORCPT ); Mon, 22 Jan 2018 12:46:45 -0500 Received: from mail-io0-f181.google.com (mail-io0-f181.google.com [209.85.223.181]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPSA id 34A6821796 for ; Mon, 22 Jan 2018 17:46:45 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 34A6821796 Authentication-Results: mail.kernel.org; dmarc=none (p=none dis=none) header.from=kernel.org Authentication-Results: mail.kernel.org; spf=none smtp.mailfrom=luto@kernel.org Received: by mail-io0-f181.google.com with SMTP id n7so10302968iob.0 for ; Mon, 22 Jan 2018 09:46:45 -0800 (PST) X-Gm-Message-State: AKwxytc93ieVxJo7WVtQD6ds+/dsloXA9LNJA0gTQom4QPcseMqruNID 8c4R9vBbFf86s29b/BO8zRPpriYvB7mdXsGRAWfcpQ== X-Received: by 10.107.170.132 with SMTP id g4mr8487614ioj.183.1516643204498; Mon, 22 Jan 2018 09:46:44 -0800 (PST) MIME-Version: 1.0 Received: by 10.2.137.84 with HTTP; Mon, 22 Jan 2018 09:46:24 -0800 (PST) In-Reply-To: <20180122101118.GG28161@8bytes.org> References: <1516120619-1159-1-git-send-email-joro@8bytes.org> <1516120619-1159-3-git-send-email-joro@8bytes.org> <20180117091853.GI28161@8bytes.org> <20180119095523.GY28161@8bytes.org> <20180122101118.GG28161@8bytes.org> From: Andy Lutomirski Date: Mon, 22 Jan 2018 09:46:24 -0800 X-Gmail-Original-Message-ID: Message-ID: Subject: Re: [PATCH 02/16] x86/entry/32: Enter the kernel via trampoline stack To: Joerg Roedel Cc: Andy Lutomirski , Thomas Gleixner , Ingo Molnar , "H . Peter Anvin" , X86 ML , LKML , Linux-MM , Linus Torvalds , Dave Hansen , Josh Poimboeuf , Juergen Gross , Peter Zijlstra , Borislav Petkov , Jiri Kosina , Boris Ostrovsky , Brian Gerst , David Laight , Denys Vlasenko , Eduardo Valentin , Greg KH , Will Deacon , "Liguori, Anthony" , Daniel Gruss , Hugh Dickins , Kees Cook , Andrea Arcangeli , Waiman Long , Joerg Roedel Content-Type: text/plain; charset="UTF-8" Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Mon, Jan 22, 2018 at 2:11 AM, Joerg Roedel wrote: > Hey Andy, > > On Fri, Jan 19, 2018 at 08:30:33AM -0800, Andy Lutomirski wrote: >> I meant that we could have sp0 have a genuinely constant value per >> cpu. That means that the entry trampoline ends up with RIP, etc in a >> different place depending on whether VM was in use, but the entry >> trampoline code should be able to handle that. sp1 would have a value >> that varies by task, but it could just point to the top of the stack >> instead of being changed depending on whether VM is in use. Instead, >> the entry trampoline would offset the registers as needed to keep >> pt_regs in the right place. >> >> I think you already figured all of that out, though :) > > Yes, and after looking a while into it, it would make a nice cleanup for > the entry code. On the other side, it would change the layout for the > in-kernel 'struct pt_regs', so that the user-visible pt_regs ends up > with a different layout than the one we use in the the kernel. I don't think this is necessarily the case. We end up with four more fields that are logically there at the end of pt_regs (which is already kind-of-sort-of the case), but we don't actually need to put them in struct pt_regs. We just end up with (regs + 1) != "top of task stack", but even that has precedent -- it's already true for tasks in vm86 mode. > > This can certainly be all worked out, but it makes this nice entry-code > cleanup not so nice and clean anymore. At least the work required to > make it work without breaking user-space is not in the scope of this > patch-set. Agreed. This should probably be saved for later. Except that your patch set still needs to come up with some way to function correctly on vm86.