Xen EFI: Difference between revisions

From Xen
Jump to navigationJump to search
 
(4 intermediate revisions by 4 users not shown)
Line 35: Line 35:
</pre>
</pre>


Alternatively you can build you GCC crosstool chain[http://wiki.osdev.org/UEFI OSDev UEFI link]
Alternatively you can build the [http://wiki.OSDev.org/UEFI#Developing_with_GNU-EFI GCC crosstool chain] documented in the [http://wiki.OSDev.org OSDev.org wiki.]


Or you can recompile your binutils (Fedora Core 25):
Or you can recompile your binutils (Fedora Core 25):
Line 117: Line 117:
[Both the Linux kernel and initramdisk MUST reside in the same directory as xen.efi]
[Both the Linux kernel and initramdisk MUST reside in the same directory as xen.efi]


* sudo cp xen/xen/xen.efi /boot/efi/EFI/xen
* sudo cp /boot/xen/xen.efi /boot/efi/EFI/xen
* Create the xen.cfg file:
* Create the xen.cfg file:
<pre>
<pre>
Line 196: Line 196:
* git clone https://git.savannah.gnu.org/git/grub.git
* git clone https://git.savannah.gnu.org/git/grub.git
* cd grub
* cd grub
* ./autogen.sh
* ./configure --target=x86_64 --with-platform=efi
* ./configure --target=x86_64 --with-platform=efi
* make
* make
Line 248: Line 249:


And you are good to go.
And you are good to go.

= Compatibility of UEFI Host Firmware, Xen and UEFI Runtime Services =

On some devices with UEFI firmware that does not strictly conform to UEFI specifications, Xen may fail to boot when UEFI Runtime Services is enabled. The Xen command line option '''efi=no-rs''' can be used to disable UEFI Runtime Services, which may allow Xen to boot on some machines with non-compliant host UEFI firmware, at the cost of losing access to UEFI Runtime Services.

Ideally, such UEFI firmware non-compliance would be identified during OEM/ODM pre-release testing with Xen and other bare-metal hypervisors and operating systems. In practice, it is difficult to obtain UEFI firmware fixes for hardware devices that are already released. If you are unable to obtain compliant UEFI host firmware from your device OEM, Xen 4.13 provides an opt-in (''expert'') build-time config option (CONFIG_EFI_SET_VIRTUAL_ADDRESS_MAP=y) to improve compatibility between non-compliant UEFI host firmware, Xen and UEFI Runtime Services.

Boot compatibility was reportedly improved for the following devices, with variability between multiboot2 and xen.efi:

* Thinkpad W540
* Thinkpad X230, firmware 2.77
* Thinkpad P52, firmware 1.25

Please update the above list with device make, model and firmware version.

Latest revision as of 02:37, 22 November 2019

Xen in EFI

Xen 4.3 and later can be built as EFI binaries. Xen 4.5 can be built as an EFI binary under ARM. Xen 4.9 can be built with Multiboot2 support which GRUB2 2.02 uses.

Linux 3.17 and later when built with CONFIG_XEN_EFI can be booted under Xen in EFI platform.

Xen does support verifying of payloads, such as the initial kernel and its ramdisk via the Shim protocol (GUID: 0x605dab50, 0xe046, 0x4300, {0xab, 0xb6, 0x3d, 0xd8, 0x10, 0xdd, 0x8b, 0x23).

For shim repo, please see shim.

Compiling Xen as EFI

Compiling under x86

During the compilation process most of the Xen hypervisor code is compiled using the normal compiler (GCC). Only during the link-time do we employ the EFI linker to built an EFI binary.


As of Ubuntu 16.04 the binutils is compiled with PE (EFI) support. To verify run ld -V. You are looking for i386pe in it, as so:

$ ld -V
GNU ld version 2.26.1-1.2.fc25
  Supported emulations:
   elf_x86_64
   elf32_x86_64
   elf_i386
   elf_iamcu
   i386linux
   elf_l1om
   elf_k1om
   i386pep
   i386pe

Alternatively you can build the GCC crosstool chain documented in the OSDev.org wiki.

Or you can recompile your binutils (Fedora Core 25):

  • dnf download --source binutils
  • rpm -hiv binutil*.srpm
  • cd /usr/src/redhat/SPECS
  • sudo dnf builddep --spec binutils.spec
  • patch -p1 < pe_binutils.patch

The pe_binutils.patch looks as follow:

--- binutils.spec.orig  2017-01-31 09:24:18.988130013 -0500
+++ binutils.spec       2017-01-31 09:25:38.975347558 -0500
@@ -22,7 +22,7 @@
 Summary: A GNU collection of binary utilities
 Name: %{?cross}binutils%{?_with_debug:-debug}
 Version: 2.26.1
-Release: 1%{?dist}
+Release: 1.2%{?dist}
 License: GPLv3+
 Group: Development/Tools
 URL: http://sources.redhat.com/binutils
@@ -263,6 +263,11 @@
     ;;
 esac
 
+case %{binutils_target} in x86_64*|i?86*|arm*|aarch64*)
+  CARGS="$CARGS --enable-targets=x86_64-pep"
+  ;;
+esac
+
 %if 0%{?_with_debug:1}
 CFLAGS="$CFLAGS -O0 -ggdb2 -Wno-error -D_FORTIFY_SOURCE=0"
 %define enable_shared 0
@@ -519,6 +524,9 @@
 %endif # %{isnative}
 
 %changelog
+* Tue Jan 31 2017 Konrad Rzeszutek Wilk <konrad.wilk@oracle.com> 2.26-1.1.2
+- Add PE support.
+
 * Mon Aug 15 2016 Nick Clifton <nickc@redhat.com> 2.26.1-1
 - Rebase on FSF binutils 2.26.1 release.
 - Retire: binutils-2.26-formatting.patch
  • rpmbuild -ba binutils.spec
  • cd ../RPMS/x86_64/
  • rpm -U binut*.rpm

In either way, you will have an xen.efi file.

Compiling under ARM

From: efi.html:

For arm64, the PE/COFF header is open-coded in assembly, so no toolchain support for PE/COFF is required. Also, the PE/COFF header co-exists with the normal Image format, so a single binary may be booted as an Image file or as an EFI application.

Booting Xen under EFI platform

There are two ways of booting Xen:

  • From the EFI platform - which shows up in BIOS boot menu.
  • Using an bootloader (such as GRUB2)

Xen as EFI binary (loading)

Xen.efi as an EFI binary can be executed by the EFI firmware immediately. As the firmware does not provide an command line (nor would you want to have it), Xen expects an configuration file to tell it what initial domain (and ramdisk) to load afterwards. This configuration file must reside in the same directory as the xen.efi. Also the payloads (vmlinuz and ramdisk) MUST also reside in said directory.

The boot mechanism is simple:

EFI firmware => Xen.efi [loads vmlinuz and ramdisk and executes vmlinuz]

To install it please follow these directions:

  • sudo mkdir /boot/efi/EFI/xen
  • sudo cp /boot/vmlinuz* /boot/efi/EFI/xen
  • sudo cp /boot/initr* /boot/efi/EFI/xen/

[Both the Linux kernel and initramdisk MUST reside in the same directory as xen.efi]

  • sudo cp /boot/xen/xen.efi /boot/efi/EFI/xen
  • Create the xen.cfg file:
cat << EOF > /boot/efi/EFI/xen/xen.cfg
global]
default=ubuntu

[ubuntu]
options=console=vga,com1 com1=115200,8n1 iommu=verbose ucode=scan flask=disabled conring_size=2097152  loglvl=all
kernel=vmlinuz-4.8.0-41-generic root=UUID=3f1e35fb-9907-48d1-b621-42369d5ad88f ro quiet vt.handoff=7 console=hvc0
ramdisk=initrd.img-4.8.0-41-generic

[fedora]
options=console=vga,com1 com1=115200,8n1 iommu=verbose ucode=scan flask=disabled conring_size=2097152  loglvl=all
kernel=vmlinuz-4.9.3-200.fc25.x86_64 root=/dev/mapper/fedora-root ro rd.lvm.lv=fedora/swap rd.lvm.lv=fedora/root console=hvc0 console=tty0
ramdisk=initramfs-4.9.3-200.fc25.x86_64.img

Make sure to modify the 'UUID' to match yours. You can find that from cat /proc/cmdline.

Also, modify the default to point to the right one.

Naturally the 'vmlinuz' and 'initramfs' may differ. Double-check that please.

  • Add the xen.efi to the EFI boot manager:
efibootmgr -w -L Xen -l "\EFI\Xen\xen.efi" -c

which will produce a new boot target (for example):

[root@localhost EFI]# ls /boot/efi/EFI/Xen
vmlinuz-4.9.3-200.fc25.x86_64 initramfs-4.9.3-200.fc25.x86_64.img  xen.cfg  xen.efi
[root@localhost Xen]# efibootmgr -w -L Xen -l "\EFI\Xen\xen.efi" -c
BootCurrent: 0000
Timeout: 0 seconds
BootOrder: 0005,0001,0002,0003,0004,0000
Boot0000* Fedora
Boot0001* UEFI: ASUS    DRW-24B1ST
Boot0002* CD/DVD Drive 
Boot0003* Hard Drive 
Boot0004* Network Card 
Boot0005* Xen

Xen as gz binary

GRUB2 loader when built as an EFI binary can load various OS-es. The most common one is Linux where it uses the linuxefi GRUB module. However GRUB2 also has support for multiboot protocol which is what Xen uses. Sadly v1 of multiboot API does not have enough data to provide information to Xen under the EFI platform.

GRUB 2.02 has also support for 'multiboot2' which can pass the EFI ImageHandler to the underlaying payload. This allows:

EFI firmware => GRUB2.EFI -> multiboot2 -> [xen.gz, vmlinuz, ramdisk]

And GRUB2 would be responsible for reading from the ESP the various files and loading them in the memory.

Xen 4.9 and later implements both multiboot and multiboot2. Prior versions only implemented multiboot.

If you are using an older version you can use the GRUB2 chainloader workaround. Example:

menuentry "Xen EFI" {
    insmod part_gpt
    insmod search_fs_uuid
    insmod chain
    chainloader (hd0,gpt1)/EFI/XEN/xen.efi
}

To build GRUB2 from scratch and utilize it please follow these instructions:

[It will install the files in /usr/local so won't conflict with the installed version]

  • sudo mkdir -p /usr/local/etc/default
  • Setup an default GRUB entries:
cat << EOF > /usr/local/etc/default/grub
GRUB_DEFAULT=0
GRUB_TIMEOUT=10
GRUB_CMDLINE_LINUX="console=hvc0 loglevel=8 initcall_debug"
GRUB_CMDLINE_XEN="loglvl=all guest_loglvl=all console=com1,vga com1=115200,8n1"
GRUB_TERMINAL=serial
GRUB_SERIAL_COMMAND="serial --speed=115200 --unit=0 --word=8 --parity=no --stop=1"
EOF

[This is optional]

  • sudo chmod 400 /usr/local/etc/grub.d/10_linux

[This is optional, but this way you will only have Xen entries]

  • Script to combine the different grub modules in one EFI file:
cat << EOF > $HOME/build-grub
#!/bin/bash                                                                                                                         

GRUB_MODULES="  all_video boot btrfs cat chain configfile echo \
                efifwsetup efinet ext2 fat font gfxmenu gfxterm gzio halt \
                hfsplus iso9660 jpeg loadenv loopback lvm mdraid09 mdraid1x \
                minicmd normal part_apple part_msdos part_gpt \
                password_pbkdf2 png \
                reboot search search_fs_uuid search_fs_file search_label \
                serial sleep syslinuxcfg test tftp video xfs \
               linux backtrace usb usbserial_common \
               usbserial_pl2303 usbserial_ftdi usbserial_usbdebug   multiboot multiboot2"

echo $GRUB_MODULES
./grub/grub-mkimage -v -O x86_64-efi -o grub2.efi -p /EFI/grub2 \
                -d grub/grub-core ${GRUB_MODULES}
EOF
  • chmod 755 $HOME/build-grub
  • $HOME/build-grub

[That creates the grub2.efi with 'multiboot2' support along with other modules]

  • sudo mkdir /boot/efi/EFI/grub2
  • sudo cp $HOME/grub2.efi /boot/efi/EFI/grub2
  • ./grub-mkconfig -o /boot/efi/EFI/grub2/grub.cfg

[Inspect the grub.cfg. Make sure that it has 'multiboot2' and 'module2' for Xen. You may need the patch titled: [PATCH] Use grub-file to figure out whether multiboot2 should be used for Xen.gz See [1]

  • sudo efibootmgr -w -L GRUB2 -l "\EFI\grub2\grub2.efi" -c

[To create an EFI boot manager 'GRUB2' entry]

And you are good to go.

Compatibility of UEFI Host Firmware, Xen and UEFI Runtime Services

On some devices with UEFI firmware that does not strictly conform to UEFI specifications, Xen may fail to boot when UEFI Runtime Services is enabled. The Xen command line option efi=no-rs can be used to disable UEFI Runtime Services, which may allow Xen to boot on some machines with non-compliant host UEFI firmware, at the cost of losing access to UEFI Runtime Services.

Ideally, such UEFI firmware non-compliance would be identified during OEM/ODM pre-release testing with Xen and other bare-metal hypervisors and operating systems. In practice, it is difficult to obtain UEFI firmware fixes for hardware devices that are already released. If you are unable to obtain compliant UEFI host firmware from your device OEM, Xen 4.13 provides an opt-in (expert) build-time config option (CONFIG_EFI_SET_VIRTUAL_ADDRESS_MAP=y) to improve compatibility between non-compliant UEFI host firmware, Xen and UEFI Runtime Services.

Boot compatibility was reportedly improved for the following devices, with variability between multiboot2 and xen.efi:

  • Thinkpad W540
  • Thinkpad X230, firmware 2.77
  • Thinkpad P52, firmware 1.25

Please update the above list with device make, model and firmware version.