[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <1382449985.18283.12.camel@hastur.hellion.org.uk>
Date: Tue, 22 Oct 2013 14:53:05 +0100
From: Ian Campbell <ian.campbell@...rix.com>
To: Konrad Rzeszutek Wilk <konrad.wilk@...cle.com>
CC: Jan Beulich <JBeulich@...e.com>, <ross.philipson@...rix.com>,
<stefano.stabellini@...citrix.com>, <grub-devel@....org>,
<david.woodhouse@...el.com>, <richard.l.maliszewski@...el.com>,
<xen-devel@...ts.xen.org>, <boris.ostrovsky@...cle.com>,
Daniel Kiper <daniel.kiper@...cle.com>,
Peter Jones <pjones@...hat.com>,
<linux-kernel@...r.kernel.org>, <keir@....org>
Subject: Re: EFI and multiboot2 devlopment work for Xen
On Tue, 2013-10-22 at 09:42 -0400, Konrad Rzeszutek Wilk wrote:
> Looking at the Fedora GRUB2 source, the 'struct linux_kernel_header' is defined
> in the linux/Documentation/x86/boot.txt and hpa is pretty strict
> about making it backwards compatible. It also seems to support Xen!
>
> (Interestingly enough we do have this structure in the code: see
> setup_header in arch/x86/bzimage.c)
There will be another usage in tools/libxc/...bzimage too
FWIW I think we only use this stuff for the magic number/version and the
payload_offset/length fields, which we do in order to extract the
payload (ELF file) for booting dom0 and domU. It's not AFAIK used for
booting Xen itself or lets say, that's not why I added it ;-)).
> Which in the GRUB2 is being constructed by parsing the EFI
> data structures. But Linux concentrates on the EFI parts and mostly
> ignores the rest. So this is more about passing those EFI values
> downstream.
I wonder why Linux can't make the EFI calls to fetch them itself?
Ian.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists