From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:45732) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1gL15z-0008Cr-Cv for qemu-devel@nongnu.org; Fri, 09 Nov 2018 02:20:48 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1gL15v-0005NB-4F for qemu-devel@nongnu.org; Fri, 09 Nov 2018 02:20:47 -0500 Received: from mail-wm1-x343.google.com ([2a00:1450:4864:20::343]:40217) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1gL15m-0004wd-G4 for qemu-devel@nongnu.org; Fri, 09 Nov 2018 02:20:38 -0500 Received: by mail-wm1-x343.google.com with SMTP id b203-v6so969598wme.5 for ; Thu, 08 Nov 2018 23:20:20 -0800 (PST) Sender: Ingo Molnar Date: Fri, 9 Nov 2018 08:20:15 +0100 From: Ingo Molnar Message-ID: <20181109072015.GA86700@gmail.com> References: <1541674784-25936-1-git-send-email-lizhijian@cn.fujitsu.com> <1541674784-25936-2-git-send-email-lizhijian@cn.fujitsu.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: Subject: Re: [Qemu-devel] [RFC/PoC PATCH 1/3] i386: set initrd_max to 4G - 1 to allow up to 4G initrd List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: 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 , zhijianx.li@intel.com, linux-kernel@vger.kernel.org, Linus Torvalds , Peter Zijlstra , Kees Cook * 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. 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. Or something along those lines. Thanks, Ingo