Created attachment 1944663 [details]
Patch to add OvmfXen platform to edk2-ovmf

Created attachment 1944663 [details]
Patch to add OvmfXen platform to edk2-ovmf

Description of problem:

The Fedora xen component depends on the edk2-ovmf package to provide uefi firmware to boot a Xen HVM guest:

https://src.fedoraproject.org/rpms/xen/blob/06e1d41034b24e4279b51d9f792c049ce0b13404/f/xen.spec#_182

AFAICT, the last version of edk2 provided by Fedora that has Xen support is edk2-ovmf-20210527gite1999b264f1f-2.fc35.noarch.rpm, released on July 21, 2021. This is because Xen support was removed from the OvmfPkgX64 platform starting with upstream version edk2-stable202108 and moved to a new OvmfXen platform as discussed here

https://bugzilla.tianocore.org/show_bug.cgi?id=2122

and the Fedora edk2 component never accounted for this change. That is, the Fedora edk2 component now provides firmware for the Fedora xen component that lacks Xen support!

The result is that the file that is shipped by Fedora in the xen component (specifically, the /usr/libexec/xen/boot/ovmf.bin file in the xen-runtime package) no longer functions correctly when using it to boot a Xen HVM guest with the bios = 'ovmf' option set in the libxl xl.cfg domain configuration file. Xen HVM guests configured to boot using legacy BIOS provided by seabios instead of using the UEFI firmware provided by the edk2-ovmf package are not affected, so the workaround is to use older legacy BIOS instead of UEFI BIOS for Xen HVM guests until this problem is fixed.

Version-Release number of selected component (if applicable):

All releases of edk2 with upstream version 202108 and later are affected.

AFAICT, all releases of the edk2-ovmf package for Fedora 36 and 37 are affected (probably also 38 and rawhide, but I have not tested those), and this in turn affects all Fedora 36 and 37 releases of the xen-runtime package that ship ovmf firmware based on a build that lacks support for Xen, so I would classify this bug as a regression that most likely appeared in an update to the Fedora 35 xen-runtime package when Fedora started shipping edk2-ovmf versions of firmware that lack Xen support.

How reproducible:

Always, but manifests differently with different guest configurations. Sometimes the guest will endlessly crash and reboot, other times, such as when the guest boots a Fedora Live disk image, the guest hangs with a message stating that the guest has not yet initialized the display. Of course it will not work correctly when the Xen support has been removed!

Steps to Reproduce:
1. Install the xen component if not already installed.
2. Reboot Fedora 36 or 37 (or rawhide, probably) as dom0 on the Xen hypervisor package provided by the Fedora xen component if not already running Fedora as Xen dom0.
3. Download a Fedora Live iso file and configure a guest to boot it in a Xen HVM using the bios = 'ovmf' option in the xen libxl domain configuration file. I tested using the vga = 'stdvga' Qemu video driver and the vnc display options in the libxl domain configuration file and connected to the guest using a vnc viewer.

Actual results:

The guest hangs indefinitely, with a message stating the guest has not initialized the display yet. Neither the Tiano Core boot screen is displayed nor the grub boot menu is displayed, and the only way to stop the guest is to destroy it with the 'xl destroy' command (or 'virsh destroy' if using libvirt as frontend to libxl).

Expected results:

The Tiano core screen and then the grub menu should display and allow the user to boot the Fedora Live disk and test Fedora live out and optionally install Fedora to a virtual hard disk in a Xen HVM that uses the ovmf firmware.

Additional info:

I verified that by adding a build of the OvmfXen platform to the edk2 SRPM and using the resulting firmware with Xen support in place of the firmware that the xen-runtime package currently provides fixes this problem and results in a guest that can boot the Fedora Live disk and other Linux domains in a Xen HVM using UEFI firmware provided by the edk-ovmf Tiano Core project.

I have attached a patchfile against a recent SRPM for Fedora 37 of the edk2 component as a way to provide Xen support once again in the edk2-ovmf package.

Also, here is a sample xl domain configuration file suitable for reproducing the bug:

With this configuration, the guest display can be
viewed by connecting to any IPv4 address of the dom0
with a vnc viewer on port 5901.

[chuckz@fedora ~]$ cat test.cfg
builder = 'hvm'
bios = 'ovmf'
memory = '3072'
vcpus = '4'
disk = ['/home/user/Downloads/Fedora-Workstation-Live-x86_64-37-1.7.iso,,xvdc,cdrom']
name = 'fedora-live'
vif = [  ]
on_poweroff = 'destroy'
on_reboot = 'restart'
on_crash = 'restart'
boot = 'd'
acpi = '1'
apic = '1'
viridian = '1'
xen_platform_pci = '1'
serial = 'pty'
vga = 'stdvga'
videoram = '16'
vnc = '1'
vnclisten = '0.0.0.0'
vncdisplay = '1'
usb = '1'
usbdevice = 'tablet'
-----end of config file ------

A trivial patch to the xen.spec file would be needed to fix this problem after the OvmfXen platform firmware is added to the edk2-ovmf package to ensure the xen-runtime package ships the firmware file that has Xen support instead of shipping the firmware file that lacks Xen support.

Related Links:

https://bugzilla.tianocore.org/show_bug.cgi?id=2122
https://bbs.archlinux.org/viewtopic.php?id=269628