Re: [Xen-devel] [PATCH] Elf loader fixes

["Christian Limpach" <christian.limpach@xxxxxxxxx>]

On 2/23/06, Gerd Hoffmann <kraxel@xxxxxxx> wrote:
> > some with p_vaddr == p_paddr on purpose and some which don't. We rely on a
> > "boot loader" (ie grub or domain builder) that only cares about p_paddr.
>
> Same goes for the x86_64 linux kernel with the vsyscall page ...
>
> I've settled for a slightly different approach now.  To keep behaviour
> as close as possible to classic i386 boot loaders I'll check paddr only
> and use the virt_base value from the __xen_guest section to shift the
> addresses.  For bug compatibility with old linux kernels I compare paddr
> + virt_base.  New patch below, this time tested both 32 and 64 bit
> (linux only though), I think it should be ok for OpenSolaris too ;)

I have two issues with your latest patch:
- the heuristics you use to distinguish between "old" and "new" kernel
images, especially the case where a valid "new" kernel image could be
mistaken for an "old" image.
- the change to the entry point, now entry point and the elf header
paddr fields are in different address modes.

We have the current combination of VIRT_BASE and elf header paddr
fields containing virtual addresses because:
- we want to be able to specify where the virtual address space mapped
by the initial pagetables starts, this is why we have VIRT_BASE
- since we always run in virtual address mode, we thought that the
loader should also do so, thus it will load the image to a virtual
address - this seems to be in line with how other loaders would read
the elf header paddr fields, i.e. use them as load addresses.

If we really need to get rid of how we change LOAD_OFFSET in Linux,
how about this:
we add another entry to the __xen_guest header, PHYS_OFFSET=0 and then
substract PHYS_OFFSET from all elf header paddr fiels to turn them
into physical addresses, respectively, resp. add VIRT_BASE-PHYS_OFFSET
to turn them into virtual addresses.  We default PHYS_OFFSET to
VIRT_BASE if it's not present in the __xen_guest header.

     christian

_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel