On 10/7/2022 8:02 AM, Chuck Zmudzinski wrote:
> 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.
Specifically, what is Xen's current strategy for supporting UEFI booting of guests (Windows, Linux, etc.)
on the x86 Xen hypervisor?
For example, is using HVM guests with the upstream Qemu device model considered legacy tech and
the work to develop support for UEFI booting in the future should be done using PVH guests instead
of HVM guests?
Kind regards,
Chuck
>
> 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 ___
> > >>
> > >>
> > >>
> > >
> >
> >
>
>
> 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.
Specifically, what is Xen's current strategy for supporting UEFI booting of guests (Windows, Linux, etc.)
on the x86 Xen hypervisor?
For example, is using HVM guests with the upstream Qemu device model considered legacy tech and
the work to develop support for UEFI booting in the future should be done using PVH guests instead
of HVM guests?
Kind regards,
Chuck
>
> 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 ___
> > >>
> > >>
> > >>
> > >
> >
> >
>
>