[Bug 1882671] Re: qemu-system-x86_64 (ver 4.2) stuck at boot with OVMF bios

[Laszlo Ersek (Red Hat)]

Vladislav,

The OVMF debug log ends like this (with UEFI protocol GUIDs decoded as
their textual identifiers in edk2):

> [Security] 3rd party image[6D19D18] can be loaded after EndOfDxe: 
> PciRoot(0x0)/Pci(0x3,0x0)/Offset(0x16400,0x4B1FF).
> InstallProtocolInterface: [EfiLoadedImageProtocol] 6D187C0
> Loading driver at 0x00006B1F000 EntryPoint=0x00006B25497 82540em.efi
> InstallProtocolInterface: [EfiLoadedImageDevicePathProtocol] 6D18498
> ProtectUefiImageCommon - 0x6D187C0
>   - 0x0000000006B1F000 - 0x00000000000B6E60
> InstallProtocolInterface: [EfiDriverBindingProtocol] 6B50C00
> InstallProtocolInterface: [EfiComponentName2Protocol] 6B50BD0
> ASSERT 
> /home/jenkins/workspace/edk2/rpms/build/edk2-g6ff7c838d0/MdeModulePkg/Core/Dxe/Image/Image.c(1676):
>  Image->Tpl == gEfiCurrentTpl

This final log snippet confirms that a UEFI device driver called
"82540em.efi" is being loaded and started from the option ROM BAR of the
PCI device that is at slot 3, function 0, of the root bridge.

When this UEFI device driver is started, it trips an assert in the
platform firmware. Namely, in the CoreStartImage() function in the
"MdeModulePkg/Core/Dxe/Image/Image.c" source file of edk2:

  //
  // Image has completed.  Verify the tpl is the same
  //
  ASSERT (Image->Tpl == gEfiCurrentTpl);

This suggests that the "82540em.efi" driver exits its entry point
function after having raised, but not having restored, the TPL (Task
Priority Level). In other words, the symptom indicates a bug in the UEFI
driver.

I *suspect* (but am not sure) that you are using an e1000 emulated NIC,
and the "82540em.efi" driver exposed in its oprom comes from the iPXE
project:

src/drivers/net/intel.c:        PCI_ROM ( 0x8086, 0x100e, "82540em",
"82540EM", 0 ),

Therefore I suspect a bug in the iPXE version that the Ubuntu 20.04
upgrade brought to you.

(I can see a number of TPL-related patches in the iPXE git history,
around Feb-Mar 2018. And QEMU loads the iPXE oprom into the emulated
NICs ROM BAR.)

Please try installing different versions of the iPXE package on your
Ubuntu host, and re-run your test (without changing any other elements
of your setup).

Thanks.

-- 
You received this bug notification because you are a member of qemu-
devel-ml, which is subscribed to QEMU.
https://bugs.launchpad.net/bugs/1882671

Title:
  qemu-system-x86_64 (ver 4.2) stuck at boot with OVMF bios

Status in QEMU:
  New
Status in qemu package in Ubuntu:
  Confirmed

Bug description:
  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:0000000007f1d225 pc=0000000007f1d225 
SP=0030:0000000007f0c8d0 env->regs[R_EAX]=0000000000000000
  RAX=0000000000000000 RBX=0000000007f0c920 RCX=0000000000000000 
RDX=0000000000000001
  RSI=0000000006d18798 RDI=0000000000008664 RBP=0000000000000000 
RSP=0000000007f0c8d0
  R8 =0000000000000001 R9 =0000000000000089 R10=0000000000000000 
R11=0000000007f2c987
  R12=0000000000000000 R13=0000000000000000 R14=0000000007087901 
R15=0000000000000000
  RIP=0000000007f1d225 RFL=00000246 [---Z-P-] CPL=0 II=0 A20=1 SMM=0 HLT=0
  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=0000000000000000 CR3=0000000007c01000 CR4=00000668
  DR0=0000000000000000 DR1=0000000000000000 DR2=0000000000000000 
DR3=0000000000000000 
  DR6=00000000ffff0ff0 DR7=0000000000000400
  CCS=0000000000000044 CCD=0000000000000000 CCO=EFLAGS  
  EFER=0000000000000d00

  
  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:
  
https://www.kraxel.org/repos/jenkins/edk2/edk2.git-ovmf-x64-0-20200515.1398.g6ff7c838d0.noarch.rpm

  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

To manage notifications about this bug go to:
https://bugs.launchpad.net/qemu/+bug/1882671/+subscriptions