[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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



On 9/22/2022 11:25 AM, Chuck Zmudzinski wrote:
> 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 dom0:
>
> 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.

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.



 


Rackspace

Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.