RE: [PATCH V4] multiboot2: Implement quirk-modules-after-kernel

["Chen, Zide" <zide.chen@intel.com>]

> -----Original Message-----
> From: Daniel Kiper <dkiper@net-space.pl>
> Sent: Thursday, April 16, 2020 6:29 AM
> To: Chen, Zide <zide.chen@intel.com>
> Cc: grub-devel@gnu.org
> Subject: Re: [PATCH V4] multiboot2: Implement quirk-modules-after-kernel
> 
> > 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 not sure
> 
> The spec is in the multiboot2 branch in the GRUB repository.
> 
> > will it take very long time, for example, months?
> 
> It depends mostly on you and a bit on workload of folks here...

I see, sorry for my naïve question:  I need to send out a new patch dedicated 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 borrowed from
> > the relocatable header tag? It seems this better covers the case for loading multiple
> > modules.
> >
> > Modules relocatable tag
> >
> >             +------------------+
> > u16     | type = 22       |
> > u16     | flags               |
> > u32     | size = 20        |
> > u32     | min_addr      |
> 
> 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     |
> 
> s/u32/u64/
> 
> > u32     | preference   |
> 
> Please put preference immediately behind the size.

Sure, will do.

> 
> >             +------------------+
> >
> > 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.
> 
> OK.
> 
> > 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.
> 
> OK.
> 
> > 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.
> 
> 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.
> 

Sure, will do. 

> Hmmm... How would you want to use that tag to force the bootloader to
> load the modules above/below the kernel?
> 
> Daniel

Either in my case, or the motivation to quirk-modules-after-kernel in Multiboot, the
problem was that it's preferred that the modules not be loaded at lower address, 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. 
Kernel will be loaded at known address, either through address tag, or ELF. 
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 guaranteed  to 
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 relative large.

-Zide