Re: Request to revert superpage adjustments

[Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>]

> >>  Nor would
> >> that deal with avoiding reserved regions not too far above 1Mb,
> >> since at best the main payload can be relocatable (but certainly
> >> not the binary seen by the boot loader, as at least multiboot1
> >> doesn't support anything like that).
> > 
> > The only reason Xen sits at the 1MB boundary is because of its ELF header.
> > 
> > A plain binary with a multiboot header has no such restriction, although
> > we flag an interested to have 4k alignment using the multiboot flags. 
> > There is no technical limitation causing Xen to be linked to run at 1MB;
> > its just the way its alway been.  There is nothing preventing the entry
> > point becoming properly relocatable.

And one can make it be at 2MB - which is what Daniel's patches did.
(CC-ing Daniel in case I got it wrong). We also needed GRUB2 patches
to take into account relocating Xen at a different location.

> 
> Without proper container format, how would the boot loader
> know where to place the binary, or how to relocate it if it doesn't
> get placed at its linked address? The only alternatives I see in
> grub1 are a.out and a kludge of a.out, both of which - at the first
> glance - also don't appear to do any relocation. And for the Linux
> variant, as said, it doesn't look like it's compatible with us needing
> multiple modules.
> 
> Jan
> 
> 
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xen.org
> http://lists.xen.org/xen-devel

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel