Could we get the OvmfPkg/OvmfXen.dsc and ArmVirtPkg/ArmVirtXen.dsc configurations be packaged and built? The methods presently available for booting VMs inside Xen on Debian are a bit oriented towards booting Linux. The UEFI in VM approach works better for booting non-Linux (say FreeBSD). Really need a virtual package name to share among the VM bootloaders, then need to add these to the wiki...
Since "help" has been added, but nothing else was sent I'm unsure what information is needed though I can guess a bit... I'm guessing the resultant packages would look quite similar to the qemu-efi package. Instead of the file "QEMU_EFI.fd" though I would expect the Tianocore build process to produce "XEN_EFI.fd". A VM on Xen would use a configuration file similar to xlexample.pvlinux, but the setting for "kernel" would be the path to the XEN_EFI.fd file. The resultant domain would boot the way Tianocore/EDK2 normally does, but instead have pv-Xen devices and use a UEFI bootloader. I suspect this would work for FreeBSD's normal bootloader, or loading a certain other OS inside Xen.
Apologies for being unclear - my intention in adding the tag was to signal that I'm open to it, but don't have the time/motivation to implement it at the moment. A merge request would be welcome, including updated documentation (README.Debian) and autopkgtests (if feasible). -dann
way.
The ARM version has turned out straightforward. If you add:
. ./edksetup.sh && build -b RELEASE -t $(EDK2_TOOLCHAIN) \
-a $(EDK2_HOST_ARCH) \
-p ArmVirtPkg/ArmVirtXen.dsc \
$(OVMF_COMMON_FLAGS)
echo output is Build/ArmVirtXen-AARCH64/RELEASE_GCC5/FV/XEN_EFI.fd
exit 1
At the start of the build-qemu-efi rule, the file referenced "XEN_EFI.fd"
will boot a Xen 4.14-ARM domain. Simply set 'kernel = "XEN_EFI.fd"' in
the domain .cfg file and things work.
I would suggest the package name "ovmf-xen-aarch64" and then have it
provide "xen-domu-bootloader" and "xen-domu-bootloader-aarch64". I don't
see much reason to have it on any architecture besides arm64.
I imagine this would work to load grub-efi-arm64. Other ARM OSes which
are compatible with UEFI BIOSes should nominally work. I was advised
even a particular OS from Redmond will boot in such a VM.
I'm presently trying to get OvmfXen.dsc operational. This is being a bit
more interesting.
I've already noticed a few issues during this process. Patches are
attached. First, there are several mild derivatives of Debian which are
close enough to build most packages. Some set $(DEB_VENDOR) distinctly
and this kills the build process.
Second, I needed to separate common bits and distinct bits of the
invocations of `edksetup.sh`. Moving the common bits nearer to the front
potentially allows turning them into a macro. Using "set -e; foo; bar"
is an odd shell construct, usually you want "foo && bar". With this
boiled down, I know the first line is now identical on every invocation.
Third, the use of `dd` seemed a bit odd in the build-qemu-efi rule. I
hope I'm not the only person who finds using `truncate` clearer.
And it always works. How do you come up with better ways to do things? Guaranteed you'll find a far superior approach within 30 seconds of sending the one you find acceptable. Replace patch 0001 with the attached.
Thanks Elliott! I marinated on that a while, and then realized what we probably should do is use the "closest parent" distro for which we have a key. Here's what I came up with: https://salsa.debian.org/qemu-team/edk2/-/commit/8b18ebfea08aa97f99a7010cb06ea536946fc1dc
I'm unsure how much of this is useful to you, but for reference I suggest taking a look at bug #776450. #776450 is similar to #978595, but for GRUB instead of EDK2. Hopefully that has some of the answers you need for #978595. I haven't seen OvmfXen.dsc being operational. My guess is it is meant to run in either PVH or HVM configurations. Those have been troublesome for me due to a bug I've been gifted with. If used in the appropriate situation I imagine it is quite capable.
According to what I've read from: https://github.com/tianocore/edk2/pull/1689 Xen support is being or has been moved from Tianocore configurations which had support, and into OvmfXen.dsc. I'm unsure how much of the Xen HVM environment is handled by Qemu versus Tianocore, but if the previous OVMF.fd drops support, adjustments will be needed. Being able to load other OSes in PVH would be nice. Having loading of other OSes in both HVM and PVH broken would be a Problem(tm).
Any chance of word on bug #978595? Small update from what I've learned elsewhere. Apparently upstream plans to merge Xen/x86 support into OVMF. At which point only ArmVirtXen.dsc might need a new package. I've gotten great results from the XEN_EFI.fd built from ArmVirtXen.dsc. One ends up with a very functional bootloader inside the VM.
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. As the Windows systems are not usable anymore, Xen is significantly reduced in functionality after the upgrade. Is this existing bug report the right place to file this, or should I open a new bug report? If this bug report is the right place, its priority should indeed be raised, at least to important (linux PVH DomUs are still working fine). If I should open a new bug report, for which package? Sidenote: A related bug report exists in https://bugzilla.redhat.com/show_bug.cgi?id=2170930 Paul
Out of curiocity, what value is it to boot a xen domU (or qemu) guest in uefi mode? I mean, bios mode is still recommended for at least commercial virt solutions such as vmware, and it works significantly faster in qemu and xen too. It is more, qemu ships minimal bios (qboot) to eliminate all boot-time cruft which is not needed in a vm most of the time. Thanks, /mjt
I personally didn't really give much thought to the choice of bootloader when setting up the DomU. If I had known back then what Michael has written now, I probably would have chosen BIOS instead. Perhaps this information about the advantages of BIOS bootloaders is something that should be added to the Xen wiki. AFAIU, things will change with Windows 11 VMs, as Windows 11 requires UEFI, unless you use some hacks. I use future tense, because Xen still lacks TPM 2.0 support. In the end, it shouldn't really matter IMHO, because as UEFI/Ovmf is an bootloader officially supported by Xen, and as it did work in Debian until the upgrade to Bookworm, I think the general expectation is that it should continue work in Debian Bookworm. The technical solution seems to be at hand (see the closed bug reports for Redhat and Fedora), at least for somebody who knows what he/she is doing (meaning that I often feel like poking with sticks at a nuclear reactor :-). Paul
First, the known high value portion of #978595 is getting
ArmVirtPkg/ArmVirtXen.dsc built and packaged. This results in a
XEN_EFI.fd file. As such the presently verified value only applies to
ARM.
What you do with XEN_EFI.fd is you configure an ARM domain with
'kernel = "${edk2_install_dir}/XEN_EFI.fd"'
The resultant domain has no extra daemons emulating hardware. Inside the
domain, Tianocore/EDK2 will search via its normal means for a boot.efi
file and load that if it can.
This is similar to PyGRUB versus PvGRUB. If the OS being loaded has
native Xen drivers, you've gotten rid of the Qemu process hanging around
in domain 0 providing security holes.
So far this is reliably booting the WIP FreeBSD/arm64. I imagine this
could also load GRUB.
I believe OvmfPkg/OvmfXen.dsc aims to be something similar for x86, but
I've yet to achieve results from that. My hope is this could load
FreeBSD/x86 in a PVH domain.
New report. The topic for #978595 is I was hoping for some other build
types of EDK2/Tianocore to be built and packaged. What you're describing
is a regression and certainly not merely a wishlist packaging request.
I'm unsure, but at first thought this would be src:xen. On that note a
FreeBSD VM I've got has been having difficulty since the 4.14 -> 4.17
upgrade. I'm still fighting other upgrade issues right now.
Some portions of the EDK2/Tianocore packaging look suspicious, so I
wouldn't be surprised if the failure was there.
On a very different note, I'm concerned about commit 5e68feec5b2. If you
would care to examine patch #3 attached to message #22 on bug 978595, you
will notice it bears a strong resemblance.
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=978595#22
https://bugs.debian.org/cgi-bin/bugreport.cgi?att=3;bug=978595;filename=0003-debian-rules-Switch-to-truncate-from-dd.patch;msg=22
I believe 5e68feec5b2 is simply parallel development (that was an ugly
use of `dd` and `truncate` is known). Yet I find it discouraging I
pointed to the issue more than a full 2 years earlier it was ignored.
On Thu, 17 Aug 2023 15:29:29 -0700 Elliott Mitchell <ehem+debian@m5p.com> wrote: As a test using a previous version of ovmf package (version 2020.11-2+deb11u1, which the DomU booted normally with) pointed to the bug being in ovmf, I filed the bug there: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1050030 Thanks for the assistance! Paul
I can confirm that the 2020 package from Debian 11 works with Xen, and that the 2022 package from Debian 12 is broken in interesting ways (I could start a <4G VM, but >= 4G vms instantly crashed). I tried to update the packaging to edk2 202502, but I ran into a bug in OVMF: https://github.com/tianocore/edk2/issues/11046 I have prepared an update to the src:edk2 package based off of the last working 202408 version of edk and posted the change to enable and build ovmf-xen here: https://github.com/byteit101/edk2-debian. Note that c2c08abb36224f5a6700f12e6a16c07ad33a3fa9 is the real change. I also added on top c7b34aae3d3d873af6d57ff1d952021331c3450e which is just a "build faster" commit for testing, and shouldn't be pulled by a Debian developer. With that tree built and installed, I was able to get all my HVM machines working by specifying: firmware='ovmf' system_firmware="/usr/share/ovmf/XEN_OVMF.fd" Presumably once a DD pulls this change, the Xen package will need the ovmf build flags updated to point to the new path.
I have pushed a new branch based on 202502 at my repo debian/xen-last here: https://github.com/byteit101/edk2-debian. Note that c2c08abb36224f5a6700f12e6a16c07ad33a3fa9 is the real change. I also added on top c7b34aae3d3d873af6d57ff1d952021331c3450e which is just a "build faster" commit for testing, and shouldn't be pulled by a Debian developer. With that tree built and installed, I was able to get all my HVM machines working by specifying: bios='ovmf' bios_path_override="/usr/share/ovmf/XEN_OVMF.fd"