Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1755324AbbBUCto (ORCPT ); Fri, 20 Feb 2015 21:49:44 -0500 Received: from mx1.redhat.com ([209.132.183.28]:53497 "EHLO mx1.redhat.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1754985AbbBUCtn (ORCPT ); Fri, 20 Feb 2015 21:49:43 -0500 Date: Sat, 21 Feb 2015 10:49:23 +0800 From: Baoquan He To: Yinghai Lu Cc: "H. Peter Anvin" , Linux Kernel Mailing List Subject: Re: [PATCH] x86, boot: Allow 64bit EFI kernel to be loaded above 4G Message-ID: <20150221024738.GA2899@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> <20150220021306.GA2621@dhcp-17-102.nay.redhat.com> <20150220092859.GA1572@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: 2766 Lines: 59 On 02/20/15 at 03:53pm, Yinghai Lu wrote: > On Fri, Feb 20, 2015 at 1:28 AM, Baoquan He wrote: > > > > Actually kexec is a bootloader which can put kernel at any address. This > > is done in user space program kexec-tools. However kexec-tools make > > kernel jump from 64bit into 64bit directly, and has built ident mapping > > of whole physical memory. I have tried this and it works. kexec is > > mainly used for kernel developer, kaslr is meaningless for kexec. > > > > However kaslr focus on normal kernel, and jump from 32bit to 64bit mode. > > I can't figure out a way to work around this. > > > > Now I just want to figure out what register setting cause GPF when > > reload kernel above 4G in this jumping from 32bit to 64bit way. > > Then you are not setting the ident mapping correctly. > > you should make sure add extra ident mapping for the new [output, > output+output_len - 1]. > bootloader only cover old [output, output+output_len - 1] > > and you should check if the mapping is present before add new one, > otherwise will overrite > the one from 64bit bootloader like kexec-tools or grub2-x86_64 etc. > > You could use kernel_ident_mapping_init() from arch/x86/mm/init_64.c > --- may need to cut and paste or split and include to > arch/x86/boot/compressed/misc.c > also you need to find some pages for alloc_pgt_page. At the beginning I did it just as you said, add IDT table and $PF handler. Get page fault address and built ident mapping around it when reload kernel above 4G. In this case 3 more pages are enough if kernel is put to another 512G and cross the boundary of 512G. kernel_ident_mapping_init code can be borrowed and need be adjusted a little bit. This works as expected, but a GPF reported and reboot to BIOS. That's why I made a simple debug patch as I pasted before to filter unnecessary interference. Since in arch/x86/boot/compressed/head_64.S 6 pages are used, 1 for pgd, 1 for pud, 4 for pmd, all of them cover 0~4G ident mapping. So I added 4 more pages as pmd, then 0~8G are covered. Now I hardcoded the output of randomization of physical address as 5G, means kernel will be reloaded there and decompressed. With these ident mapping for this hard coded address should be correctly setted, still that GPF will happen. I borrowed a printf.c from arch/x86/boot and made it work for boot/compressed, can see in this case it will decompress successfully and jump into arch/x86/kernel/head_64.S, then it reboot there during a jump. > > 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/