Bugzilla (bugzilla.redhat.com) will be under maintenance for infrastructure upgrades and will not be available on July 31st between 12:30 AM - 05:30 AM UTC. We appreciate your understanding and patience. You can follow status.redhat.com for details.
Bug 1415558 - emulation failure on Intel Xeon X5450
Summary: emulation failure on Intel Xeon X5450
Alias: None
Product: Fedora
Classification: Fedora
Component: qemu
Version: 25
Hardware: Unspecified
OS: Unspecified
Target Milestone: ---
Assignee: Fedora Virtualization Maintainers
QA Contact: Fedora Extras Quality Assurance
Depends On:
TreeView+ depends on / blocked
Reported: 2017-01-23 04:31 UTC by Kyle Marek
Modified: 2017-02-05 20:23 UTC (History)
10 users (show)

Fixed In Version:
Doc Type: If docs needed, set a value
Doc Text:
Clone Of:
Last Closed: 2017-02-05 20:23:16 UTC
Type: Bug

Attachments (Terms of Use)

Description Kyle Marek 2017-01-23 04:31:53 UTC
Description of problem:
Host machine is a Dell PowerEdge 2950 with two Intel Xeon X5450 CPUs. I'm using Libvirt to manage QEMU virtual machines, and have discovered that the execution of iPXE (from the included ROMs) causes QEMU to crash.

My experience with this issue is spotty on other machines. So far, the only other host I have noticed this exact issue with is a Dell Latitude E5500. Newer Intel and AMD hosts do not suffer from this issue.

Version-Release number of selected component (if applicable):

How reproducible:

Steps to Reproduce:
1. Run: qemu-system-x86_64 -display none -nodefaults -nodefconfig -no-user-config -machine q35,accel=kvm -cpu qemu64 -monitor stdio -device qxl-vga -device virtio-net-pci # This command will leave only a virtio NIC to boot from, booting the iPXE ROM.

Actual results:

QEMU stops execution ("info status" shows "VM status: paused (internal-error)"), displays:
KVM internal error. Suberror: 1
emulation failure
EAX=f81a8cc0 EBX=000000a0 ECX=00002e50 EDX=0009eed8
ESI=07fa4bc0 EDI=07ef4000 EBP=ffffffff ESP=00007b92
EIP=000006ab EFL=00000087 [--S--PC] CPL=0 II=0 A20=1 SMM=0 HLT=0
ES =0000 00000000 ffffffff 00c09300
CS =9c48 0009c480 ffffffff 00809b00
SS =0000 00000000 ffffffff 00809300
DS =9ccc 0009ccc0 ffffffff 00c09300
FS =0000 00000000 ffffffff 00c09300
GS =0000 00000000 ffffffff 00c09300
LDT=0000 00000000 0000ffff 00008200
TR =0000 00000000 0000ffff 00008b00
GDT=     00000000 00000000
IDT=     00000000 000003ff
CR0=00000010 CR2=00000000 CR3=00000000 CR4=00000000
DR0=0000000000000000 DR1=0000000000000000 DR2=0000000000000000 DR3=0000000000000000 
DR6=00000000ffff0ff0 DR7=0000000000000400
Code=00 16 66 9c 66 60 0f a8 0f a0 06 1e 16 0e fa 2e 8e 1e 90 06 <0f> ae 06 00 1d 0f 01 0e f6 1c 0f 01 06 f0 1c fc 66 b9 38 00 00 00 66 ba 10 02 00 00 66 68

Expected results:
QEMU continues graceful execution past 1 second (remaining at the "(qemu) " prompt).

Additional info:
Changing "accel=" from "kvm" to "tcg" (disabling KVM acceleration) results in a working VM, but a lack of hardware acceleration makes this type of virtualization useless for my purposes.

Comment 1 Cole Robinson 2017-02-05 19:15:56 UTC
Is this still reproducing with latest qemu and kernel? May also try updating ipxe with the rawhide version, packages are linked here:


There was an emulation issue triggered by ipxe recently but I didn't catch all the details, that might be what you are hitting

Comment 2 Kyle Marek 2017-02-05 20:23:16 UTC
Updating kernel (and thus kernel-core and kernel-modules) alone fixed my issue. Updating all other packages (including qemu, and rawhide ipxe) does not "re-break" iPXE. The issue is no longer observed on either host.

The kernel change across the reboot was from 4.9.4-201.fc25.x86_64 to 4.9.6-200.fc25.x86_64 for the PowerEdge, and from 4.8.8-300.x86_64 to 4.9.6-200.fc25.x86_64 for the Latitude.

Note You need to log in before you can comment on or make changes to this bug.