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. 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.
-hpa
_______________________________________________
Virtualization mailing list
[email protected]
https://lists.linux-foundation.org/mailman/listinfo/virtualization
