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

["Jacob Gorm Hansen" <jacobg@xxxxxxx>]

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