While I have to wait for some internal legal matters to settle before I
can submit an initial (small) set of patches for a first round of reviews/
comments, I wanted to take the opportunity to both announce that
the boot part of this work is now mostly done, and ask a couple of
related questions.
While supposedly (or just theoretically?) it is possible to boot Xen
indirectly through e.g. GrUB2's EFI support, any use of an
intermediate boot loader is bogus when using EFI - Linux has to do
so because of its custom load file format, but Xen certainly doesn't
have to follow this (as it also uses the more generic multiboot
protocol when booted from GrUB).
Consequently the natural mechanism is to build Xen as an EFI
application binary, thus making it possible to have it run directly
from the EFI shell or boot manager.
To keep the amount of dependencies down, I decided against the
elilo way of building on top of the gnu-efi package - all that gets
done (as for e.g. ACPI) is to import a couple of header files.
Beyond that, one "special" feature each is required to be available
in compiler and linker: The former has to support the ms_abi
function attribute, the latter must support linking full-fledged EFI
binaries (minus proper relocation support, which gets dealt with
through a custom build utility). If either is unavailable, the building
of an EFI binary simply gets disabled (while still generating the
traditional gzip-compressed ELF binary).
Questions/issues:
1) While for obtaining the necessary firmware information
XENPF_firmware_info was an obvious and natural fit, I'm not as
certain for the to-be-implemented Dom0 access to the runtime
services. I'm currently favoring a new XENPF_ sub-hypercall.
2) The installation is part is still relatively unclear to me at this
point: Linux irrespective of whether EFI is present, simply installs
into /boot, relying on elilo to copy the necessary files over. As
we're not going to use a secondary boot loader, we'd have to
do this ourselves, but the mandated location is in
<EFI-mountpoint>/efi/<vendor>/, and the <vendor> part
("SuSE" in our case) is what I don't see easily handled (as I
wasn't able to find this stored in any system configuration file).
3) GrUB decompresses simple gzip-ed binaries (i.e. the traditional
non-bzImage kernel), but with EFI Xen will need to do so itself.
The most obvious choice would seem be to allow for all currently
supported compression methods to not only be used inside a
bzImage container, but also on a plain ELF binary.
Jan
_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel
|
Home