From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Google-Smtp-Source: ACJfBosiCssoExNfchxKS7gVJTJ1//Uf28jcFyyZo+3KekpnZux4UxoodcX9CequvM/tFrpQiuAb ARC-Seal: i=1; a=rsa-sha256; t=1516355728; cv=none; d=google.com; s=arc-20160816; b=bbEq1NaV5dVMrpJADbjAAxWG+CcHE9OSQAoAA4+B69cY9WsY/hAScob5sEFEu2lAcu 68Wefg2kbff30GBDDHxucZg+x0UPpEwDkfzQMk/6XWa5eWbng08cm1SRArdnd+oT2DSX RtofBwwCiEdDH6EkdJ4sPoGQ1+V7DbaHk9XJDSDLXf7DDN7ChBL+Aaj0MyPhB60+b1nT eNSKy/XMPULkQYVwVATkpDWxry81J6AmYw3foFn0Rtnn6nSOKvxCWdLeolxB4p6T8lUV ORZl6GfG9SC1K+3qn3ttImLcJpj6iVlxClTTD1Kt5IXxG4Nwvx5/LS6DwDFN6ju0MWp5 fOXA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=user-agent:in-reply-to:content-disposition:mime-version:references :message-id:subject:cc:to:from:date:dkim-signature :arc-authentication-results; bh=WCvyRMFFhQfC22TyOKDUHXiPjAg0F0VKvWDrZ6PmTZY=; b=Ou/w99FSu5iQIvkxK2UDOLbLVmhdy9hTmynLf7Dx0spUOS5fjTbO1rLcXKWO87edV8 gYmhhUq/3PQEpuaD3GEjBWj8yobQOoAeaJMpGe+3rEeKGZ9fZQF3B1eaFJtwLMIflGDd BkWKqCgHoCSqx3MEOZzU8/Dr8Zg1oWhZXrf6V3zSpxqeML7X2UGYZmkyxCjrEgaTXDBJ x4STskFc0iWK5BCGfJ/s4KBU++aDMbkTwXSWioGhfFEeFKDzdP0UqGXXm/p46S9pTmdy dZ9vx97QxPNdJSJSXR5vrVmG4v3erDBnd9wCgkvz1kzobwr37Zktz5bRLqlaY0sPLoNW 86gw== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass (test mode) header.i=@8bytes.org header.s=mail-1 header.b=I6a9vpxp; spf=pass (google.com: domain of joro@8bytes.org designates 2a01:238:4383:600:38bc:a715:4b6d:a889 as permitted sender) smtp.mailfrom=joro@8bytes.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=8bytes.org Authentication-Results: mx.google.com; dkim=pass (test mode) header.i=@8bytes.org header.s=mail-1 header.b=I6a9vpxp; spf=pass (google.com: domain of joro@8bytes.org designates 2a01:238:4383:600:38bc:a715:4b6d:a889 as permitted sender) smtp.mailfrom=joro@8bytes.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=8bytes.org Date: Fri, 19 Jan 2018 10:55:23 +0100 From: Joerg Roedel To: Andy Lutomirski Cc: Thomas Gleixner , Ingo Molnar , "H . Peter Anvin" , X86 ML , LKML , linux-mm@kvack.org, 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 Subject: Re: [PATCH 02/16] x86/entry/32: Enter the kernel via trampoline stack Message-ID: <20180119095523.GY28161@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> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.24 (2015-08-30) X-getmail-retrieved-from-mailbox: INBOX X-GMAIL-THRID: =?utf-8?q?1589767841589420443?= X-GMAIL-MSGID: =?utf-8?q?1590014223528376974?= X-Mailing-List: linux-kernel@vger.kernel.org List-ID: Hey Andy, On Wed, Jan 17, 2018 at 10:10:23AM -0800, Andy Lutomirski wrote: > On Wed, Jan 17, 2018 at 1:18 AM, Joerg Roedel wrote: > > Just read up on vm86 mode control transfers and the stack layout then. > > Looks like I need to check for eflags.vm=1 and copy four more registers > > from/to the entry stack. Thanks for pointing that out. > > You could just copy those slots unconditionally. After all, you're > slowing down entries by an epic amount due to writing CR3 on with PCID > off, so four words copied should be entirely lost in the noise. OTOH, > checking for VM86 mode is just a single bt against EFLAGS. > > With the modern (rewritten a year or two ago by Brian Gerst) vm86 > code, all the slots (those actually in pt_regs) are in the same > location regardless of whether we're in VM86 mode or not, but we're > still fiddling with the bottom of the stack. Since you're controlling > the switch to the kernel thread stack, you can easily just write the > frame to the correct location, so you should not need to context > switch sp1 -- you can do it sanely and leave sp1 as the actual bottom > of the kernel stack no matter what. In fact, you could probably avoid > context switching sp0, either, which would be a nice cleanup. I am not sure what you mean by "not context switching sp0/sp1" ... > So I recommend the following. Keep sp0 as the bottom of the sysenter > stack no matter what. Then do: > > bt $X86_EFLAGS_VM_BIT > jc .Lfrom_vm_\@ > > push 5 regs to real stack, starting at four-word offset (so they're in > the right place) > update %esp > ... > .Lupdate_esp_\@ > > .Lfrom_vm_\@: > push 9 regs to real stack, starting at the bottom > jmp .Lupdate_esp_\@ > > Does that seem reasonable? It's arguably much nicer than what we have > now. But that looks like a good idea. Having a consistent stack with and without vm86 is certainly a nice cleanup. Regards, Joerg From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-wm0-f72.google.com (mail-wm0-f72.google.com [74.125.82.72]) by kanga.kvack.org (Postfix) with ESMTP id CECB56B025E for ; Fri, 19 Jan 2018 04:55:29 -0500 (EST) Received: by mail-wm0-f72.google.com with SMTP id 194so804918wmv.9 for ; Fri, 19 Jan 2018 01:55:29 -0800 (PST) Received: from theia.8bytes.org (8bytes.org. [2a01:238:4383:600:38bc:a715:4b6d:a889]) by mx.google.com with ESMTPS id p4si1782281edm.328.2018.01.19.01.55.25 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 19 Jan 2018 01:55:25 -0800 (PST) Date: Fri, 19 Jan 2018 10:55:23 +0100 From: Joerg Roedel Subject: Re: [PATCH 02/16] x86/entry/32: Enter the kernel via trampoline stack Message-ID: <20180119095523.GY28161@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> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: Sender: owner-linux-mm@kvack.org List-ID: To: Andy Lutomirski Cc: Thomas Gleixner , Ingo Molnar , "H . Peter Anvin" , X86 ML , LKML , linux-mm@kvack.org, 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 Hey Andy, On Wed, Jan 17, 2018 at 10:10:23AM -0800, Andy Lutomirski wrote: > On Wed, Jan 17, 2018 at 1:18 AM, Joerg Roedel wrote: > > Just read up on vm86 mode control transfers and the stack layout then. > > Looks like I need to check for eflags.vm=1 and copy four more registers > > from/to the entry stack. Thanks for pointing that out. > > You could just copy those slots unconditionally. After all, you're > slowing down entries by an epic amount due to writing CR3 on with PCID > off, so four words copied should be entirely lost in the noise. OTOH, > checking for VM86 mode is just a single bt against EFLAGS. > > With the modern (rewritten a year or two ago by Brian Gerst) vm86 > code, all the slots (those actually in pt_regs) are in the same > location regardless of whether we're in VM86 mode or not, but we're > still fiddling with the bottom of the stack. Since you're controlling > the switch to the kernel thread stack, you can easily just write the > frame to the correct location, so you should not need to context > switch sp1 -- you can do it sanely and leave sp1 as the actual bottom > of the kernel stack no matter what. In fact, you could probably avoid > context switching sp0, either, which would be a nice cleanup. I am not sure what you mean by "not context switching sp0/sp1" ... > So I recommend the following. Keep sp0 as the bottom of the sysenter > stack no matter what. Then do: > > bt $X86_EFLAGS_VM_BIT > jc .Lfrom_vm_\@ > > push 5 regs to real stack, starting at four-word offset (so they're in > the right place) > update %esp > ... > .Lupdate_esp_\@ > > .Lfrom_vm_\@: > push 9 regs to real stack, starting at the bottom > jmp .Lupdate_esp_\@ > > Does that seem reasonable? It's arguably much nicer than what we have > now. But that looks like a good idea. Having a consistent stack with and without vm86 is certainly a nice cleanup. Regards, Joerg -- 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