From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from list by lists.gnu.org with archive (Exim 4.90_1) id 1jP8X2-0008KS-6B for mharc-grub-devel@gnu.org; Thu, 16 Apr 2020 13:42:32 -0400 Received: from eggs.gnu.org ([2001:470:142:3::10]:39199) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1jP8Wv-0008HW-Vm for grub-devel@gnu.org; Thu, 16 Apr 2020 13:42:27 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1jP8Wr-0008Dj-Rv for grub-devel@gnu.org; Thu, 16 Apr 2020 13:42:24 -0400 Received: from mga02.intel.com ([134.134.136.20]:1121) by eggs.gnu.org with esmtps (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.71) (envelope-from ) id 1jP8Wr-00086j-Ji for grub-devel@gnu.org; Thu, 16 Apr 2020 13:42:21 -0400 IronPort-SDR: vI8DyVl0mnJAAc36gK1u0W+zM3oUQbkeZmt5ER3HBOfBfqNw5vhZgsgFWOMn9bW1sQjHqJKLoZ WeBhL7jZPWfA== X-Amp-Result: SKIPPED(no attachment in message) X-Amp-File-Uploaded: False Received: from fmsmga001.fm.intel.com ([10.253.24.23]) by orsmga101.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 16 Apr 2020 10:42:12 -0700 IronPort-SDR: 9GIa2+UkR60SmBNbzEuvw4zR2deyN1447djY7NkEUcOCKZk4pK2HL+91/TiCNNpdYZVgofSUZA OCZ8rYtuJkhw== X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.72,391,1580803200"; d="scan'208";a="364066704" Received: from orsmsx108.amr.corp.intel.com ([10.22.240.6]) by fmsmga001.fm.intel.com with ESMTP; 16 Apr 2020 10:42:11 -0700 Received: from orsmsx112.amr.corp.intel.com (10.22.240.13) by ORSMSX108.amr.corp.intel.com (10.22.240.6) with Microsoft SMTP Server (TLS) id 14.3.439.0; Thu, 16 Apr 2020 10:42:11 -0700 Received: from orsmsx102.amr.corp.intel.com ([169.254.3.107]) by ORSMSX112.amr.corp.intel.com ([169.254.3.76]) with mapi id 14.03.0439.000; Thu, 16 Apr 2020 10:42:11 -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+CAAxebgP//w14g Date: Thu, 16 Apr 2020 17:42:10 +0000 Message-ID: <636297D5EBADD745BF4BDD83AA58243931FE1CF8@ORSMSX102.amr.corp.intel.com> References: <20200407210859.215-1-zide.chen@intel.com> <20200414200928.mh3vqbkisqftxk2v@tomti.i.net-space.pl> <636297D5EBADD745BF4BDD83AA58243931FDCD74@ORSMSX102.amr.corp.intel.com> <20200416132833.icr4xqfjrrh36uhg@tomti.i.net-space.pl> In-Reply-To: <20200416132833.icr4xqfjrrh36uhg@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="iso-8859-1" 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: Thu, 16 Apr 2020 17:42:27 -0000 > -----Original Message----- > From: Daniel Kiper > Sent: Thursday, April 16, 2020 6:29 AM > To: Chen, Zide > Cc: grub-devel@gnu.org > Subject: Re: [PATCH V4] multiboot2: Implement quirk-modules-after-kernel >=20 > > Yes, a new tag would give it more flexibility for loading modules. But = my main > > concern is don't know how to push the new tag to Multiboot2 spec, and n= ot sure >=20 > The spec is in the multiboot2 branch in the GRUB repository. >=20 > > will it take very long time, for example, months? >=20 > It depends mostly on you and a bit on workload of folks here... I see, sorry for my na=EFve question: I need to send out a new patch dedic= ated for the new tag change and send to grub-devel@gnu.orgfor review, at the time it's accepted, you will merge it = to multiboot2 branch? Is it correct? > > w.r.t. to the tag, how about the following draft which was almost borro= wed from > > the relocatable header tag? It seems this better covers the case for lo= ading multiple > > modules. > > > > Modules relocatable tag > > > > +------------------+ > > u16 | type =3D 22 | > > u16 | flags | > > u32 | size =3D 20 | > > u32 | min_addr | >=20 > s/u32/u64/ Currently modules are loaded at 32bit address only. But yes, I agree that '= u64' would make it more flexible. > > u32 | max_addr | >=20 > s/u32/u64/ >=20 > > u32 | preference | >=20 > Please put preference immediately behind the size. Sure, will do. >=20 > > +------------------+ > > > > This tag is independent to the relocatable header tag. All of the > > address fields 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. >=20 > OK. >=20 > > max_addr > > Highest possible physical address at which loaded any modules should > > end. The bootloader cannot load any part of any modules above this > > address. >=20 > OK. >=20 > > preference > > It contains load address placement suggestion for modules. Boot loader > > should follow it. '0' means none, '1' means load image at lowest > > possible address but not lower than min_addr and '2' means load image > > at highest possible address but not higher than max_addr. >=20 > I am OK with that. However, I would add something saying that the > min_addr and max_addr usage do not depend so strongly on preference > setting. I mean if preference is 0 then the bootloader still looks > at the min_addr and max_addr. >=20 Sure, will do.=20 > Hmmm... How would you want to use that tag to force the bootloader to > load the modules above/below the kernel? >=20 > Daniel Either in my case, or the motivation to quirk-modules-after-kernel in Multi= boot, the problem was that it's preferred that the modules not be loaded at lower add= ress, and whether it's above/below the kernel is not important. However, if the user does want to the modules to be above/below kernel, it = still has options: Case 1: kernel relocatable tag is not present.=20 Kernel will be loaded at known address, either through address tag, or ELF.= =20 Then user can manipulate this modules relocatable tag to put modules above = or below kernel. Case 2: kernel relocatable tag is present. Yes, depending on the memory fragmentation situation, the kernel can't guar= anteed to=20 get address that is lower or higher addresses for modules. But the user may= put different min/max_addr in this tag and the kernel relocatable tag. In this case, the = only issue is the gap between kernel load address and modules load addresses could be rel= ative large. -Zide