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 ;)
Current TODO list:
- discuss design, fixup if needed ;)
- more testing.
- re-add bsd symtab loading.
- re-add other architectures.
- re-add loader bits (plan9, ...)
cheers,
Gerd
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel
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@lists.xensource.com http://lists.xensource.com/xen-devel
> 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.That is an unrelated problem. It''s certainly possible to do that, probably even easier in the new framework. On real hardware boot loaders usually do _not_ setup that kind mappings though, that is the job of the OS kernel. And I think we should to that in xen the same way, to make porting OS''es as simple as possible and also to keep the code differences between native and xen guest as small as possible.> 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.It needs to know to bootstrap domain 0 only, all other domains are created by the tools, not the hypervisor itself. cheers, Gerd -- Gerd Hoffmann <kraxel@suse.de> http://www.suse.de/~kraxel/julika-dora.jpeg _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
Gerd Hoffmann wrote:>> 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. >> > > It needs to know to bootstrap domain 0 only, all other domains are > created by the tools, not the hypervisor itself. >It always struck me as odd that we duplicated the domain builder code in both in userspace and in the hypervisor. Have you given any thought of unifying the two? I always thought it would be neat to have a hypercall that could build paravirt domains at least... Regards, Anthony Liguori> cheers, > > Gerd > >_______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
> It always struck me as odd that we duplicated the domain builder code in > both in userspace and in the hypervisor. Have you given any thought of > unifying the two?No. It probably could work for the current one as you can see everywhere that one was created by copy&pasting the other one some time ago. The rewritten one wouldn''t work very well within the hypervisor due to the design. cheers, Gerd -- Gerd Hoffmann <kraxel@suse.de> http://www.suse.de/~kraxel/julika-dora.jpeg _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel