Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1760403AbbBIUXS (ORCPT ); Mon, 9 Feb 2015 15:23:18 -0500 Received: from mail-ig0-f172.google.com ([209.85.213.172]:62451 "EHLO mail-ig0-f172.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1750916AbbBIUXQ (ORCPT ); Mon, 9 Feb 2015 15:23:16 -0500 MIME-Version: 1.0 In-Reply-To: <20150209182742.GQ6461@codeblueprint.co.uk> References: <1423015400-12629-1-git-send-email-yinghai@kernel.org> <20150209182742.GQ6461@codeblueprint.co.uk> Date: Mon, 9 Feb 2015 12:23:15 -0800 X-Google-Sender-Auth: B0IZJz7JzcecyV4yvjfgEa6Ge3s Message-ID: Subject: Re: [PATCH] x86, boot: Allow 64bit EFI kernel to be loaded above 4G From: Yinghai Lu To: Matt Fleming Cc: Thomas Gleixner , "H. Peter Anvin" , Ingo Molnar , Jonathan Corbet , Matt Fleming , Kees Cook , Junjie Mao , "linux-doc@vger.kernel.org" , "linux-efi@vger.kernel.org" , Linux Kernel Mailing List Content-Type: text/plain; charset=UTF-8 Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 2200 Lines: 64 On Mon, Feb 9, 2015 at 10:27 AM, Matt Fleming wrote: > On Tue, 03 Feb, at 06:03:20PM, Yinghai Lu wrote: > > The first thing that comes to mind is the issues we experienced last > year when adding support for loading initrds above 4GB to the EFI boot > stub, c.f. commit 47226ad4f4cf ("x86/efi: Only load initrd above 4g on > second try"). > > Are things going to work correctly this time? That should be addressed the grub2. I was thinking that we may need to add mem_limit command together with linuxefi and initrdefi. or add linuxefi64/initrdefi64? BTW, I tested loading kernel above grub2 on virutalbox, qemu/kvm/OVMF, and real servers (ami ...) all work without problem. wonder if we need have one black list for 64bit UEFI that does not support access memory above 4G. >> @@ -1430,9 +1431,12 @@ struct boot_params *efi_main(struct efi_ >> * If the kernel isn't already loaded at the preferred load >> * address, relocate it. >> */ >> - if (hdr->pref_address != hdr->code32_start) { >> - unsigned long bzimage_addr = hdr->code32_start; >> - status = efi_relocate_kernel(sys_table, &bzimage_addr, >> + loaded_addr = hdr->code32_start; >> + loaded_addr |= (unsigned long)hdr->ext_code32_start << 32; > > Please compile this for CONFIG_X86_32 and fix any compiler warnings. Ok. > >> @@ -738,6 +742,13 @@ Offset/size: 0x264/4 >> >> See EFI HANDOVER PROTOCOL below for more details. >> >> +Field name: ext_code32_start >> +Type: modify (optional, reloc) >> +Offset/size: 0x268/4 >> +Protocol: 2.14+ >> + >> + The address is used with code32_start to compare pref_address >> + to support EFI 64bit kernel get loaded above 4G. > > It would be good to mention that this new field contains the upper > 32-bits of the 64-bit address. ok. that is: upper 32bits of the 64bit address of startup_32 when kernel loaded above 4G. 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/