Re: xen ovmf/uefi firmware does not save screen resolution

[Chuck Zmudzinski <brchuckz@xxxxxxxxxxxx>]

On 10/6/2022 9:38 AM, Liberalia Tempus, S.L. wrote:
> Thank you very much for your answers.
>
> Finally, after trying some of the solutions proposed by Chuck, I have 
> made the decision to delete the UEFI partition and move it to a normal 
> MBR system.

Did you know you can keep the GPT partitions and the EFI partition and boot HVM 
guests
using MBR (seabios) with a GPT BIOS Boot partition present in the guest's 
virtual boot disk?
I implemented that by stealing the last 1 MB of the EFI GPT partition and 
assigned that 1 MB
to be a BIOS boot GPT partition, and grub2 is smart enough to install its own 
MBR bootcode
into that partition and it works fine in Xen HVMs by using seabios instead of 
ovmf as the
firmware/bios for the guest in the xl.cfg guest configuration file. But that's 
not necessary if
you are going to give up on using the EFI partition and GPT partitions and go 
back to the
legacy MBR partitioning scheme. What you are doing is a sensible option also 
given Xen's
current lack of support for UEFI booting of Xen HVM guests that actually works.

> I think it's too cumbersome all this xen and UEFI booting stuff and 
> there's no point in spending more time on it. At the end of the day what 
> matters in a virtual environment is that the machine works, regardless 
> of the system used to boot.
> As of today, UEFI booting does not work properly in xen/qemu, at least 
> not for people who are not experts in xen code.
> Best regards.
>
> PS: Chuck, what you say about version 4.14 I have not been able to apply 
> in a vm with windows 10. It seems to work with a hvm vm with linux, but 
> not with a windows vm.

That may be true, because I have only tried UEFI booting of a Linux HVM guest. 
I have always
used MBR booting of Windows HVM guests with either the stdvga Qemu emulated 
graphics
device as the Windows HVM guest's primary graphics device or VGA passthrough of 
the Intel
IGD graphics device to the HVM Windows guest as the guest's primary graphics 
device.

I will in the meantime try to get UEFI booting working for both Windows and 
Linux HVM guests
for the future and at the same time use the BIOS boot GPT partition hack to 
give me the option to
use MBR booting with seabios instead of ovmf as the firmware/bios for the HVM 
guest until
Xen works well enough with UEFI booting of HVM guests. Obviously the MBR 
technology is legacy
tech and Xen needs to eventually be updated to support the UEFI booting method 
of HVM guests
going forward. I am not aware of much work in this area being done by the Xen 
developers, but
I am not subscribed to xen-devel so I could be wrong about that and I would 
welcome any
Xen developer who could explain to Xen users what work is being done to support 
UEFI booting
of Xen HVM guests in the future.

Best regards,

Chuck

