From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-io0-f200.google.com (mail-io0-f200.google.com [209.85.223.200]) by kanga.kvack.org (Postfix) with ESMTP id AC6E3800D8 for ; Mon, 22 Jan 2018 12:46:47 -0500 (EST) Received: by mail-io0-f200.google.com with SMTP id e2so3307313ioa.22 for ; Mon, 22 Jan 2018 09:46:47 -0800 (PST) Received: from mail.kernel.org (mail.kernel.org. [198.145.29.99]) by mx.google.com with ESMTPS id h71si13132473ioe.267.2018.01.22.09.46.45 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 22 Jan 2018 09:46:46 -0800 (PST) Received: from mail-io0-f171.google.com (mail-io0-f171.google.com [209.85.223.171]) (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 2EA972178F for ; Mon, 22 Jan 2018 17:46:45 +0000 (UTC) Received: by mail-io0-f171.google.com with SMTP id f4so8508167ioh.8 for ; Mon, 22 Jan 2018 09:46:45 -0800 (PST) MIME-Version: 1.0 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 Message-ID: Subject: Re: [PATCH 02/16] x86/entry/32: Enter the kernel via trampoline stack Content-Type: text/plain; charset="UTF-8" Sender: owner-linux-mm@kvack.org List-ID: 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 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. -- To unsubscribe, send a message with 'unsubscribe linux-mm' in the body to majordomo@kvack.org. For more info on Linux MM, see: http://www.linux-mm.org/ . Don't email: email@kvack.org