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):
qemu-system-x86-2.7.1-2.fc25.x86_64
seabios-bin-1.9.3-1.fc25.noarch
ipxe-roms-qemu-20160622-1.git0418631.fc25.noarch
How reproducible:
100%
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
EFER=0000000000000000
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.
Is this still reproducing with latest qemu and kernel? May also try updating ipxe with the rawhide version, packages are linked here:
https://koji.fedoraproject.org/koji/buildinfo?buildID=822610
There was an emulation issue triggered by ipxe recently but I didn't catch all the details, that might be what you are hitting
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.
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): qemu-system-x86-2.7.1-2.fc25.x86_64 seabios-bin-1.9.3-1.fc25.noarch ipxe-roms-qemu-20160622-1.git0418631.fc25.noarch How reproducible: 100% 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 EFER=0000000000000000 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.