From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from list by lists.gnu.org with archive (Exim 4.90_1) id 1jOTHJ-0006Yw-C1 for mharc-grub-devel@gnu.org; Tue, 14 Apr 2020 17:39:33 -0400 Received: from eggs.gnu.org ([2001:470:142:3::10]:34485) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1jOTHG-0006Yh-P8 for grub-devel@gnu.org; Tue, 14 Apr 2020 17:39:31 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1jOTHE-0007tO-NJ for grub-devel@gnu.org; Tue, 14 Apr 2020 17:39:29 -0400 Received: from mga02.intel.com ([134.134.136.20]:49895) by eggs.gnu.org with esmtps (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.71) (envelope-from ) id 1jOTHE-0007sP-EF for grub-devel@gnu.org; Tue, 14 Apr 2020 17:39:28 -0400 IronPort-SDR: V+01nMY4RG9LdtHj08gW8ASvxnhrTHABeiT3NEG5quKE4UgtBFKzPBv8Wu8EYVFEzTJ/qkBGGf 9yGSVLkj5pfg== X-Amp-Result: SKIPPED(no attachment in message) X-Amp-File-Uploaded: False Received: from fmsmga006.fm.intel.com ([10.253.24.20]) by orsmga101.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 14 Apr 2020 14:39:18 -0700 IronPort-SDR: o7xhTBY+k5G7GbQxsdiL5lkP29rqrSZLeCpMpom1KPjIZp2xbVZPm3KKWWY63ozprN15BkZ1xP jfEmHkHIadxw== X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.72,384,1580803200"; d="scan'208";a="454700264" Received: from orsmsx105.amr.corp.intel.com ([10.22.225.132]) by fmsmga006.fm.intel.com with ESMTP; 14 Apr 2020 14:39:18 -0700 Received: from orsmsx161.amr.corp.intel.com (10.22.240.84) by ORSMSX105.amr.corp.intel.com (10.22.225.132) with Microsoft SMTP Server (TLS) id 14.3.439.0; Tue, 14 Apr 2020 14:39:18 -0700 Received: from orsmsx102.amr.corp.intel.com ([169.254.3.107]) by ORSMSX161.amr.corp.intel.com ([169.254.4.226]) with mapi id 14.03.0439.000; Tue, 14 Apr 2020 14:39:18 -0700 From: "Chen, Zide" To: Daniel Kiper CC: "grub-devel@gnu.org" Subject: RE: [PATCH V4] multiboot2: Implement quirk-modules-after-kernel Thread-Topic: [PATCH V4] multiboot2: Implement quirk-modules-after-kernel Thread-Index: AQHWDSDJ853BRFpcc06Ak4xciv/VK6h5jEoA//+dC+A= Date: Tue, 14 Apr 2020 21:39:17 +0000 Message-ID: <636297D5EBADD745BF4BDD83AA58243931FDCD74@ORSMSX102.amr.corp.intel.com> References: <20200407210859.215-1-zide.chen@intel.com> <20200414200928.mh3vqbkisqftxk2v@tomti.i.net-space.pl> In-Reply-To: <20200414200928.mh3vqbkisqftxk2v@tomti.i.net-space.pl> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: dlp-product: dlpe-windows dlp-version: 11.2.0.6 dlp-reaction: no-action x-originating-ip: [10.22.254.140] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-detected-operating-system: by eggs.gnu.org: FreeBSD 9.x [fuzzy] X-Received-From: 134.134.136.20 X-BeenThere: grub-devel@gnu.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: The development of GNU GRUB List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 Apr 2020 21:39:31 -0000 Hi Daniel, > Subject: Re: [PATCH V4] multiboot2: Implement quirk-modules-after-kernel > On Tue, Apr 07, 2020 at 02:08:59PM -0700, Zide Chen wrote: > > In contrast to Mulitboot, in Mulitboot2, there is currently no way to > > control where to load the modules to. This could be a problem, e.g., th= e > > OS loaded by Multiboot2 needs to reserve low address for some particula= r > > purposes and not for loading modules. > > > > This patch implements the quirk quirk-modules-after-kernel to load modu= les > > to address after the kernel for Multiboot2 by reusing the implementatio= n > > for Multiboot: > > > > - remove "ifndef GRUB_USE_MULTIBOOT2" that is handling this quirk. > > - define separate variables for both Multiboot and Multiboot2, e.g., > > grub_multiboot_quirks, highest_load, etc. > > - in grub_multiboot2_load(): calculate the highest load address of raw > > image and assign it to grub_multiboot2_highest_load. > > - the existing code in multiboot_elfxx.c is able to calculate the > > highest_load for Mutiboot2 already. > > > > Currently, lowest address for Multiboot2 modules allocation was 0x0. > > With this patch, the lowest module load address is set to 1MB even if t= his > > quirk is not enabled. > > > > Tested on KBL NUC loading ACRN Hypervisor. >=20 > OK, I understand the need but I do not like the solution. I would prefer > if you extend Multiboot2 protocol specification [1] with an additional > tag. I think that it should allow a user to specify above/below the > kernel (just a 32-bit bitfield) and specific address in the memory > (64-bit). Specific address should have a preference. So, the new tag > should have at least two members. If you decide to go that way I would > like to see updates to the Multiboot2 specification first. If we are OK > with the proposed changes then you can go and write the code for GRUB. > Is it OK for you? Thank you very much for the comments! Yes, a new tag would give it more flexibility for loading modules. But my m= ain concern is don't know how to push the new tag to Multiboot2 spec, and not s= ure will it take very long time, for example, months? w.r.t. to the tag, how about the following draft which was almost borrowed = from the relocatable header tag? It seems this better covers the case for loadin= g multiple modules. Modules relocatable tag +------------------+ u16 | type =3D 22 | u16 | flags | u32 | size =3D 20 | u32 | min_addr | u32 | max_addr | u32 | preference | +------------------+ This tag is independent to the relocatable header tag. All of the address f= ields in this tag are physical addresses. min_addr Lowest possible physical address at which any modules should be loaded. The= bootloader cannot load any part of any modules below this address. max_addr Highest possible physical address at which loaded any modules should end. T= he bootloader cannot load any part of any modules above this address. preference It contains load address placement suggestion for modules. Boot loader shou= ld follow it. '0' means none, '1' means load image at lowest possible addre= ss but not lower than min_addr and '2' means load image at highest possible= address but not higher than max_addr. =20 > Last but not least, this change is not GRUB 2.06 release material. > However, I am happy to get it after the release. >=20 > If you have any questions just drop me a line. >=20 > Daniel Best Regards, Zide