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

[Gerd Hoffmann <kraxel@suse.de>]

Eric W. Biederman wrote:
> 
> 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.e. you insert a additional state into the boot process which does the
relocation and page table setup?  URL would to the patch be nice, yes.
A paper (or at least a short outline how it works) even better ;)

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

Well, xen has two modes now:  One where the guest knows the machine
addresses and has to translate machine[1] <=> physical[2] addresses.
And one where xen does the translation transparantly.  The former
performs better, the later is easier to implement ;)

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

For the build system it shouldn't matter.  Ideally only the code
creating page tables has to care about that.  Right now xen creates
old-style ELF binaries (pre-kexec merge) with wrong paddr entries, but
that's fixable (have patches pending for xen).

Unlike real hardware xen virtual machines run with paging enabled all
the time, so you can't just turn off paging to get a identity (phys ==
virt) mapping.  That makes things a bit harder sometimes.

  Gerd

[1] machine address  == physical address of the real hardware.
[2] physical address == physical address of the virtual machine.

-- 
Gerd 'just married' Hoffmann <kraxel@suse.de>
I'm the hacker formerly known as Gerd Knorr.
http://www.suse.de/~kraxel/just-married.jpeg