Mailing List Archive

xen ovmf/uefi firmware does not save screen resolution
Hello Xen users ...

I have a problem with a hvm domU that uses ovmf/uefi firmware ans loads a windows 10 SO.

When windows loads, screen resolution is always 800x600 mode and there is no possibility of switching to another one.
So I change resolution into UEFI bios (Tiano Core), save and restart with no change. Screen resolution is always the same, on boot loading and windows.

I have tried changing several settings in the configuration file (vga, videoram) with no results.

Screen resolution can be changed in Legacy BIOS mode.


Any idea what I need to look at? I am completely lost with this issue ..

Dom0 is running under Debian (5.10.0-17-amd64) and xen version is 4.14.5 (xen-3.0-x86_64).

Thank you very much in advance and best regards.

------------------
MhBeyle ___
Re: xen ovmf/uefi firmware does not save screen resolution [ In reply to ]
On 9/15/2022 10:55 AM, mhbeyle@yahoo.es wrote:
> Hello Xen users ...
>
> I have a problem with a hvm domU that uses ovmf/uefi firmware ans loads a windows 10 SO.
>
> When windows loads, screen resolution is always 800x600 mode and there is no possibility of switching to another one.
> So I change resolution into UEFI bios (Tiano Core), save and restart with no change. Screen resolution is always the same, on boot loading and windows.
>
> I have tried changing several settings in the configuration file (vga, videoram) with no results.
>
> Screen resolution can be changed in Legacy BIOS mode.
>
>
> Any idea what I need to look at? I am completely lost with this issue ..
>
> Dom0 is running under Debian (5.10.0-17-amd64) and xen version is 4.14.5 (xen-3.0-x86_64).
>
> Thank you very much in advance and best regards.
>
> ------------------
> MhBeyle ___

I think I have heard about this problem, but I am not sure what the answer is.
That is why I always use the Legacy BIOS mode with Xen HVM. Just speculating,
it might be because the Xen HVM device model, Qemu, has the part that
supports Xen HVM, but it emulates a very old type of PC, I think twenty-five
years old or something like that. The emulation if you use Qemu with
KVM instead of Xen is of a newer PC like only twelve years old or
so, when the all the PCs had UEFI. Just a thought about the reason.

I also don't know if Xen HVM with Qemu emulation works for a Windows
11 HVM. My guess is it would not, but maybe if the Xen developers fix that
by the time support for Windows 10 ends, they might also fix this problem
with the UEFI screen resolution because I think in Windows 11 UEFI is required
AFAIK.

The best chance might be for you to work on it and try to find a fix yourself.
It is not easy to find the technical information to do it, but if you start
experimenting and reading articles online about it you can learn how to do it.
Debian is a good platform for building the packages. You probably will want to
at least learn to build and test patches to Xen, Qemu, the Linux kernel, and ovmf
packages. It is a complicated problem because all those packages have to work
together nicely. Start by researching the technical specifications for UEFI, it
is quite different from legacy BIOS.

Best regards,

Chuck
Re: xen ovmf/uefi firmware does not save screen resolution [ In reply to ]
On 9/18/2022 11:52 PM, Chuck Zmudzinski wrote:
> On 9/15/2022 10:55 AM, mhbeyle@yahoo.es wrote:
> > Hello Xen users ...
> >
> > I have a problem with a hvm domU that uses ovmf/uefi firmware ans loads a windows 10 SO.
> >
> > When windows loads, screen resolution is always 800x600 mode and there is no possibility of switching to another one.
> > So I change resolution into UEFI bios (Tiano Core), save and restart with no change. Screen resolution is always the same, on boot loading and windows.
> >
> > I have tried changing several settings in the configuration file (vga, videoram) with no results.
> >
> > Screen resolution can be changed in Legacy BIOS mode.
> >
> >
> > Any idea what I need to look at? I am completely lost with this issue ..
> >
> > Dom0 is running under Debian (5.10.0-17-amd64) and xen version is 4.14.5 (xen-3.0-x86_64).
> >
> > Thank you very much in advance and best regards.
> >
> > ------------------
> > MhBeyle ___
>
> I think I have heard about this problem, but I am not sure what the answer is.
> That is why I always use the Legacy BIOS mode with Xen HVM. Just speculating,
> it might be because the Xen HVM device model, Qemu, has the part that
> supports Xen HVM, but it emulates a very old type of PC, I think twenty-five
> years old or something like that. The emulation if you use Qemu with
> KVM instead of Xen is of a newer PC like only twelve years old or
> so, when the all the PCs had UEFI. Just a thought about the reason.
>
> I also don't know if Xen HVM with Qemu emulation works for a Windows
> 11 HVM. My guess is it would not, but maybe if the Xen developers fix that
> by the time support for Windows 10 ends, they might also fix this problem
> with the UEFI screen resolution because I think in Windows 11 UEFI is required
> AFAIK.
>
> The best chance might be for you to work on it and try to find a fix yourself.
> It is not easy to find the technical information to do it, but if you start
> experimenting and reading articles online about it you can learn how to do it.
> Debian is a good platform for building the packages. You probably will want to
> at least learn to build and test patches to Xen, Qemu, the Linux kernel, and ovmf
> packages. It is a complicated problem because all those packages have to work
> together nicely. Start by researching the technical specifications for UEFI, it
> is quite different from legacy BIOS.
>
> Best regards,
>
> Chuck
>

Just a couple of more tips on working on this problem using Debian. I would recommend
using Debian unstable instead of Debian stable, so that you can be working on the
latest versions of the upstream packages. There also was a patch set proposed for
Qemu and Xen to update the emulation to the same type of PC that Qemu uses
with KVM over four years ago, and it was discussed on xen-devel but never made
it into Xen and Qemu. These patches and the discussions there would probably
be helpful:

https://lists.xenproject.org/archives/html/xen-devel/2018-03/msg01176.html

I am not sure if this problem is fixed on KVM/Qemu, but I would definitely check and see,
and if so, the KVM solution can guide your work on patching Xen and Qemu to fix this.

Best regards,

Chuck
Re: xen ovmf/uefi firmware does not save screen resolution [ In reply to ]
Am 19.09.22 um 18:03 schrieb Chuck Zmudzinski:
> On 9/18/2022 11:52 PM, Chuck Zmudzinski wrote:
>> On 9/15/2022 10:55 AM, mhbeyle@yahoo.es wrote:
>>> Hello Xen users ...
>>>
>>> I have a problem with a hvm domU that uses ovmf/uefi firmware ans loads a windows 10 SO.
>>>
>>> When windows loads, screen resolution is always 800x600 mode and there is no possibility of switching to another one.
>>> So I change resolution into UEFI bios (Tiano Core), save and restart with no change. Screen resolution is always the same, on boot loading and windows.
>>>
>>> I have tried changing several settings in the configuration file (vga, videoram) with no results.
>>>
>>> Screen resolution can be changed in Legacy BIOS mode.
>>>
>>>
>>> Any idea what I need to look at? I am completely lost with this issue ..
>>>
>>> Dom0 is running under Debian (5.10.0-17-amd64) and xen version is 4.14.5 (xen-3.0-x86_64).
>>>
>>> Thank you very much in advance and best regards.
>>>
>>> ------------------
>>> MhBeyle ___
>>
>> I think I have heard about this problem, but I am not sure what the answer is.
>> That is why I always use the Legacy BIOS mode with Xen HVM. Just speculating,
>> it might be because the Xen HVM device model, Qemu, has the part that
>> supports Xen HVM, but it emulates a very old type of PC, I think twenty-five
>> years old or something like that. The emulation if you use Qemu with
>> KVM instead of Xen is of a newer PC like only twelve years old or
>> so, when the all the PCs had UEFI. Just a thought about the reason.
>>
>> I also don't know if Xen HVM with Qemu emulation works for a Windows
>> 11 HVM. My guess is it would not, but maybe if the Xen developers fix that
>> by the time support for Windows 10 ends, they might also fix this problem
>> with the UEFI screen resolution because I think in Windows 11 UEFI is required
>> AFAIK.
>>
>> The best chance might be for you to work on it and try to find a fix yourself.
>> It is not easy to find the technical information to do it, but if you start
>> experimenting and reading articles online about it you can learn how to do it.
>> Debian is a good platform for building the packages. You probably will want to
>> at least learn to build and test patches to Xen, Qemu, the Linux kernel, and ovmf
>> packages. It is a complicated problem because all those packages have to work
>> together nicely. Start by researching the technical specifications for UEFI, it
>> is quite different from legacy BIOS.
>>
>> Best regards,
>>
>> Chuck
>>
>
> Just a couple of more tips on working on this problem using Debian. I would recommend
> using Debian unstable instead of Debian stable, so that you can be working on the
> latest versions of the upstream packages. There also was a patch set proposed for
> Qemu and Xen to update the emulation to the same type of PC that Qemu uses
> with KVM over four years ago, and it was discussed on xen-devel but never made
> it into Xen and Qemu. These patches and the discussions there would probably
> be helpful:
>
> https://lists.xenproject.org/archives/html/xen-devel/2018-03/msg01176.html
>
> I am not sure if this problem is fixed on KVM/Qemu, but I would definitely check and see,
> and if so, the KVM solution can guide your work on patching Xen and Qemu to fix this.
>
> Best regards,
>
> Chuck
>

I encountered this problem two years ago. I suspected a problem with
Qemu and reported it on a mailing list, but never got a response:

https://lists.nongnu.org/archive/html/qemu-discuss/2020-09/msg00010.html

Best regards.
Stefan
Re: xen ovmf/uefi firmware does not save screen resolution [ In reply to ]
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.) 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 ___


El 21/09/2022 a las 14:00, xen-users-request@lists.xenproject.org escribió:
> Message: 1
> Date: Mon, 19 Sep 2022 19:12:57 +0200
> From: Stefan Kadow <pub@ska67.de>
> To: xen-users@lists.xenproject.org
> Subject: Re: xen ovmf/uefi firmware does not save screen resolution
> Message-ID: <aea59c2c-e4d4-15d1-c328-2d3febc7639b@ska67.de>
> Content-Type: text/plain; charset=UTF-8; format=flowed
>
> Am 19.09.22 um 18:03 schrieb Chuck Zmudzinski:
>> On 9/18/2022 11:52 PM, Chuck Zmudzinski wrote:
>>> On 9/15/2022 10:55 AM, mhbeyle@yahoo.es wrote:
>>>> Hello Xen users ...
>>>>
>>>> I have a problem with a hvm domU that uses ovmf/uefi firmware ans
>>>> loads a windows 10 SO.
>>>>
>>>> When windows loads, screen resolution is always 800x600 mode and
>>>> there is no possibility of switching to another one.
>>>> So I change resolution into UEFI bios (Tiano Core), save and
>>>> restart with no change. Screen resolution is always the same, on
>>>> boot loading and windows.
>>>>
>>>> I have tried changing several settings in the configuration file
>>>> (vga, videoram) with no results.
>>>>
>>>> Screen resolution can be changed in Legacy BIOS mode.
>>>>
>>>>
>>>> Any idea what I need to look at? I am completely lost with this
>>>> issue ..
>>>>
>>>> Dom0 is running under Debian (5.10.0-17-amd64) and xen version is
>>>> 4.14.5 (xen-3.0-x86_64).
>>>>
>>>> Thank you very much in advance and best regards.
>>>>
>>>> ------------------
>>>> MhBeyle ___
>>> I think I have heard about this problem, but I am not sure what the
>>> answer is.
>>> That is why I always use the Legacy BIOS mode with Xen HVM. Just
>>> speculating,
>>> it might be because the Xen HVM device model, Qemu, has the part that
>>> supports Xen HVM, but it emulates a very old type of PC, I think
>>> twenty-five
>>> years old or something like that. The emulation if you use Qemu with
>>> KVM instead of Xen is of a newer PC like only twelve years old or
>>> so, when the all the PCs had UEFI. Just a thought about the reason.
>>>
>>> I also don't know if Xen HVM with Qemu emulation works for a Windows
>>> 11 HVM. My guess is it would not, but maybe if the Xen developers
>>> fix that
>>> by the time support for Windows 10 ends, they might also fix this
>>> problem
>>> with the UEFI screen resolution because I think in Windows 11 UEFI
>>> is required
>>> AFAIK.
>>>
>>> The best chance might be for you to work on it and try to find a fix
>>> yourself.
>>> It is not easy to find the technical information to do it, but if
>>> you start
>>> experimenting and reading articles online about it you can learn how
>>> to do it.
>>> Debian is a good platform for building the packages. You probably
>>> will want to
>>> at least learn to build and test patches to Xen, Qemu, the Linux
>>> kernel, and ovmf
>>> packages. It is a complicated problem because all those packages
>>> have to work
>>> together nicely. Start by researching the technical specifications
>>> for UEFI, it
>>> is quite different from legacy BIOS.
>>>
>>> Best regards,
>>>
>>> Chuck
>>>
>> Just a couple of more tips on working on this problem using Debian. I
>> would recommend
>> using Debian unstable instead of Debian stable, so that you can be
>> working on the
>> latest versions of the upstream packages. There also was a patch set
>> proposed for
>> Qemu and Xen to update the emulation to the same type of PC that Qemu
>> uses
>> with KVM over four years ago, and it was discussed on xen-devel but
>> never made
>> it into Xen and Qemu. These patches and the discussions there would
>> probably
>> be helpful:
>>
>> https://lists.xenproject.org/archives/html/xen-devel/2018-03/msg01176.html
>>
>> I am not sure if this problem is fixed on KVM/Qemu, but I would
>> definitely check and see,
>> and if so, the KVM solution can guide your work on patching Xen and
>> Qemu to fix this.
>>
>> Best regards,
>>
>> Chuck
>>
> I encountered this problem two years ago. I suspected a problem with
> Qemu and reported it on a mailing list, but never got a response:
>
> https://lists.nongnu.org/archive/html/qemu-discuss/2020-09/msg00010.html
>
> Best regards.
> Stefan
>
>
>
>
Re: xen ovmf/uefi firmware does not save screen resolution [ In reply to ]
On 9/22/2022 4:37 AM, mhbeyle@yahoo.es 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 ___
>
>
>
Re: xen ovmf/uefi firmware does not save screen resolution [ In reply to ]
On 9/22/2022 11:25 AM, Chuck Zmudzinski wrote:
> On 9/22/2022 4:37 AM, mhbeyle@yahoo.es 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.2 (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:

Sorry, this is from the journal of the dom0, not 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 ___
> >
> >
> >
>
Re: xen ovmf/uefi firmware does not save screen resolution [ In reply to ]
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.
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.

-------------------------
MhBeyle __
> Date: Thu, 22 Sep 2022 11:25:41 -0400
> From: Chuck Zmudzinski <brchuckz@netscape.net>
>
>
> On 9/22/2022 4:37 AM, mhbeyle@yahoo.es 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 ___
>>
>>
>>
>
Re: xen ovmf/uefi firmware does not save screen resolution [ In reply to ]
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@netscape.net>
> >
> >
> > On 9/22/2022 4:37 AM, mhbeyle@yahoo.es 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 ___
> >>
> >>
> >>
> >
>
>
Re: xen ovmf/uefi firmware does not save screen resolution [ In reply to ]
On 9/22/2022 11:25 AM, Chuck Zmudzinski wrote:
> On 9/22/2022 4:37 AM, mhbeyle@yahoo.es 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@citrix.com/

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.