From nobody Tue Feb 10 10:20:05 2026 Delivered-To: importer@patchew.org Received-SPF: pass (zoho.com: domain of gnu.org designates 209.51.188.17 as permitted sender) client-ip=209.51.188.17; envelope-from=qemu-devel-bounces+importer=patchew.org@nongnu.org; helo=lists.gnu.org; Authentication-Results: mx.zohomail.com; spf=pass (zoho.com: domain of gnu.org designates 209.51.188.17 as permitted sender) smtp.mailfrom=qemu-devel-bounces+importer=patchew.org@nongnu.org Return-Path: Received: from lists.gnu.org (lists.gnu.org [209.51.188.17]) by mx.zohomail.com with SMTPS id 1547197385850615.8527201405684; Fri, 11 Jan 2019 01:03:05 -0800 (PST) Received: from localhost ([127.0.0.1]:35891 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ghsiW-0005Nq-Dj for importer@patchew.org; Fri, 11 Jan 2019 04:03:04 -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 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 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 X-Amp-Result: SKIPPED(no attachment in message) X-Amp-File-Uploaded: False X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.56,465,1539673200"; d="scan'208";a="134962104" 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+importer=patchew.org@nongnu.org Sender: "Qemu-devel" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Since linux commit: cf8fa920cb42 ("i386: handle an initrd in highmem (versi= on 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 =20 /* highest address for loading the initrd */ - if (protocol >=3D 0x203) { + if (protocol >=3D 0x20c && + lduw_p(header+0x236) & XLF_CAN_BE_LOADED_ABOVE_4G) { + /* + * Linux has supported initrd up to 4 GB for a very long time (200= 7, + * 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 bootload= er + * bugs". Luckily, QEMU firmware(which does something like bootloa= der) + * 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 we= ll. + * + * FIXME: it's possible that linux protocol within [0x208, 0x20c] + * supports up to 4G initrd as well. + */ + initrd_max =3D UINT32_MAX; + } else if (protocol >=3D 0x203) { initrd_max =3D ldl_p(header+0x22c); } else { initrd_max =3D 0x37ffffff; --=20 2.7.4