Re: [Xen-devel] [MULTIBOOT2 DOC PATCH 06/10] multiboot2: Add description of support for relocatable images

[Daniel Kiper]

On Thu, Jun 09, 2016 at 10:36:29PM +0100, Andrew Cooper wrote:
> On 09/06/2016 21:30, Daniel Kiper wrote:
> > Signed-off-by: Daniel Kiper <address@hidden>
> > ---
> >  doc/multiboot.texi |   56 
> > ++++++++++++++++++++++++++++++++++++++++++++++++++++
> >  doc/multiboot2.h   |   24 ++++++++++++++++++++++
> >  2 files changed, 80 insertions(+)
> >
> > diff --git a/doc/multiboot.texi b/doc/multiboot.texi
> > index 130176a..f1e0e09 100644
> > --- a/doc/multiboot.texi
> > +++ b/doc/multiboot.texi
> > @@ -359,6 +359,7 @@ executable header.
> >  * Console header tags::
> >  * Module alignment tag::
> >  * EFI boot services tag::
> > +* Relocatable header tag::
> >
> >  @end menu
> >
> > @@ -681,6 +682,47 @@ u32     | size = 8          |
> >  This tag indicates that payload supports starting without
> >  terminating boot services.
> >
> > address@hidden Relocatable header tag
> > address@hidden Relocatable header tag
> > +
> > address@hidden
> > address@hidden
> > +        +-------------------+
> > +u16     | type = 10         |
> > +u16     | flags             |
> > +u32     | size = 24         |
> > +u32     | min_addr          |
> > +u32     | max_addr          |
> > +u32     | align             |
> > +u32     | preference        |
> > +        +-------------------+
> > address@hidden group
> > address@hidden example
> > +
> > +This tag indicates that image is relocatable.
> > +
> > +The meaning of each field is as follows:
> > +
> > address@hidden @code
> > address@hidden min_addr
> > +Lowest possible physical address at which image should be loaded.
> > +Boot loader cannot load any part of image below this address.
>
> "The bootloader".

This and earlier comments show, what I know very well, that a/the
English stuff is huge pain for me. Ehh... It looks that I should
not update any docs... ;-))) Anyway, thank you for your comments!

[...]

> > +struct multiboot_header_tag_relocatable
> > +{
> > +  multiboot_uint16_t type;
> > +  multiboot_uint16_t flags;
> > +  multiboot_uint32_t size;
> > +  multiboot_uint32_t min_addr;
> > +  multiboot_uint32_t max_addr;
>
> 64bit multiboot2 payloads could reasonably expect to be able to have
> themselves relocated about the 4G boundary.

That is true but in general the multiboot2 protocol is 32-bit stuff.
So, I prefer to stay in 32-bit domain. Just in case. If we need to use
full blown 64-bit thing then, IMO, we should introduce new protocol
(e.g. multiboot3) with full 64-bit support, probably compatible with
32-bit stuff to some extent.

Daniel