OK, according to the last comments, the bug has been fixed somewhere
with the last kernel or QEMU releases, so I'm closing this ticket now.
** Changed in: qemu
Status: Incomplete => Fix Released
You received this bug notification because you are a member of qemu-
devel-ml, which is subscribed to QEMU.
multi-core FreeBSD guest hangs after warm reboot
Status in QEMU:
On some Linux KVM hosts in our environment, FreeBSD guests fail to
reboot properly if they have more than one CPU (socket, core, and/or
thread). They will boot fine the first time, but after issuing a
"reboot" command via the OS the guest starts to boot but hangs during
SMP initialization. Fully shutting down and restarting the guest works
in all cases.
The only meaningful difference between hosts with the problem and those
without is the CPU. Hosts with Xeon E5-26xx v2 processors have the problem,
including at least the "Intel(R) Xeon(R) CPU E5-2667 v2" and the "Intel(R)
Xeon(R) CPU E5-2650 v2".
Hosts with any other CPU, including "Intel(R) Xeon(R) CPU E5-2650 0",
"Intel(R) Xeon(R) CPU E5-2620 0", or "AMD Opteron(TM) Processor 6274" do not
have the problem. Note the "v2" in the names of the problematic CPUs.
On hosts with a "v2" Xeon, I can reproduce the problem under Linux
kernel 3.10 or 3.12 and Qemu 1.7.0 or 2.0.0.
The problem occurs with all currently-supported versions of FreeBSD,
including 8.4, 9.2, 10.0 and 11-CURRENT.
On a Linux KVM host with a "v2" Xeon, this command line is adequate to
reproduce the problem:
/usr/bin/qemu-system-x86_64 -machine accel=kvm -name bsdtest -m 512
-smp 2,sockets=1,cores=1,threads=2 -drive
-device virtio-blk-pci,scsi=off,drive=drive0 -vnc 0.0.0.0:0 -net none
I have tried many variations including different models of -machine
and -cpu for the guest with no visible difference.
A native FreeBSD installation on a host with a "v2" Xeon does not have
the problem, nor do a paravirtualized FreeBSD guests under bhyve (the
BSD legacy-free hypervisor) using the same FreeBSD disk images as on
the Linux hosts. So it seems unlikely the cause is on the FreeBSD side
I would greatly appreciate any feedback or developer attention to
this. I am happy to provide additional details, test patches, etc.
To manage notifications about this bug go to: