Copyright 2015 by Assured Information Security, Inc. Created by Jean-Edouard Lejosne <lejosnej@ainfosec.com>. This work is licensed under the Creative Commons Attribution 4.0 International License. To view a copy of this license, visit http://creativecommons.org/licenses/by/4.0/.

Status

Legacy BIOS boot of OpenXT on GPT works fine when using the steps described here. However, UEFI boot requires multiboot2 support (see below).

UEFI

To be compatible with UEFI firmwares, OpenXT needs a bunch of modifications.
The upgrade can be divided in two steps, first switching to the UEFI partition table, GPT (see next chapter), that is compatible with most legacy BIOSes. Once that's done, we can work on switching to UEFI. Here are a few components that will need to be updated, in boot order:

tboot

The latest version of tboot is supposedly completely compatible with UEFI. The upgrade is in progress.

Xen

The latest Xen, Xen 4.5, can be booted from UEFI, but only when built as an efi module.
This is not an option for us, as the UEFI doesn't start Xen in OpenXT. OpenXT uses multiboot to start tboot that will start Xen that will start dom0.
To properly support UEFI, we need multiboot2 support in Xen. There is a patch in the mailing list pending approval for a future version of Xen (4.7?).
The idea for now is to update to Xen 4.5, and add the pending patch to our patchqueue.

Installer

The OpenXT installer will have to be modified to create/update the disk to use GPT instead of MBR. More on that in the next section.

GPT

For a fresh install, we can just use gdisk instead of fdisk (there's an OpenEmbedded recipe for it upstream), and create a GPT "BIOS boot partition".
The upgrade case is more complicated.

The upgrade case

In case of an upgrade, the msdos partition table will have to be replaced by a GPT.
Theoretically, this is very easy, just run gdisk /dev/sda, write and exit (wq).

The practical case is more complicated...
GPT uses the beginning and the end of the disk to store metadata.
In general, there's enough free space at the beginning of the disk (i.e. before the first partition) for gdisk to store the GPT (otherwise, see "Head-shrink trick").
However, usually, the OpenXT LVM and partition are configured to span to the very end of the disk, leaving no room for the secondary GPT table (see "Tail-shrink trick").

Head-shrink trick

Luckily, even when the OpenXT partition starts at the very beginning of the disk, the LVM PV starts 2MB after.
The should move the partition 1MB forward, keeping the LVM PV at the same place on the disk, 1MB after the beginning of the partition:

Tail-shrink trick

Luckily again, the installer leaves around 1GB at the end of the LVM PV. We can reduce that and use the space for the GPT and the GPT "BIOS boot partition".

Grub

This section is about installing grub on a GPT (+ LVM) disk.
The only relevant subsection is the UEFI one, but as I found a way to boot in GPT + Legacy BIOS mode, I'm writing about it here.

Legacy BIOS

We currently install grub in a terrible way (see /usr/share/xenclient/install-bootloader).
We want to install grub the normal way, using grub-install.
Grub can be installed on a GPT. Grub can be installed on an LVM. But grub can't be installed on an GPT LVM. Therefore, we need to create a separate /boot partition, additionally to the BIOS system boot partition (EF02) when booting in legacy BIOS mode.
Once the disk is switched to GPT and the extra partition is created, just run in a chroot:
grub-install --root-directory=<path-to-mounted-boot-partition> /dev/sda
If the legacy BIOS refuses to boot to the disk at this point, try this:
parted /dev/sdX
disk_toggle pmbr_boot (Warning: That will break UEFI booting!)

UEFI

Grub doesn't need to be "installed" when using UEFI. The only thing to do is to create an EFI system partition (EF00) on the disk, format it in fat32 (vfat), and copy grub-efi there, in the standard path: /EFI/BOOT/BOOTX64.EFI.

References

This page is a GRUB gold mine:
https://wiki.archlinux.org/index.php/GRUB