>
> -------------------------
> MhBeyle __
> > Date: Thu, 22 Sep 2022 11:25:41 -0400
> > From: Chuck Zmudzinski <brchuckz@xxxxxxxxxxxx>
> >
> >
> > On 9/22/2022 4:37 AM, mhbeyle@xxxxxxxx wrote:
> >> Thanks for the answers.
> >>
> >> Chuck, I tried at the time to apply suggested patches to the software
> >> with no results. It is not clear that any of the current patches solve
> >> the problem.
> >>
> >> I think there are two problems here: One, the virtual machine that
> >> creates xen uses QEMU and the UEFI bios is not able to communicate the
> >> resolution data to the system. Two, this kind of problem would be easily
> >> solved by virtualizing a more modern vga instead of the current cards
> >> (cirrus etc.)
> > Actually, this might be a bug in Xen 4.16 that was not in Xen 4.14.
> >
> > On Debian 11 (bullseye/stable for Dom0) booting HVM with Tiano Core
> > UEFI works for me using vga = stdvga and videoram = 16:
> >
> > With Debian 11.x stable for dom0, the Xen version is 4.14 and the Qemu
> > version is a bit old, 5.2, but booting with ovmf/uefi works:
> >
> > I boot Debian 11.x (stable) in a Xen HVM using ovmf using vga = stdvga in 
> > the
> > xl.cfg and it seems to work in a VNC window. I can get 1920x1080 resolution
> > (with videoram = 16 in the xl.cfg), but this only works on Debian stable 
> > dom0
> > with Xen version 4.14.x and Qemu version 5.1 (haven't checked if Debian
> > backported Qemu version 7.0 for Debian 11 also works).
> >
> > After login, use the gnome display settings and it gives the option of up
> > to 1920x1080 resolution with videoram = 16. I presume KDE, XFCE, MATE, etc.
> > also would allow this.
> >
> > It is true the Tiano Core UEFI boot configuration setup screen and the grub
> > screen resolution is low (I think only 800x600) at the beginning of booting.
> >
> > Here is my xl config for ovmf (UEFI booting with vga = stdvga, videoram = 
> > 16)
> > and a VNC display and Debian stable with Xen 4.14.x dom0 and Qemu 5.2 in
> > dom0 on Debian stable:
> >
> > --- domain configuration file ---
> > builder = 'hvm'
> > bios = 'ovmf'
> > memory = '6144'
> > vcpus = '4'
> > disk = ['/dev/linux/bullseye,,xvda,w']
> > name = 'bullseye-hvm'
> > vif = [ 'mac=<redacted>,type=vif,script=vif-route,ip=<redacted>' ]
> > on_poweroff = 'destroy'
> > on_reboot = 'restart'
> > on_crash = 'restart'
> > boot = 'c'
> > acpi = '1'
> > apic = '1'
> > viridian = '1'
> > xen_platform_pci = '1'
> > serial = 'pty'
> > vga = 'stdvga'
> > videoram = '16'
> > sdl = '0'
> > vnc = '1'
> > vnclisten = '0.0.0.0'
> > vncdisplay = '1'
> > usb = '1'
> > usbdevice = 'tablet'
> > --- End of domain configuration file ---
> >
> > But the same configuration with Xen 4.16 and Qemu 7.1 in dom0 that is in 
> > Debian
> > unstable, and also in Fedora 36 with Xen 4.16 and Qemu 6.2 I think, I get a 
> > crash at
> > boot - it does show the Tiano Core configuration screen and grub screen at 
> > 800x600
> > resolution but crashes soon after. When trying to boot Fedora 36 in a Xen 
> > HVM with
> > ovmf, I got this in the journal of the guest:
> >
> > xen-qemu-system-i386: relocate_memory 4096 pages from GFN bf000 to GFN 
> > c1000 failed: Invalid argument
> >
> > Also, with a good boot (using seabios) I get this in the journal of the 
> > guest,
> > but is missing from the boot that crashes:
> >
> > fedora kernel: BIOS-e820: [mem 0x00000000fc000000-0x00000000fcffffff] 
> > reserved
> >
> > The size of this missing entry is 4096 pages, which is probably what Qemu 
> > is trying to
> > relocate but cannot with ovmf/uefi boot because it is missing. 4096 pages 
> > is 16 MB,
> > which is probably the video shared memory.
> >
> > This is probably a bug/regression in Xen somewhere between Xen 4.14 and 4.16
> > and I will try to bisect it when I have time.
> >
> > Best regards,
> >
> > Chuck
> >
> >> that are not recognized by the operating system when using
> >> UEFI and do not load specific drivers. For example, the problem is
> >> solved using qxl and a driver in Windows, but the qxl development is not
> >> complete and fails.
> >>
> >> With limitations, it seems that the problem in QEMU is solved by
> >> changing the parameters in the BIOS and doing a warm/soft reboot. I
> >> don't know why, this can't be done in xen. The settings are never saved
> >> and the reboot, at least in windows 10, is always a cold one (xen
> >> destroys the virtual machine and recreates it. The soft reboot parameter
> >> hangs the vm).
> >>
> >> Regards.
> >>
> >> __________
> >> MhBeyle ___
> >>
> >>
> >>
> >
>
>