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.
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.
> 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.
> 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.
J
