On Wed, May 02, 2007 at 02:59:11PM -0700, H. Peter Anvin wrote: > Jeremy Fitzhardinge wrote: > > > > So the bzImage structure is currently: > > > > 1. old-style boot sector > > 2. old-style boot info, followed by 0xaa55 at the end of the sector > > 3. the HdrS boot param block > > 4. setup.S boot code > > 5. the self-decompressing kernel > > > > If we make 5 actually an ELF file, containing properly formed Ehdr, > > Phdrs (for all the mappings required), and the actual kernel > > decompressor, relocator and compressed kernel data, then it would be > > easy for the Xen domain builder to find that and use it as a basis for > > loading. I think it would just require the bzImage boot param block to > > contain an offset of the start of the ELF file. The contents of the ELF > > file would be in a form where the normal boot code could just jump over > > the ELF headers, directly into the segment data itself. > > > > ie: > > > > 1. old-style boot sector > > 2. old-style boot info, followed by 0xaa55 at the end of the sector > > 3. the HdrS boot param block > > 4. setup.S boot code (jumps directly into 5.3) > > 5. 32-bit self-decompressing kernel: > > 1. Ehdr > > 2. Phdrs for all necessary mappings > > 3. decompressor/relocator .text > > 4. compressed kernel data > > > > Does that sound reasonable? > > > > I don't know if that would break any programs that are currently > bypassing the setup. I think kexec bzImage loader will break. It bypasses the setup code and directly jumps to the code present after setup sectors(decompressor). > The existing setup protocol definitely allows > invoking an entry point which isn't 0x100000 (rather, the 32-bit > entrypoint is defined by code32_start); I'm not sure how Eric's > relocatable kernel patches (2.05 protocol) affect that, mostly because I > haven't seen any boot loaders which actually use it so I can't comment > on what their code looks like. With relocatable patches, if a boot loader decides to load protected mode component at non-1MB address, then it shall have to modify code32_start to reflect the new location of protected mode code. Thanks Vivek _______________________________________________ Virtualization mailing list Virtualization@xxxxxxxxxxxxxxxxxxxxxxxxxx https://lists.linux-foundation.org/mailman/listinfo/virtualization
