Re: [PATCH 18/18] x86: add multiboot2 protocol support for EFI platforms

[Daniel Kiper]

On Sat, Feb 14, 2015 at 08:23:45PM +0300, Andrei Borzenkov wrote:
> В Wed, 11 Feb 2015 08:20:04 +0000
> "Jan Beulich" <address@hidden> пишет:
>
> > >>> On 10.02.15 at 22:27, <address@hidden> wrote:
> > > After some testing we have found at least one machine on which this thing
> > > does not work. It is Dell PowerEdge R820 with latest firmware. Machine
> > > crashes/stops because early 32-bit code is not relocatable and must live
> > > under 0x100000 address. (side note: I am surprised how it worked without
> > > any issue until now; Multiboot protocol, any version, does not guarantee
> > > that OS image will be loaded at specified/requested address;
> >
> > How does it not? It's an ELF binary without relocations that's being
> > loaded - I can't see how such could be validly loaded anywhere but
> > at the virtual address(es) its program header states (and I don't
> > know whether grub [1 or 2] would correctly process relocations if
> > there were any, but I doubt it).
> >
>
> grub2 relocates own modules when loading them. It does not do

Great! However, it also ignores MULTIBOOT_TAG_TYPE_EFI_BS flag
and overwrite BS if it leaves in region requested by image. It
is a bug which I have just discovered. I will fix it.

> relocation when loading Xen binary, but it does not sound impossible.

Ugh... You are right. I was confused because multiboot2 command just
allocate memory outside reserved regions. I thought that this is final
destination. However, later if you execute boot command then image
is relocated to final destination. Facepalm! Anyway, we must support
relocatable images in multiboot2 protocol. I think that image (any
format, e.g. PE) could inform loader that it can live anywhere below
4 GiB by setting special flag in multiboot2 header. Or ELF image could
have relocation section which would be interpreted by loader. Both
approaches make sense and are feasible.

Daniel