From patchwork Wed Nov 21 02:06:01 2018 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Li Zhijian X-Patchwork-Id: 10691531 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 6A25113BF for ; Wed, 21 Nov 2018 02:07:19 +0000 (UTC) Received: from mail.wl.linuxfoundation.org (localhost [127.0.0.1]) by mail.wl.linuxfoundation.org (Postfix) with ESMTP id 553EA2B109 for ; Wed, 21 Nov 2018 02:07:19 +0000 (UTC) Received: by mail.wl.linuxfoundation.org (Postfix, from userid 486) id 49E9F2B112; Wed, 21 Nov 2018 02:07:19 +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=-7.9 required=2.0 tests=BAYES_00,MAILING_LIST_MULTI, RCVD_IN_DNSWL_HI autolearn=ham version=3.3.1 Received: from lists.gnu.org (lists.gnu.org [208.118.235.17]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) by mail.wl.linuxfoundation.org (Postfix) with ESMTPS id E2BA52B157 for ; Wed, 21 Nov 2018 02:07:18 +0000 (UTC) Received: from localhost ([::1]:36839 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1gPHvC-0006pz-5o for patchwork-qemu-devel@patchwork.kernel.org; Tue, 20 Nov 2018 21:07:18 -0500 Received: from eggs.gnu.org ([2001:4830:134:3::10]:49854) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1gPHtp-0005ll-Ad for qemu-devel@nongnu.org; Tue, 20 Nov 2018 21:05:54 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1gPHtk-0002kv-8Y for qemu-devel@nongnu.org; Tue, 20 Nov 2018 21:05:51 -0500 Received: from mga05.intel.com ([192.55.52.43]:12715) by eggs.gnu.org with esmtps (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.71) (envelope-from ) id 1gPHtk-0002gn-0u for qemu-devel@nongnu.org; Tue, 20 Nov 2018 21:05: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 fmsmga105.fm.intel.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 20 Nov 2018 18:05:43 -0800 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.56,259,1539673200"; d="scan'208";a="90916977" Received: from bangyuan-mobl.ccr.corp.intel.com (HELO haswell-OptiPlex-9020.ccr.corp.intel.com) ([10.255.31.159]) by orsmga007.jf.intel.com with ESMTP; 20 Nov 2018 18:05:41 -0800 From: Li Zhijian To: qemu-devel@nongnu.org Date: Wed, 21 Nov 2018 10:06:01 +0800 Message-Id: <1542765966-20244-1-git-send-email-lizhijian@cn.fujitsu.com> X-Mailer: git-send-email 2.7.4 X-detected-operating-system: by eggs.gnu.org: Genre and OS details not recognized. X-Received-From: 192.55.52.43 Subject: [Qemu-devel] [PATCH v2 0/5] support loading initrd below 4G for recent kernel 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: Philip Li , Li Zhijian , Li Zhijian Errors-To: qemu-devel-bounces+patchwork-qemu-devel=patchwork.kernel.org@nongnu.org Sender: "Qemu-devel" X-Virus-Scanned: ClamAV using ClamSMTP Long long ago, linux kernel have supported up to 4G initrd, but it's header still hard code to allow loading initrd below 2G only. cutting from arch/x86/head.S: # (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. In order to supporting more than 2G initrd, qemu must allow loading initrd above 2G address. Luckly, recent kernel introduced a new field to linux header named xloadflags:XLF_CAN_BE_LOADED_ABOVE_4G which tells bootload an optional and safe address to load initrd. Current QEMU always load initrd below below_4g_mem_size which always less than 4G, so here limit initrd_max to 4G - 1 simply is enough if this bit is set. Default roms(Seabios + optionrom(linuxboot_dma)) works as expected with those patch set. Patch 1/5 make a huge changes to address/memory APIs, but if it's not a good idea, below is an specfic patch to avoid dma overflow changes: V2: add 2 patches(3/5, 4/5) to fix potential loading issue. Li Zhijian (5): unify len and addr type for memory/address APIs change load_image() reture type to ssize_t refactor load_image/load_image_size x86: exit qemu if load_image fails x86: allow load initrd below 4G for recent linux exec.c | 49 ++++++++++++++++++++++++----------------------- hw/core/loader.c | 27 +++++++++++++++----------- hw/i386/pc.c | 17 +++++++++++++++- include/exec/cpu-all.h | 2 +- include/exec/cpu-common.h | 10 +++++----- include/exec/memory.h | 20 +++++++++---------- include/hw/loader.h | 2 +- 7 files changed, 74 insertions(+), 53 deletions(-) diff --git a/hw/nvram/fw_cfg.c b/hw/nvram/fw_cfg.c index 946f765..5c9607c 100644 --- a/hw/nvram/fw_cfg.c +++ b/hw/nvram/fw_cfg.c @@ -338,7 +338,7 @@ static void fw_cfg_dma_transfer(FWCfgState *s) while (dma.length > 0 && !(dma.control & FW_CFG_DMA_CTL_ERROR)) { if (s->cur_entry == FW_CFG_INVALID || !e->data || s->cur_offset >= e->len) { - len = dma.length; + len = dma.length > INT32_MAX ? INT32_MAX : dma.length; /* If the access is not a read access, it will be a skip access, * tested before. @@ -358,6 +358,8 @@ static void fw_cfg_dma_transfer(FWCfgState *s) len = (e->len - s->cur_offset); } + len = len > INT32_MAX ? INT32_MAX : len; + /* If the access is not a read access, it will be a skip access, * tested before. */