All of lore.kernel.org
 help / color / mirror / Atom feed
From: Daniel Kiper <dkiper@net-space.pl>
To: Zide Chen <zide.chen@intel.com>
Cc: grub-devel@gnu.org
Subject: Re: [PATCH V4] multiboot2: Implement quirk-modules-after-kernel
Date: Tue, 14 Apr 2020 22:09:28 +0200	[thread overview]
Message-ID: <20200414200928.mh3vqbkisqftxk2v@tomti.i.net-space.pl> (raw)
In-Reply-To: <20200407210859.215-1-zide.chen@intel.com>

Hi Zide,

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., the
> OS loaded by Multiboot2 needs to reserve low address for some particular
> purposes and not for loading modules.
>
> This patch implements the quirk quirk-modules-after-kernel to load modules
> to address after the kernel for Multiboot2 by reusing the implementation
> 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 this
> quirk is not enabled.
>
> Tested on KBL NUC loading ACRN Hypervisor.

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?

Last but not least, this change is not GRUB 2.06 release material.
However, I am happy to get it after the release.

If you have any questions just drop me a line.

Daniel


  reply	other threads:[~2020-04-14 20:09 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-04-07 21:08 [PATCH V4] multiboot2: Implement quirk-modules-after-kernel Zide Chen
2020-04-14 20:09 ` Daniel Kiper [this message]
2020-04-14 21:39   ` Chen, Zide
2020-04-16 13:28     ` Daniel Kiper
2020-04-16 17:42       ` Chen, Zide
2020-04-16 21:18         ` Chen, Zide

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20200414200928.mh3vqbkisqftxk2v@tomti.i.net-space.pl \
    --to=dkiper@net-space.pl \
    --cc=grub-devel@gnu.org \
    --cc=zide.chen@intel.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.