Received: by 2002:ad5:474a:0:0:0:0:0 with SMTP id i10csp546126imu; Fri, 9 Nov 2018 01:58:36 -0800 (PST) X-Google-Smtp-Source: AJdET5duFemGdIfvwfPlDKyMWZ5Cl4lijDh6OOtuxEoMo4VQThTamGCoMrhRQrGvC22LFebbouAo X-Received: by 2002:a17:902:4165:: with SMTP id e92-v6mr8368848pld.209.1541757516615; Fri, 09 Nov 2018 01:58:36 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1541757516; cv=none; d=google.com; s=arc-20160816; b=WqxuEbI0T5IY39HwvWd+SK4iZ39Mqirlx3Asjy7K9F6SKSOaH0CSnq6QMNAYPUKbwx UXUdcUrUTtv65Thu+lHb29SfcEp3prGRbiPXnMtPe8U1Up/H/QCv1rFkD2SfURSLGkyj 0cEkMvTkj6SQaLIz1hRO/f6zhabGlnElYdr/lyM20rmK5bEM/Um57sMgQnYm8+QMoUks mP92rl+PRAubQ8DviJl7d09Tmuzd4yU9ihaqiJKWBJIRiH+wLyVqs0Vv2y7xSvK7TwFI bQHlhz3iPe6ynC6R2gJyWDSDHtd8tDVgWXD6iaau0taHWUTtCq4SkIr8hfoRmvw+c8CE Dhag== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:content-language :content-transfer-encoding:in-reply-to:mime-version:user-agent:date :message-id:from:references:cc:to:subject; bh=r6JI8giTUZBLZRTXpP+3Cvf/4ZM4mTxnHTnW4bt17+E=; b=B3z4T8dTJ77XFyTJ6AgfK0DsgfDmA+o8qZYlK62QBivKAzVIBX219K80gmVohfn+BK YUYcOeO9FNt8k5+dRd0nLyYo+WWqo+Dj2T9FBArziPTgk7YCA2gYo5r0nrpHUbXKLpMG NrhFL3dTRxhnCN2FcPSPoK78+vpIiyPmoXjH6S4z5Gr78fBGdGMZzUk7nMYG7oKRSbTD SkHmt1P/1j+2Mio8GK348DO4RVl64rgsxPN5Rh8MNz5iYIcY8iBRlCB6uyudvP0u1C52 r0G2ie1fX+G8W9USo0Tq4NWE+essnlRZxoBocLOwUuVjKIP3MdVSFcRB35NNcZKtoaTl SBMQ== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=intel.com Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id bh6-v6si7249838plb.66.2018.11.09.01.58.21; Fri, 09 Nov 2018 01:58:36 -0800 (PST) Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=intel.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1727840AbeKITht (ORCPT + 99 others); Fri, 9 Nov 2018 14:37:49 -0500 Received: from mga07.intel.com ([134.134.136.100]:3966 "EHLO mga07.intel.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1727532AbeKIThs (ORCPT ); Fri, 9 Nov 2018 14:37:48 -0500 X-Amp-Result: SKIPPED(no attachment in message) X-Amp-File-Uploaded: False Received: from orsmga007.jf.intel.com ([10.7.209.58]) by orsmga105.jf.intel.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 09 Nov 2018 01:57:58 -0800 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.54,483,1534834800"; d="scan'208";a="87979925" Received: from mke-mobl.ccr.corp.intel.com (HELO [192.168.4.139]) ([10.255.30.228]) by orsmga007.jf.intel.com with ESMTP; 09 Nov 2018 01:57:53 -0800 Subject: Re: [Qemu-devel] [RFC/PoC PATCH 1/3] i386: set initrd_max to 4G - 1 to allow up to 4G initrd To: Ingo Molnar , Li Zhijian , Juergen Gross Cc: Peter Maydell , x86@kernel.org, hpa@zytor.com, bp@alien8.de, mingo@redhat.com, tglx@linutronix.de, QEMU Developers , Philip Li , linux-kernel@vger.kernel.org, Linus Torvalds , Peter Zijlstra , Kees Cook References: <1541674784-25936-1-git-send-email-lizhijian@cn.fujitsu.com> <1541674784-25936-2-git-send-email-lizhijian@cn.fujitsu.com> <20181109072015.GA86700@gmail.com> From: Li Zhijian Message-ID: <38905d35-29af-b522-1629-b13e98a47a42@intel.com> Date: Fri, 9 Nov 2018 17:57:50 +0800 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:60.0) Gecko/20100101 Thunderbird/60.0 MIME-Version: 1.0 In-Reply-To: <20181109072015.GA86700@gmail.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Content-Language: en-US Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 11/9/2018 3:20 PM, Ingo Molnar wrote: > * Li Zhijian wrote: > >>> If the kernel initrd creation process creates an initrd which >>> is larger than 2GB and also claims that it can't be placed >>> with any part of it above 2GB, then that sounds like a bug >>> in the initrd creation process... >> Exactly, it's a real problem. >> >> Add x86 maintainers and LKML: >> >> The background is that QEMU want to support up to 4G initrd. but linux header ( >> initrd_addr_max field) only allow 2G-1. >> Is one of the below approaches reasonable: >> 1) change initrd_addr_max to 4G-1 directly simply(arch/x86/boot/header.S)? >> 2) lie QEMU bootloader the initrd_addr_max is 4G-1 even though header said 2G-1 >> 3) any else > A 10 years old comment from hpa says: > > initrd_addr_max: .long 0x7fffffff > # (Header version 0x0203 or later) > # The highest safe address for > # the contents of an initrd > # The current kernel allows up to 4 GB, > # but leave it at 2 GB to avoid > # possible bootloader bugs. > > To avoid the potential of bugs lurking in dozens of major and hundreds of > minor iterations of various Linux bootloaders I'd prefer a real solution > and extend it - because if there's a 2GB initrd for some weird reason > today there might be a 4GB one in two years. thank a lots. that's amazing. > > The real solution would be to: > > - Extend the boot protocol with a 64-bit field, named initrd_addr64_max > or such. > - We don't change the old field - but if the new field is set by new > kernels then new bootloaders can use that as a new initrd_addr64_max > value. (or reject to load the kernel if the address is too high.) > > - The kernel build should also emit a warning when building larger than > 2GB initrds, with a list of bootloaders that support the new protocol. Actually i just knew QEMU(Seabios + optionrom(linuxboot_dma.bin)) can support ~4GB initrd so far. i just drafted at patch to add this field. could you have a look. another patch which is to document initrd_addr64_max is ongoing. commit db463ac9c1975f115d1ce2acb82d530c2b63b888 Author: Li Zhijian Date: Fri Nov 9 17:24:14 2018 +0800 x86: Add header field initrd_addr64_max Years ago, kernel had support load ~4GB initrd. But for some weird reasons ( avoid possible bootloader bugs), it only allow leave initrd under 2GB address space(see initrd_addr_max fild at arch/x86/boot/header.S). So modern bootloaders have not chance to load >=2G initrd previously. To avoid the potential of bugs lurking in dozens of major and hundreds of minor iterations of various Linux bootloaders. Ingo suggests to add a new field initrd_addr64_max. If bootloader believes that it can load initrd to >=2G address space, it can use initrd_addr64_max as the maximum loading address in stead of the old field initrd_addr_max. diff --git a/arch/x86/boot/header.S b/arch/x86/boot/header.S index 4c881c8..5fc3ebe 100644 --- a/arch/x86/boot/header.S +++ b/arch/x86/boot/header.S @@ -300,7 +300,7 @@ _start: # Part 2 of the header, from the old setup.S .ascii "HdrS" # header signature - .word 0x020e # header version number (>= 0x0105) + .word 0x020f # header version number (>= 0x0105) # or else old loadlin-1.5 will fail) .globl realmode_swtch realmode_swtch: .word 0, 0 # default_switch, SETUPSEG @@ -562,6 +562,12 @@ acpi_rsdp_addr: .quad 0 # 64-bit physical pointer to the # ACPI RSDP table, added with # version 2.14 +#ifdef CONFIG_INITRD_SIZE_4GB +initrd_addr64_max: .quad 0xffffffff # allow ~4G initrd since 2.15 +#else +initrd_addr64_max: .quad 0 +#endif + # End of setup header ##################################################### .section ".entrytext", "ax" diff --git a/arch/x86/include/uapi/asm/bootparam.h b/arch/x86/include/uapi/asm/bootparam.h index 22f89d0..b86013d 100644 --- a/arch/x86/include/uapi/asm/bootparam.h +++ b/arch/x86/include/uapi/asm/bootparam.h @@ -90,6 +90,7 @@ struct setup_header { __u32 init_size; __u32 handover_offset; __u64 acpi_rsdp_addr; + __u64 initrd_addr64_max; } __attribute__((packed)); struct sys_desc_table { diff --git a/init/Kconfig b/init/Kconfig index a4112e9..611d4af 100644 --- a/init/Kconfig +++ b/init/Kconfig @@ -1080,6 +1080,14 @@ config BLK_DEV_INITRD If unsure say Y. +config INITRD_SIZE_4GB + bool "4G size initrd support" + depends on (X86 || X86_64) + help + This option enables support ~4GB initrd. + + if unsure say N. + if BLK_DEV_INITRD source "usr/Kconfig" Thanks Zhijian > Or something along those lines. > > Thanks, > > Ingo