The version of QEMU (4.2.0) packaged for Ubuntu 20.04 hangs indefinitely at boot if an OVMF bios is used. This happens ONLY with qemu-system-x86_64. qemu-system-i386 works fine with the latest ia32 OVMF bios.
NOTE[1]: the same identical OVMF bios works fine on QEMU 2.x packaged with Ubuntu 18.04.
NOTE[2]: reproducing the fatal bug requires *no* operating system:
qemu-system-x86_64 -bios OVMF-pure-efi.fd
On its window QEMU gets stuck at the very first stage:
"Guest has not initialized the display (yet)."
NOTE[3]: QEMU gets stuck no matter if KVM is used or not.
NOTE[4]: By adding the `-d int` option it is possible to observe that QEMU is, apparently, stuck in an endless loop of interrupts. For the first few seconds, registers' values vary quickly, but at some point they reach a final value, while the interrupt counter increments:
NOTE[5]: Just to better help the investigation of the bug, I'd like to remark that the issue is NOT caused by an endless loop of triple-faults. I tried with -d cpu_reset and there is NO such loop. No triple fault whatsoever.
but the issue is the same with older OVMF versions as well.
Please take a look at it, as the bug is NOT a corner case. QEMU 4.2.0 cannot boot with an UEFI firmware (OVMF) while virtualizing a x86_64 machine AT ALL.
The version of QEMU (4.2.0) packaged for Ubuntu 20.04 hangs indefinitely at boot if an OVMF bios is used. This happens ONLY with qemu-system-x86_64. qemu-system-i386 works fine with the latest ia32 OVMF bios.
NOTE[1]: the same identical OVMF bios works fine on QEMU 2.x packaged with Ubuntu 18.04.
NOTE[2]: reproducing the fatal bug requires *no* operating system:
qemu- system- x86_64 -bios OVMF-pure-efi.fd
On its window QEMU gets stuck at the very first stage:
"Guest has not initialized the display (yet)."
NOTE[3]: QEMU gets stuck no matter if KVM is used or not.
NOTE[4]: By adding the `-d int` option it is possible to observe that QEMU is, apparently, stuck in an endless loop of interrupts. For the first few seconds, registers' values vary quickly, but at some point they reach a final value, while the interrupt counter increments:
2568: v=68 e=0000 i=0 cpl=0 IP=0038: 0000000007f1d22 5 pc=0000000007f1d225 SP=0030: 0000000007f0c8d 0 env->regs[ R_EAX]= 000000000000000 0 00000 RBX=0000000007f 0c920 RCX=00000000000 00000 RDX=00000000000 00001 18798 RDI=00000000000 08664 RBP=00000000000 00000 RSP=0000000007f 0c8d0 00000 R11=0000000007f 2c987 00000 R13=00000000000 00000 R14=00000000070 87901 R15=00000000000 00000 1d225 RFL=00000246 [---Z-P-] CPL=0 II=0 A20=1 SMM=0 HLT=0 00000 CR3=0000000007c 01000 CR4=00000668 00000 DR1=00000000000 00000 DR2=00000000000 00000 DR3=00000000000 00000 f0ff0 DR7=00000000000 00400 00044 CCD=00000000000 00000 CCO=EFLAGS 000d00
RAX=00000000000
RSI=0000000006d
R8 =0000000000000001 R9 =0000000000000089 R10=00000000000
R12=00000000000
RIP=0000000007f
ES =0030 0000000000000000 ffffffff 00cf9300 DPL=0 DS [-WA]
CS =0038 0000000000000000 ffffffff 00af9a00 DPL=0 CS64 [-R-]
SS =0030 0000000000000000 ffffffff 00cf9300 DPL=0 DS [-WA]
DS =0030 0000000000000000 ffffffff 00cf9300 DPL=0 DS [-WA]
FS =0030 0000000000000000 ffffffff 00cf9300 DPL=0 DS [-WA]
GS =0030 0000000000000000 ffffffff 00cf9300 DPL=0 DS [-WA]
LDT=0000 0000000000000000 0000ffff 00008200 DPL=0 LDT
TR =0000 0000000000000000 0000ffff 00008b00 DPL=0 TSS64-busy
GDT= 00000000079eea98 00000047
IDT= 000000000758f018 00000fff
CR0=80010033 CR2=00000000000
DR0=00000000000
DR6=00000000fff
CCS=00000000000
EFER=0000000000
NOTE[5]: Just to better help the investigation of the bug, I'd like to remark that the issue is NOT caused by an endless loop of triple-faults. I tried with -d cpu_reset and there is NO such loop. No triple fault whatsoever.
NOTE[6]: The OVMF version used for the test has been downloaded from: /www.kraxel. org/repos/ jenkins/ edk2/edk2. git-ovmf- x64-0-20200515. 1398.g6ff7c838d 0.noarch. rpm
https:/
but the issue is the same with older OVMF versions as well.
Please take a look at it, as the bug is NOT a corner case. QEMU 4.2.0 cannot boot with an UEFI firmware (OVMF) while virtualizing a x86_64 machine AT ALL.
Thank you very much,
Vladislav K. Valtchev