Re: [Xen-devel] [kvmarm] boot-wrapper: simple multi module loading support

[Ian Campbell <Ian.Campbell@xxxxxxxxxx>]

On Mon, 2012-09-03 at 16:00 +0100, Marc Zyngier wrote:
> On 03/09/12 14:30, Ian Campbell wrote:
> 
> Hi Ian,
> 
> > Apparently kvmarm@ is the place for boot-wrapper discussions so
> > apologies for the otherwise Xen related mail ;)
> > 
> > The following implements support for a very basic protocol for loading
> > multiple "modules" and providing them to the kernel. The ARM port of Xen
> > uses this to support passing both a dom0 kernel and initrd to the
> > hypervisor "kernel".
> > 
> > The Xen side of this can be found in the series at:
> >         http://lists.xen.org/archives/html/xen-devel/2012-09/msg00065.html
> > 
> > With that you can boot Xen on arm using the semi-hosting feature of the
> > model (paths are host paths):
> >         $MODEL linux-system-semi.axf -C cluster.cpu0.semihosting-cmd_line=\
> >                     '--kernel xen-arm.bin \
> >                      --module zImage earlyprintk=xenboot console=ttyAMA1 
> > root=/dev/mmcblk0 ro \
> >                      --dtb vexpress-v2p-aem-v7a-xen.dtb -- dom0_mem=256M'
> > 
> > Until we know what bootloaders are going to become common in the ARM
> > servers world it hard to know who we should be working with to define a
> > proper protocol going forward and which bootloaders to supply patches
> > for etc. If anyone has any pointers that would be very useful.
> 
> I don't have any useful insight about bootloaders (I tend to hate them
> all ;-), but what we (KVM/ARM) need is something that implements the
> "boot in HYP mode" thing, as described here:
> 
> https://lists.cs.columbia.edu/pipermail/kvmarm/2012-August/002829.html
> 
> From a discussion with Stefano last week, it looks like this protocol
> can fit Xen as well, but it would be nice to have a formal Ack before we
> push this into RMK's patch system.

Yes, Xen needs this "boot in hyp mode" functionality as well, which AIUI
is main core of the proposal. The bits about leaving a stub hypervisor
behind when the kernel then drops to SVC mode is really an internal
Linux/KVM implementation detail. Xen expects to be launched in hyp mode
and will stay there, it launches the domain 0 kernel in svc mode (so
under Xen the kernel never sees hyp mode).

The proposal in
https://lists.cs.columbia.edu/pipermail/kvmarm/2012-August/002828.html
seems consistent with Xen's requirements to me, both for the hypervisor
itself and the guest kernels (including dom0).

The functionality I'm implementing in boot-wrapper here is something
unrelated to this, it is the mechanism by which the initial modules,
which are loaded by the bootloader and passed to the kernel, get passed
across. This is somewhat similar to the kernel's initrd except there can
be more than one, typically there are two (domain 0 kernel and domain 0
initrd) but you can imagine a world with multiple initial domains and
therefore 2*N modules. This has uses outside of virtualisation too, e.g.
L4 and Hurd both use multiboot (which is the x86 standard for this sort
of stuff), to load all the required initial binaries to get a usable
system off the ground.

Ian.


_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxx
http://lists.xen.org/xen-devel