Re: Xen bootloader (was: Re: [Xen-devel] Xen Roadmap proposal)

[Mark Williamson <mark.williamson@xxxxxxxxxxxx>]

> So do you mean the kexec
> 1. from dom0, that is used to restart xen and dom0
> 2. or kexec in domU that will load this own first kernel then the
> final kernel in the domU.?

The latter - we currently don't have a means of implementing a guest 
bootloader that's fully isolated (runs only in the guest domain, hence secure 
in the event of compromise).  Kboot will also support network boot, and just 
about any filesystem we want.  Since it runs in the domain, it'll also 
support consoles properly for interactive use.

The default for config files would be to boot the kboot kernel+initrd, which 
would then load the correct kernel+initrd for that guest, according to a 
configuration file or a user menu choice.

Cheers,
Mark

>
> YH
>
> On 7/13/06, Mark Williamson <mark.williamson@xxxxxxxxxxxx> wrote:
> > Just floating this for general comment -
> >
> > For the bootloader work, we should consider Kboot:
> > http://kboot.sourceforge.net/
> >
> > Kboot is designed to use a "conventional" bootloader to start a Linux
> > kernel running "full" bootloader functionality.  This is responsible for
> > loading and kexec-ing the kernel the user actually wants to run.  The
> > advantage of this is that all the high level functionality of grub
> > (interactive menus, filesystem support, networking) are now provided by a
> > full Linux environment rather than a large special purpose codebase.
> >
> > Some folks at IBM (Michael included) have been working on an update to
> > this called kboot_sl (system loader): http://merbach.net/kboot_sl/
> >
> > The zSeries guys want this because their z/IPL bootloader doesn't have
> > any interactivity - rather like the domain builder.  They want to start a
> > default "kboot" kernel and have that display the user interface, offer
> > network boot options, etc, and then kexec to the "real" kernel.  Their
> > requirements are similar to ours, so kboot_sl is worth a look.
> >
> > I think this is an approach we should look at.
> >
> > It gets us:
> > * Interactive bootloader
> > * Guest kernel stored in its own filesystem
> > * Network boot
> > * Multiple filesystem support (in principle, anything that Linux
> > supports) * Exotic boot support (boot from http, ftp, ssh - good for
> > developers) * A common platform with other software
> >
> > A port of Grub(2?) might also be nice to have, but I suspect that (given
> > a working kexec) kboot_sl will be easier to get working and will be more
> > flexible.
> >
> > Cheers,
> > Mark

-- 
Dave: Just a question. What use is a unicyle with no seat?  And no pedals!
Mark: To answer a question with a question: What use is a skateboard?
Dave: Skateboards have wheels.
Mark: My wheel has a wheel!

_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel