Re: [PATCH] Fix ELF entry point (i386)

[ebiederm@xmission.com (Eric W. Biederman)]

Gerd Hoffmann <kraxel@suse.de> writes:

>> Currently my assumptions are:
>> 
>> Standalone executables load at the physical not the virtual addresses.
>> Standalone executables start executing at a physical address and not at
>> a virtual address.
>
> Well, that is true for real hardware.  xen guest kernels are booted with
> paging already enabled and thus the entry point is in virtual memory,
> and I'm trying to figure how to handle that best (both for initial boot
> and kexec).
>
> xen uses a special xen header anyway to give the domain builder a hint
> how the initial page tables should look like (they look simliar to what
> head.S creates on real hardware).  That can also be used to figure the
> correct virtual entry point from the physical one.  It probably even
> makes more sense to do that (instead of writing the virtual address into
> the entry point) as the xen domain builder doesn't look at the virtual
> addresses in the ELF headers too.  It uses PAGE_OFFSET+paddr instead.
> That keeps the differences between real and virtual hardware small ...

Ok. The unmerged Xen case.

I have some pending patches that make a bzImage a ET_DYN executable.
Would that be interesting to you?  Especially if that would just mean
your initial page tables got to set physical == virtual?

I believe Xen does expose the actual physical addresses to the guest.

Either that or this is a case where Xen probably needs to take a
different path in the build system.

Eric