[prev in list] [next in list] [prev in thread] [next in thread] 

List:       xen-users
Subject:    Re: Xen Ovmf/UEFI HVM error after upgrade to Debian Bookworm (was: xen ovmf/uefi firmware does not s
From:       Chuck Zmudzinski <brchuckz () netscape ! net>
Date:       2023-07-10 16:47:23
Message-ID: 83a94ee6-6fcd-204a-7b8d-b89858d7831d () netscape ! net
[Download RAW message or body]

On 7/4/2023 5:06 PM, Paul Leiber wrote:
> 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@citrix.com/#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
>

Hi Paul,

Your config looks OK to me, except that I have no pointers for a Windows guest.
I have a Windows HVM guest, but it uses BIOS / MBR instead of EFI / GPT so I
cannot easily reproduce your setup. I did not see any problems when using the
OVMF.fd file built for Xen in a bookworm dom0 according to Anthony's guide and
booting Linux HVM guests with EFI / GPT, so the problem might be that the graphics
for the Windows efi bootloader is not compatible with the efi implementation
that Xen uses (edk2 and Qemu with bochs vga) but the grub bootloader and
Linux graphics is compatible with the efi implementation for Xen HVM, but that is
just a guess.

Someone with more expertise about booting Windows in the Qemu / edk2 / bochs
environment might be able to shed more light on the error you are seeing with
some of your Windows guests. IIRC, I think there are some discussions of this
problem on Qemu or Xen or edk2 mailing lists in past years and you might try
searching those mailing lists for clues to the problem and patches that might
fix it.

Now, I have migrated my dom0 from Debian to Fedora since Fedora provides
an official ovmf-xen package now, but Debian still does not and I would have
to maintain it myself if I stayed with Debian.

Kind regards,

Chuck

[prev in list] [next in list] [prev in thread] [next in thread]