[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] Re: [Xen-devel] [PATCH] Elf loader fixes
On 2/22/06, Gerd Hoffmann <kraxel@xxxxxxx> wrote: > As I see things there are basically two ways to fixup this: Either > create a simple linear mapping using paddr + VIRT_BASE, which would be > pretty close to the current behaviour (and other boot loaders). Or do a > complete virtual memory setup, which probably can't be done without > major changes in the domain builder ... hi, as previously mentioned here and at the XenSummit, I have a simple yet functioning domU bootloader which defers ELF-decoding to domU-space. It currently only works when the input is a ramdisk image, created with a small tool called 'pack. It used to work from a TCP-connection (provided by the fabulous UIP which is still in my tree), hence the weird state-machine look of the code. I suppose taking this approach could solve all our domU-building woes for good. It should also provide a more elegant solution to the attestation problems the Intel guys were talking about and trying to solve with their two-stage domain building proposal. Clone my tree at http://www.distlab.dk/hg/index.cgi/xen-gfx.hg and have a look at the extras/mstrap subdir. The 'pack' tool is in tools/migrate. You will need Jam to build, or you have to roll your own Makefile. The tree also contains my very experimental 'Blink' display system as demoed at the Summit in tools/gfx, and my self-migration patch to XenLinux which at the moment is mostly useful for self-checkpointing to disk (see tools/minimig.c). Your mileage may vary. Jacob _______________________________________________ Xen-devel mailing list Xen-devel@xxxxxxxxxxxxxxxxxxx http://lists.xensource.com/xen-devel
|
![]() |
Lists.xenproject.org is hosted with RackSpace, monitoring our |