From patchwork Fri Jan 11 08:57:51 2019 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Li Zhijian X-Patchwork-Id: 10757539 Return-Path: Received: from mail.wl.linuxfoundation.org (pdx-wl-mail.web.codeaurora.org [172.30.200.125]) by pdx-korg-patchwork-2.web.codeaurora.org (Postfix) with ESMTP id 2197C13B4 for ; Fri, 11 Jan 2019 09:02:37 +0000 (UTC) Received: from mail.wl.linuxfoundation.org (localhost [127.0.0.1]) by mail.wl.linuxfoundation.org (Postfix) with ESMTP id 1290028DEC for ; Fri, 11 Jan 2019 09:02:37 +0000 (UTC) Received: by mail.wl.linuxfoundation.org (Postfix, from userid 486) id 071A0297A8; Fri, 11 Jan 2019 09:02:37 +0000 (UTC) X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on pdx-wl-mail.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-2.9 required=2.0 tests=BAYES_00,MAILING_LIST_MULTI autolearn=ham version=3.3.1 Received: from lists.gnu.org (lists.gnu.org [209.51.188.17]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) by mail.wl.linuxfoundation.org (Postfix) with ESMTPS id 7376B28DEC for ; Fri, 11 Jan 2019 09:02:36 +0000 (UTC) Received: from localhost ([127.0.0.1]:35891 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ghsi3-0005Nq-KU for patchwork-qemu-devel@patchwork.kernel.org; Fri, 11 Jan 2019 04:02:35 -0500 Received: from eggs.gnu.org ([209.51.188.92]:55728) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ghsgZ-0004BR-BJ for qemu-devel@nongnu.org; Fri, 11 Jan 2019 04:01:04 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1ghseI-0000vv-MH for qemu-devel@nongnu.org; Fri, 11 Jan 2019 03:58:43 -0500 Received: from mga11.intel.com ([192.55.52.93]:51737) by eggs.gnu.org with esmtps (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.71) (envelope-from ) id 1ghseI-0000jA-BP for qemu-devel@nongnu.org; Fri, 11 Jan 2019 03:58:42 -0500 X-Amp-Result: SKIPPED(no attachment in message) X-Amp-File-Uploaded: False Received: from fmsmga004.fm.intel.com ([10.253.24.48]) by fmsmga102.fm.intel.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 11 Jan 2019 00:58:25 -0800 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.56,465,1539673200"; d="scan'208";a="134962104" Received: from sunausti-mobl.ccr.corp.intel.com (HELO haswell-OptiPlex-9020.ccr.corp.intel.com) ([10.255.29.222]) by fmsmga004.fm.intel.com with ESMTP; 11 Jan 2019 00:58:23 -0800 From: Li Zhijian To: qemu-devel@nongnu.org, mst@redhat.com, peter.maydell@linaro.org Date: Fri, 11 Jan 2019 16:57:51 +0800 Message-Id: <1547197071-14504-5-git-send-email-lizhijian@cn.fujitsu.com> X-Mailer: git-send-email 2.7.4 In-Reply-To: <1547197071-14504-1-git-send-email-lizhijian@cn.fujitsu.com> References: <1547197071-14504-1-git-send-email-lizhijian@cn.fujitsu.com> X-detected-operating-system: by eggs.gnu.org: Genre and OS details not recognized. X-Received-From: 192.55.52.93 Subject: [Qemu-devel] [PATCH v5 4/4] i386: allow to load initrd below 4G for recent linux X-BeenThere: qemu-devel@nongnu.org X-Mailman-Version: 2.1.21 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Cc: Eduardo Habkost , Li Zhijian , zhijianx.li@intel.com, Paolo Bonzini , philmd@redhat.com, Richard Henderson Errors-To: qemu-devel-bounces+patchwork-qemu-devel=patchwork.kernel.org@nongnu.org Sender: "Qemu-devel" X-Virus-Scanned: ClamAV using ClamSMTP Since linux commit: cf8fa920cb42 ("i386: handle an initrd in highmem (version 2)") linux has supported initrd up to 4 GB, but the header field ramdisk_max is still set to 2 GB to avoid "possible bootloader bugs". When use '-kernel vmlinux -initrd initrd.cgz' to launch a VM, the firmware(it could be linuxboot_dma.bin) helps to read initrd contents into guest memory(below ramdisk_max) and jump to kernel. that's similar with what bootloader does, like grub. In addition, initrd_max is uint32_t simply because QEMU doesn't support the 64-bit boot protocol (specifically the ext_ramdisk_image field). Therefore here just limit initrd_max to UINT32_MAX simply as well to allow initrd to be loaded below 4 GB. CC: Paolo Bonzini CC: Richard Henderson CC: Eduardo Habkost CC: "Michael S. Tsirkin" CC: Marcel Apfelbaum Signed-off-by: Li Zhijian --- V5: udpate comments and changelog V3: correct grammar and check XLF_CAN_BE_LOADED_ABOVE_4G first (Michael S. Tsirkin) Signed-off-by: Li Zhijian --- hw/i386/pc.c | 24 +++++++++++++++++++++++- 1 file changed, 23 insertions(+), 1 deletion(-) diff --git a/hw/i386/pc.c b/hw/i386/pc.c index 89c25b2..ea7a3c7 100644 --- a/hw/i386/pc.c +++ b/hw/i386/pc.c @@ -904,7 +904,29 @@ static void load_linux(PCMachineState *pcms, #endif /* highest address for loading the initrd */ - if (protocol >= 0x203) { + if (protocol >= 0x20c && + lduw_p(header+0x236) & XLF_CAN_BE_LOADED_ABOVE_4G) { + /* + * Linux has supported initrd up to 4 GB for a very long time (2007, + * long before XLF_CAN_BE_LOADED_ABOVE_4G which was added in 2013), + * though it only sets initrd_max to 2 GB to "work around bootloader + * bugs". Luckily, QEMU firmware(which does something like bootloader) + * has supported this. + * + * It's believed that if XLF_CAN_BE_LOADED_ABOVE_4G is set, initrd can + * be loaded into any address. + * + * In addition, initrd_max is uint32_t simply because QEMU doesn't + * support the 64-bit boot protocol (specifically the ext_ramdisk_image + * field). + * + * Therefore here just limit initrd_max to UINT32_MAX simply as well. + * + * FIXME: it's possible that linux protocol within [0x208, 0x20c] + * supports up to 4G initrd as well. + */ + initrd_max = UINT32_MAX; + } else if (protocol >= 0x203) { initrd_max = ldl_p(header+0x22c); } else { initrd_max = 0x37ffffff;