Messages in this thread | | | Date | Fri, 10 Mar 2006 10:58:49 +0100 | From | Gerd Hoffmann <> | Subject | Re: [PATCH] Fix ELF entry point (i386) |
| |
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 - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
| |