Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752360AbbB1Ntm (ORCPT ); Sat, 28 Feb 2015 08:49:42 -0500 Received: from cantor2.suse.de ([195.135.220.15]:54040 "EHLO mx2.suse.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751464AbbB1Ntk (ORCPT ); Sat, 28 Feb 2015 08:49:40 -0500 Date: Sat, 28 Feb 2015 14:48:32 +0100 From: Borislav Petkov To: Alexander Kuleshov Cc: Thomas Gleixner , Ingo Molnar , "H. Peter Anvin" , linux-kernel@vger.kernel.org Subject: Re: [PATCH] x86-64: no need to fix up physical addresses if they are correct Message-ID: <20150228134832.GB11038@pd.tnic> References: <1425130460-29807-1-git-send-email-kuleshovmail@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: <1425130460-29807-1-git-send-email-kuleshovmail@gmail.com> User-Agent: Mutt/1.5.23 (2014-03-12) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 1891 Lines: 52 On Sat, Feb 28, 2015 at 07:34:20PM +0600, Alexander Kuleshov wrote: > If kernel doesn't use kASLR and runned on the same address that was > compiled to run, %rbp will be zero and no need to fix physical addresses > in the page tables. > > Signed-off-by: Alexander Kuleshov > --- > arch/x86/kernel/head_64.S | 9 +++++++++ > 1 file changed, 9 insertions(+) > > diff --git a/arch/x86/kernel/head_64.S b/arch/x86/kernel/head_64.S > index 6fd514d9..c0127bc 100644 > --- a/arch/x86/kernel/head_64.S > +++ b/arch/x86/kernel/head_64.S > @@ -86,6 +86,14 @@ startup_64: > jnz bad_address > > /* > + * We have no need to fixup the physical addresses in the page tables > + * if there is no difference between the address where kernel compiled > + * to run and the actual address where kernel running at. > + */ > + cmpq $0x0, %rbp > + je 1f No thanks - this is saving 4 ADDs which probably execute even in parallel on modern out-of-order x86, for the price of more code in asm which people would have to spend mental energy on in the future without any apparent gain. If you really want to help out with kernel development, I'd suggest you try fixing real bugs. You could read lkml and try to understand and debug the issues people are reporting, get a box and start testing linux-next every day and search the net for kernelnewbies (IRC channel etc) for things to do. Another great exercise is building randconfigs and trying to boot them with kvm and see what splats happen - believe me, lots of them. I sincerely hope that helps. -- Regards/Gruss, Boris. ECO tip #101: Trim your mails when you reply. -- -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/