On Thu, 17 Aug 2023 15:29:29 -0700 Elliott Mitchell
<ehem+deb...@m5p.com> 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
