Xen Ovmf/UEFI HVM error after upgrade to Debian Bookworm (was: xen ovmf/uefi firmware does not save screen resolution)

[Paul Leiber <paul@xxxxxxxxxxxxxxxx>]

On 14/02/2023 8:31 AM, Chuck Zmudzinski wrote:
> I am adding this information to complete the discussion of this
> problem I reported several months ago:
>
> I discovered the cause of the problems of ovmf/uefi booting with more 
> recent Xen
> versions - it is not a bug in Xen, but the problem occurs because
> newer versions
> of ovmf do not have Xen support in the OvmfPkgX64 target from edk2 
and > the
> Xen support is only available from the Xen-specific OvmfXen target
> from edk2.
>
> The problem is discussed here on the Arch Linux forums:
>
> https://bbs.archlinux.org/viewtopic.php?pid=2012659#p2012659
>
> The last version that had the Xen support in the OvmfPkgX64 target was
> edk2-stable202105, so for newer versions it is necessary to build and 
> use the
> Xen-specific OVMF.fd firmware target to boot properly on Xen.
>
> After building using 'OvmfPkg/build.sh -p OvmfPkg/OvmfXen.dsc' as
> explained
> here:
>
> https://lore.kernel.org/all/20190813113119.14804-1-
> anthony.perard@xxxxxxxxxx/
>
> from the edk2 source at https://github.com/tianocore/edk2 and using
> the
> resulting
> OVMF.fd firmware target with Xen support to boot the Xen HVM guest,
> the guest
> works properly with versions of ovmf edk2-stable202108 and newer.
>
> Unfortunately distros such as Debian and Fedora don't provide the Xen 
> specific
> target in their ovmf packages, so it is necessary to build it from
> source for
> ovmf
> versions of edk2-stable202108 and newer.

Thanks a lot for posting this, Chuck! It seems that I have run into this 
situation after upgrading from Debian Bullseye to Debian Bookworm. With 
standard packages, existing HVM DomUs using "firmware = 'ovmf'" (Windows 
Server 2022 and Windows 10) can't boot anymore. Booting these systems 
leads to the Windows error 0xc0000225. I wasn't able to fix this error. 
Booting an installation .iso leads to the same error. Booting the 
installation media with "firmware = 'bios'" leads to a normal boot.
I tried building Ovmf following
https://lore.kernel.org/all/20190813113119.14804-1-anthony.perard@xxxxxxxxxx/#t 
, but I wasn't fully able to create a working system:
(1) Using the resulting OVMF.fd from the build process with "firmware =
'/path/to/new/OVMF.fd' led consistently to a black screen in VNC or
Spice with the text "Guest has not initialized the display (yet)".

(2) Replacing the OVMF.fd in /var/lib/ovmf with the freshly built
OVMF.fd led to a slight improvement. I could then boot the Windows
Server installation .iso, but booting the Windows 10 installation .iso
lead to a crash where the TianoCore logo was visible, but nothing
happened. The two existing DomUs were still not bootable. When trying to
boot any of them, in Ovmf log appears an error "FATAL ERROR - RaiseTpl
with OldTpl(0x1F) > NewTpl(0x10)".

However, I am not sure that I followed the procedure correctly, I might
very well have done something very wrong. Any pointers are welcome.

My HVM config file:

type = "hvm"
memory = 6144
vcpus = 2
name = "kalliope"
firmware = 'ovmf'
firmware = '/usr/local/lib/ovmf/OVMF.fd'
vif = ['bridge=xenbr0,mac=XX:XX:XX:XX:XX:XX,ip=10.0.0.4']
disk = ['phy:/dev/vg0/matrix,hda,w']
device_model_version = 'qemu-xen'
hdtype = 'ahci'
pae = 1
acpi = 1
apic = 1
vga = 'stdvga'
videoram = 16
xen_platform_pci = 1
vendor_device = 'xenserver'
viridian = 1
on_crash = 'restart'
device_model_args_hvm = [
  # Debug OVMF
  '-chardev', 'file,id=debugcon,path=/var/log/xen/ovmf.log,',
  '-device', 'isa-debugcon,iobase=0x402,chardev=debugcon',
]
sdl = 0
serial = 'pty'
vnc = 1
vnclisten = "0.0.0.0"
vncpasswd = ""


There is a Debian bug report which seems to be related, I also described 
my situation there: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=978595
Paul