Bug 2170730 - Regression: OvmfPkgX64 no longer supports Xen HVM
Summary: Regression: OvmfPkgX64 no longer supports Xen HVM
Keywords:
Status: CLOSED ERRATA
Alias: None
Product: Fedora
Classification: Fedora
Component: edk2
Version: 37
Hardware: x86_64
OS: Linux
unspecified
medium
Target Milestone: ---
Assignee: Paolo Bonzini
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2023-02-17 05:15 UTC by Chuck Zmudzinski
Modified: 2023-03-05 00:53 UTC (History)
8 users (show)

Fixed In Version: edk2-20221117gitfff6d81270b5-14.fc39 edk2-20221117gitfff6d81270b5-14.fc38 edk2-20221117gitfff6d81270b5-14.fc37 edk2-20221117gitfff6d81270b5-14.fc36
Doc Type: If docs needed, set a value
Doc Text:
Clone Of:
Environment:
Last Closed: 2023-02-17 17:16:54 UTC
Type: Bug
Embargoed:


Attachments (Terms of Use)
Patch to add OvmfXen platform to edk2-ovmf (2.66 KB, patch)
2023-02-17 05:15 UTC, Chuck Zmudzinski
no flags Details | Diff

Description Chuck Zmudzinski 2023-02-17 05:15:51 UTC
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

Comment 1 Gerd Hoffmann 2023-02-17 10:27:50 UTC
> 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.

Well, if xen goes combine code and vars into a single file anyway
(as noted in the patch) there is little reason to ship them.
We can just package OVMF.fd instead which xen can use directly,
and placing it in a separate sub-package which xen-runtime can
pull in as dependency probably makes sense too.

Comment 2 Gerd Hoffmann 2023-02-17 12:51:43 UTC
Test builds at https://copr.fedorainfracloud.org/coprs/kraxel/edk2.testbuilds/ now.

Comment 3 Chuck Zmudzinski 2023-02-17 14:17:51 UTC
> > 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.
> 
> Well, if xen goes combine code and vars into a single file anyway
> (as noted in the patch) there is little reason to ship them.
> We can just package OVMF.fd instead which xen can use directly,
> and placing it in a separate sub-package which xen-runtime can
> pull in as dependency probably makes sense too.

Yes, that is fine with me, I also tested the combined OVMF.fd file instead of
the combined file by concatenating the code and vars files (as the xen package
currently does) and it also fixes the bug. So unless there is a reason to ship
the code and vars files we can just ship OVMF.fd in the separate ovmf-xen
sub-package that xen-runtime can pull in as its build dependency.

Thanks for the quick response.

Comment 4 Chuck Zmudzinski 2023-02-17 15:27:00 UTC
(In reply to Chuck Zmudzinski from comment #3)
> > > 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.
> > 
> > Well, if xen goes combine code and vars into a single file anyway
> > (as noted in the patch) there is little reason to ship them.
> > We can just package OVMF.fd instead which xen can use directly,
> > and placing it in a separate sub-package which xen-runtime can
> > pull in as dependency probably makes sense too.
> 
> Yes, that is fine with me, I also tested the combined OVMF.fd file instead
> of the combined file by concatenating the code and vars files (as the xen
> package currently does) and it also fixes the bug. So unless there is a
> reason to ship the code and vars files we can just ship OVMF.fd in the
> separate ovmf-xen sub-package that xen-runtime can pull in as its build
> dependency.
> 

In fact, I think it would be appropriate to just make the new ovmf-xen
sub-package a Recommended dependency (not required because seabios,
not ovmf is still the default firmware for Xen) of the xen-runtime package
and configure Xen to use the OVMF.fd firmware from the ovmf-xen
sub-package directly instead of having the ovmf-xen sub-package as a
build dependency and installing the ovmf firmware for xen under
/usr/libexec/xen/boot/ovmf.bin.

So I inquire if that is OK with the xen packages maintainer (Michael
Young). Michael, what do you think?

Thanks.

Comment 5 Fedora Update System 2023-02-17 17:14:42 UTC
FEDORA-2023-951bd0eeaf has been submitted as an update to Fedora 39. https://bodhi.fedoraproject.org/updates/FEDORA-2023-951bd0eeaf

Comment 6 Fedora Update System 2023-02-17 17:16:54 UTC
FEDORA-2023-951bd0eeaf has been pushed to the Fedora 39 stable repository.
If problem still persists, please make note of it in this bug report.

Comment 7 Chuck Zmudzinski 2023-02-17 18:04:58 UTC
I am satisfied with the update to rawwhide, so clearing all needinfo requests.

Thanks!

Comment 8 Fedora Update System 2023-02-17 18:26:07 UTC
FEDORA-2023-d9a4db9d73 has been submitted as an update to Fedora 38. https://bodhi.fedoraproject.org/updates/FEDORA-2023-d9a4db9d73

Comment 9 Fedora Update System 2023-02-17 18:28:07 UTC
FEDORA-2023-d9a4db9d73 has been pushed to the Fedora 38 stable repository.
If problem still persists, please make note of it in this bug report.

Comment 10 Fedora Update System 2023-02-17 21:15:57 UTC
FEDORA-2023-06e4cf6b9f has been submitted as an update to Fedora 37. https://bodhi.fedoraproject.org/updates/FEDORA-2023-06e4cf6b9f

Comment 11 Fedora Update System 2023-02-17 21:53:37 UTC
FEDORA-2023-e821b64a4c has been submitted as an update to Fedora 36. https://bodhi.fedoraproject.org/updates/FEDORA-2023-e821b64a4c

Comment 12 Fedora Update System 2023-02-18 02:22:09 UTC
FEDORA-2023-e821b64a4c has been pushed to the Fedora 36 testing repository.
Soon you'll be able to install the update with the following command:
`sudo dnf upgrade --enablerepo=updates-testing --refresh --advisory=FEDORA-2023-e821b64a4c`
You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2023-e821b64a4c

See also https://fedoraproject.org/wiki/QA:Updates_Testing for more information on how to test updates.

Comment 13 Fedora Update System 2023-02-18 02:38:01 UTC
FEDORA-2023-06e4cf6b9f has been pushed to the Fedora 37 testing repository.
Soon you'll be able to install the update with the following command:
`sudo dnf upgrade --enablerepo=updates-testing --refresh --advisory=FEDORA-2023-06e4cf6b9f`
You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2023-06e4cf6b9f

See also https://fedoraproject.org/wiki/QA:Updates_Testing for more information on how to test updates.

Comment 14 Fedora Update System 2023-02-22 10:11:46 UTC
FEDORA-2023-06e4cf6b9f has been pushed to the Fedora 37 stable repository.
If problem still persists, please make note of it in this bug report.

Comment 15 Fedora Update System 2023-03-05 00:53:18 UTC
FEDORA-2023-e821b64a4c has been pushed to the Fedora 36 stable repository.
If problem still persists, please make note of it in this bug report.


Note You need to log in before you can comment on or make changes to this bug.