Jeremy Fitzhardinge <jeremy at goop.org> writes: > Eric W. Biederman wrote: >> Xen passes parameter block? Is there no shim layer between Xen and the kernel >> it is loading? No bootloader? If there isn't some kind of bootloader thing > int >> the middle I think we have a huge interface stability problem. >> > > In the dom0 case (which we're not really talking about here), the kernel gets > loaded as a grub module for Xen, and Xen does all the work to construct the dom0 > domain and start it up. There's a section in the ELF file which contains > various pieces of metadata about the kernel for Xen to use when constructing the > domain, which includes the entrypoint the kernel wants Xen to use. To pick a nit. Bootloaders should never use ELF sections only ELF segments. In particular that is what the note segment is for. > In the domU case, the domain is constructed by a domain builder, which is > user-space code running in dom0. After that, the boot sequence is more or less > the same as the dom0 case (I think). The domain builder is essentially the boot > loader, and it just arranges the initial address space and CPU state so the > kernel can be run directly. Sounds sane. >> There is a lot to be gained by having a single entry point and the kernel > looking >> at parameters it is passed and the state of the system and seeing what to do. >> > > Doesn't that mean that it will become an increasingly complex tangle of subtle > dependencies? It's already pretty hairy. Only we if we have implicit and not explicit rules on what is needed. The current state is not too bad and we can successfully and cleanly extend it. The maintenance requirements in other parts of the system are much worse if we don't. >> In particular it gives us a stable ABI so the kernel and it's bootloaders can >> evolve independently. Exporting an entry point address is a non-trivial thing >> to do and to maintain. Exporting multiple entry point addresses is very > difficult >> and expensive. Because you have to cope with the weirdness of recompiling > code >> and relative offsets between routines changing. >> > > Xen relies on the kernel image being an ELF file, and it uses an ELF section to > hold various pieces of useful information about the kernel, including the > preferred entrypoint. It doesn't rely on entry code being at a specific address > or anything; maintaining it should be transparent to, and independent from, > anything else going on in head.S. The problem is that an ELF header has exactly one ELF entry point. Just to verify, the goal when we are done is to have one binary kernel that will run on real hardware, under Xen, and paravirtualized VMware, and on any other hypervisor that comes along. As I understand it. That goal requires a bzImage with an ELF header :) Which we will have shortly. And no the kernel will not be multiboot as that is not an extensible standard. Which makes multiboot useless, in the long term. Eric
