[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Xen-devel] EFI and multiboot2 devlopment work for Xen



On Tue, Oct 22, 2013 at 05:08:03PM +0100, Ian Campbell wrote:
> On Tue, 2013-10-22 at 18:01 +0200, Daniel Kiper wrote:
> > On Tue, Oct 22, 2013 at 03:42:42PM +0000, Woodhouse, David wrote:
> > > On Tue, 2013-10-22 at 16:32 +0100, Matthew Garrett wrote:
> > > >
> > > > There are two problems with this:
> > > >
> > > > 1) The kernel will only boot if it's signed with a key in db, not a key
> > > > in MOK.
> > > > 2) grub will read the kernel, but the kernel will have to read the
> > > > initramfs using EFI calls. That means your initramfs must be on a FAT
> > > > partition.
> > > >
> > > > If you're happy with those limitations then just use the chainloader
> > > > command. If you're not, use the linuxefi command.
> > >
> > > Well, we're talking about booting the Xen hypervisor aren't we?
> > >
> > > So yes, there are reasons the Linux kernel uses the 'boot stub' the way
> > > it does, but I'm not sure we advocate that Xen should emulate that in
> > > all its 'glory'?
> >
> > Right, I think that sensible mixture of multiboot2 protocol (it is needed
> > to pass at least modules list to Xen; IIRC, linuxefi uses Linux Boot 
> > protocol
> > for it) with extension proposed by Vladimir and something similar to 
> > linuxefi
> > command will solve our problem (I proposed it in my first email). Users 
> > which
> > do not need SB may use upstream GRUB2 and others could use
> > 'multiboot2efi extension'.
>
> Are you (going to be) in Edinburgh? Matthew was just explaining a bunch
> of this stuff to me, it might be useful for you to get it from the
> horses mouth instead of laundered through my brain (which is a bit
> addled afterwards ;-)).

Sadly no. However, if it is possible/needed I could participate in conference 
call.

Daniel

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


 


Rackspace

Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.