|
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] Re: [Xen-devel] [RFC/patch] domain builder rewrite
> 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@xxxxxxx> http://www.suse.de/~kraxel/julika-dora.jpeg _______________________________________________ Xen-devel mailing list Xen-devel@xxxxxxxxxxxxxxxxxxx http://lists.xensource.com/xen-devel
|
 |
Lists.xenproject.org is hosted with RackSpace, monitoring our |
