[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 03:25:39PM +0000, Woodhouse, David wrote: > On Tue, 2013-10-22 at 10:43 -0400, Konrad Rzeszutek Wilk wrote: > > > > And looking at bit deeper in the x86/linux boot spec: > > > > **** EFI HANDOVER PROTOCOL > > > > > > > > This protocol allows boot loaders to defer initialisation to the EFI > > > > boot stub. The boot loader is required to load the kernel/initrd(s) > > > > from the boot media and jump to the EFI handover protocol entry point > > > > which is hdr->handover_offset bytes from the beginning of > > > > startup_{32,64}. > > Oh, ignore that. You want the *actual* PE executable entry point, as it > would get invoked by a real UEFI firmware. Right. The Xen hypervisor can be built in two images: a standard PE/COFF that can be executed from the EFI shell, and an multiboot blob that can be loaded by multiboot compatible boot loaders (like GRUB). > > I thought that's what Grub invoked, for 'linuxefi'. Perhaps I mean a > chainloader method of some kind instead. Either way, make Grub (or > whatever bootloader you choose) load it as an EFI executable. Looks like chainloader was it from Peter's answer. But then you can't do SecureBoot <sigh>. > > Seriously, forget Grub for now. Grub is mostly just an exercise in > gratuitously doing things the difficult way and wondering why it's > fragile. > > Make your code work as an EFI executable when loaded directly from the > UEFI firmware. Worry about the insanity of grub later. That has been done by Jan. Now we are at the 'have a shim that launches GRUB2, now what?' > > > -- > Sent with MeeGo's ActiveSync support. > > David Woodhouse Open Source Technology Centre > David.Woodhouse@xxxxxxxxx Intel Corporation > > > _______________________________________________ Xen-devel mailing list Xen-devel@xxxxxxxxxxxxx http://lists.xen.org/xen-devel
|
Lists.xenproject.org is hosted with RackSpace, monitoring our |