Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1753906AbbBTCV4 (ORCPT ); Thu, 19 Feb 2015 21:21:56 -0500 Received: from mx1.redhat.com ([209.132.183.28]:46638 "EHLO mx1.redhat.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1753854AbbBTCVz (ORCPT ); Thu, 19 Feb 2015 21:21:55 -0500 Date: Fri, 20 Feb 2015 10:13:06 +0800 From: Baoquan He To: Yinghai Lu Cc: Linux Kernel Mailing List Subject: Re: [PATCH] x86, boot: Allow 64bit EFI kernel to be loaded above 4G Message-ID: <20150220021306.GA2621@dhcp-17-102.nay.redhat.com> References: <1423015400-12629-1-git-send-email-yinghai@kernel.org> <20150211061148.GA4448@dhcp-17-102.nay.redhat.com> <20150218112956.GA1965@dhcp-17-102.nay.redhat.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 1970 Lines: 46 On 02/18/15 at 11:47am, Yinghai Lu wrote: > On Wed, Feb 18, 2015 at 3:29 AM, Baoquan He wrote: > > On 02/17/15 at 11:22pm, Yinghai Lu wrote: > >> On Tue, Feb 10, 2015 at 10:11 PM, Baoquan He wrote: > > I am sorry I didn't get what you mean. I have tried to set another ident > > mapping for new range and it is successful seeing from debug message > > printing. However it always reboot because of GPF. That's why I made > > that small debug patch which add another 4G ident mapping and hardcoded > > to put kernel between 4G and 8G. > > > > Could you say more of it? Or which direction should I go? > > I would suggest: > leave physical address random handling to bootloader, as bootloader always > need to set ident mapping to cover kernel/bootparam/cmdline. > > For virtual address random handling it should go kasl in kernel. Kaslr need both virtual and physical address be randomized, otherwise it doesn't make sense. Please check what hpa said about this issue: https://lkml.org/lkml/2014/10/13/350 And usually no bootloader often load kernel onto a random physical address. Fow now we can often see kexec/kdump did this. I believe Kees introduced kaslr to mainly solve security issue of normal kernel which is not like kexec/kdump for testing or debugging. Randomizing physical address makes sense for kaslr feature. In normal kernel it jump from 32bit to 64bit and enter into 64bit mode of long mode. I am wondering why it will cause a GPF when kernel is put above 4G. Adding a IDT and #PF handler to solve the ident page mapping on demand has been done now, I am blocked by the GPF now, otherwise I can post it very soon for testing. Thanks Baoquan > > Thanks > > Yinghai -- 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/