Re: [Xen-devel] [RFC/patch] domain builder rewrite

[Simon Kagstrom <simon.kagstrom@xxxxxx>]

Hi Gerd!

I hope I've understood what you are trying to do.

At Thu, 01 Jun 2006 16:59:07 +0200,
Gerd Hoffmann wrote:
>   Hi,
> 
> I've started cleaning up the domU domain builder, which basically ended
> up in being a nearly complete rewrite of the code.  The patch below is
> the very first cut of the new code.  I've tested it on x86_32 (both
> with and without shadow_translated) and with linux kernels only.  In
> theory PAE mode and x86_64 should work too, I havn't even compiled on
> x86_64 though.
> 
> Design goals:
>   - General cleanup of the code, move lots of state information
>     which currently is held in local variables into a struct.
>   - separate out arch-specific bits into functions and source files
>     (as far as possible), so there are not tons of #ifdef's all over
>     the place ;)
>   - Don't have xen hypercalls all over the place, so most of the
>     code runs just fine without xen.
> 
> Why I'm doing this:
>   - The current code is a mess ...
>   - I want to reuse the domain builder code for other purposes than
>     directly booting xen domains.  domU kexec is the first item on
>     my todo list.  Directly writing a suspend image, then boot the
>     virtual machines via "xm restore" should be easy too.  It isn't
>     very useful on a single host, but booting xen virtual machines
>     on _another_ machine that way (using the migration protocol)
>     probably is.
>   - I'm sure other people have fancy idea's too ;)

This sounds like useful stuff to me :-). A thing which I think would
be good is to allow more flexible handling of the ELF files. In
particular, it would be nice if it was possible to arrange the virtual
address space more freely, i.e., loading an ELF-file like:

  [Nr] Name              Type            Addr     Off    Size   ES Flg Lk Inf Al
  [ 0]                   NULL            00000000 000000 000000 00      0   0  0
  [ 1] .text             PROGBITS        c0000000 02e000 1d9ce8 00 WAX  0   0 32
  [ 2] .rodata           PROGBITS        c01d9d00 207d00 05b840 00   A  0   0 32
  [ 3] header            PROGBITS        c0235540 263540 00004c 00   A  0   0  8
  [ 4] .kstrtab          PROGBITS        c023558c 26358c 00077a 00   A  0   0  1
  [ 5] __ksymtab         PROGBITS        c0235d08 263d08 000480 00   A  0   0  4
  [ 6] .data             PROGBITS        90000000 001000 00d5a8 00  WA  0   0 
4096
  ...

where the data and code are mapped to different locations in memory. I
guess this is along the lines of your "writing a suspended image
directly" idea?


I guess that the hypervisor really doesn't need to know about ELF
images at all? To me it seems that it should be enough for it to get a
suspended image built by the domain.

Sorry if I've overlooked some fundamental issue here.

// Simon

_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel