From patchwork Thu Jan 17 12:49:04 2019 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Li Zhijian X-Patchwork-Id: 10768019 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 084B7746 for ; Thu, 17 Jan 2019 12:51:07 +0000 (UTC) Received: from mail.wl.linuxfoundation.org (localhost [127.0.0.1]) by mail.wl.linuxfoundation.org (Postfix) with ESMTP id ECA912F616 for ; Thu, 17 Jan 2019 12:51:06 +0000 (UTC) Received: by mail.wl.linuxfoundation.org (Postfix, from userid 486) id E0ACD2F673; Thu, 17 Jan 2019 12:51:06 +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 393B12F616 for ; Thu, 17 Jan 2019 12:51:06 +0000 (UTC) Received: from localhost ([127.0.0.1]:43516 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1gk78T-0006sM-Dz for patchwork-qemu-devel@patchwork.kernel.org; Thu, 17 Jan 2019 07:51:05 -0500 Received: from eggs.gnu.org ([209.51.188.92]:45792) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1gk779-0005lg-6e for qemu-devel@nongnu.org; Thu, 17 Jan 2019 07:49:49 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1gk778-000212-8Z for qemu-devel@nongnu.org; Thu, 17 Jan 2019 07:49:43 -0500 Received: from mga11.intel.com ([192.55.52.93]:36274) by eggs.gnu.org with esmtps (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.71) (envelope-from ) id 1gk778-0001sS-0P for qemu-devel@nongnu.org; Thu, 17 Jan 2019 07:49:42 -0500 X-Amp-Result: SKIPPED(no attachment in message) X-Amp-File-Uploaded: False Received: from fmsmga007.fm.intel.com ([10.253.24.52]) by fmsmga102.fm.intel.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 17 Jan 2019 04:49:29 -0800 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.56,488,1539673200"; d="scan'208";a="115392203" Received: from sunausti-mobl.ccr.corp.intel.com (HELO haswell-OptiPlex-9020.ccr.corp.intel.com) ([10.255.29.222]) by fmsmga007.fm.intel.com with ESMTP; 17 Jan 2019 04:49:27 -0800 From: Li Zhijian To: qemu-devel@nongnu.org, mst@redhat.com, peter.maydell@linaro.org Date: Thu, 17 Jan 2019 20:49:04 +0800 Message-Id: <1547729344-3895-5-git-send-email-lizhijian@cn.fujitsu.com> X-Mailer: git-send-email 2.7.4 In-Reply-To: <1547729344-3895-1-git-send-email-lizhijian@cn.fujitsu.com> References: <1547729344-3895-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 v6 4/4] i386: allow to load initrd below 4 GB 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 , philip.li@intel.com, 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. NOTE: it's possible that linux protocol within [0x208, 0x20c] supports up to 4 GB initrd as well. CC: Paolo Bonzini CC: Richard Henderson CC: Eduardo Habkost CC: "Michael S. Tsirkin" CC: Marcel Apfelbaum Signed-off-by: Li Zhijian Reviewed-by: Eduardo Habkost Reviewed-by: Stefano Garzarella --- V6: update comments 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 | 21 ++++++++++++++++++++- 1 file changed, 20 insertions(+), 1 deletion(-) diff --git a/hw/i386/pc.c b/hw/i386/pc.c index 64d23b2..10977a3 100644 --- a/hw/i386/pc.c +++ b/hw/i386/pc.c @@ -1130,7 +1130,26 @@ 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. + */ + initrd_max = UINT32_MAX; + } else if (protocol >= 0x203) { initrd_max = ldl_p(header+0x22c); } else { initrd_max = 0x37ffffff;