Bug#978595: #978595 is looking higher priority
On Thu, 17 Aug 2023 15:29:29 -0700 Elliott Mitchell
wrote:
On Tue, Jul 04, 2023 at 11:56:39PM +0300, Michael Tokarev wrote:
> 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.
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.
On Tue, Jul 04, 2023 at 10:30:34PM +0200, Paul Leiber wrote:
> 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?
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.
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
Bug#978595: #978595 is looking higher priority
On Tue, Jul 04, 2023 at 11:56:39PM +0300, Michael Tokarev wrote:
> 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.
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.
On Tue, Jul 04, 2023 at 10:30:34PM +0200, Paul Leiber wrote:
> 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?
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.
--
(\___(\___(\__ --=> 8-) EHM <=-- __/)___/)___/)
\BS (| ehem+sig...@m5p.com PGP 87145445 |) /
\_CS\ | _ -O #include O- _ | / _/
8A19\___\_|_/58D2 7E3D DDF4 7BA6 <-PGP-> 41D1 B375 37D0 8714\_|_/___/5445
Bug#978595: #978595 is looking higher priority
On Tue, 4 Jul 2023 23:56:39 +0300 Michael Tokarev wrote: 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. 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
Bug#978595: #978595 is looking higher priority
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
Bug#978595: #978595 is looking higher priority
On Thu, 30 Sep 2021 15:00:45 -0700 Elliott Mitchell wrote: 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). It seems that I have run into this Problem(tm) 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 0xc225. 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.per...@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
