qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[Qemu-devel] [Bug 1329956] [NEW] multi-core FreeBSD guest hangs after wa


From: John Nielsen
Subject: [Qemu-devel] [Bug 1329956] [NEW] multi-core FreeBSD guest hangs after warm reboot
Date: Fri, 13 Jun 2014 21:14:39 -0000

Public bug reported:

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
file=./20140613_FreeBSD_9.2-RELEASE_ufs.qcow2,if=none,id=drive0,format=qcow2
-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 of
things.

I would greatly appreciate any feedback or developer attention to this.
I am happy to provide additional details, test patches, etc.

** Affects: qemu
     Importance: Undecided
         Status: New

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

Title:
  multi-core FreeBSD guest hangs after warm reboot

Status in QEMU:
  New

Bug description:
  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
  file=./20140613_FreeBSD_9.2-RELEASE_ufs.qcow2,if=none,id=drive0,format=qcow2
  -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
  of things.

  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:
https://bugs.launchpad.net/qemu/+bug/1329956/+subscriptions



reply via email to

[Prev in Thread] Current Thread [Next in Thread]