qemu-system-x86_64 broken on ubuntu 17.10

[eezacque]

I have run a virtual machine over the past three years without problems, but the update to Ubuntu 17.10 broke it: the machine falls into an infinite boot loop.

$ qemu-system-x86_64 --version
QEMU emulator version 2.10.1(Debian 1:2.10+dfsg-0ubuntu3.5)

$ sudo qemu-system-x86_64 -enable-kvm -usb \
    -chardev stdio,id=char0 \
    -device usb-host,vendorid=0x056a,productid=0x00c6 \
    -device usb-host,vendorid=0x04a9,productid=0x2220 \
    -soundhw all \
    -m 2048 -cpu core2duo -machine q35 \
    -smp 2 \
    -device usb-mouse \
    -vga std \
    -device isa-applesmc,osk="CONFIDENTIAL" \
    -smbios type=2 \
    -device ide-drive,bus=ide.0,drive=HDD \
    -drive id=HDD,if=none,cache=none,file=hdd.img \
    -device ide-drive,bus=ide.3,drive=ScrapHDD \
    -drive id=ScrapHDD,if=none,cache=none,file=scrap.img \
    -netdev tap,id=net0,ifname=tap0,script=no \
    -device e1000,netdev=net0,id=nic0,mac=00:aa:00:60:00:01

$ uname -a
Linux behemoth 4.13.0-36-generic #40-Ubuntu SMP Fri Feb 16 20:07:48 UTC 2018 x86_64 x86_64 x86_64 GNU/Linux

$ lsb_release -a
No LSB modules are available.
Distributor ID: Ubuntu
Description: Ubuntu 17.10
Release: 17.10
Codename: artful

ProblemType: Bug
DistroRelease: Ubuntu 17.10
Package: qemu-kvm 1:2.10+dfsg-0ubuntu3.5
ProcVersionSignature: Ubuntu 4.13.0-36.40-generic 4.13.13
Uname: Linux 4.13.0-36-generic x86_64
NonfreeKernelModules: wl
ApportVersion: 2.20.7-0ubuntu3.7
Architecture: amd64
CurrentDesktop: ubuntu:GNOME
Date: Fri Mar 9 10:11:39 2018
InstallationDate: Installed on 2014-10-24 (1231 days ago)
InstallationMedia: Ubuntu 14.04.1 LTS "Trusty Tahr" - Release amd64 (20140722.2)
KvmCmdLine: COMMAND STAT EUID RUID PID PPID %CPU COMMAND
MachineType: ASUS All Series
ProcKernelCmdLine: BOOT_IMAGE=/vmlinuz-4.13.0-36-generic root=/dev/mapper/ubuntu--vg-root ro acpi_enforce_resources=lax quiet splash vt.handoff=7
SourcePackage: qemu
UpgradeStatus: Upgraded to artful on 2018-03-08 (0 days ago)
dmi.bios.date: 06/24/2015
dmi.bios.vendor: American Megatrends Inc.
dmi.bios.version: 2501
dmi.board.asset.tag: To be filled by O.E.M.
dmi.board.name: Z97-PRO(Wi-Fi ac)
dmi.board.vendor: ASUSTeK COMPUTER INC.
dmi.board.version: Rev 1.xx
dmi.chassis.asset.tag: To Be Filled By O.E.M.
dmi.chassis.type: 3
dmi.chassis.vendor: To Be Filled By O.E.M.
dmi.chassis.version: To Be Filled By O.E.M.
dmi.modalias: dmi:bvnAmericanMegatrendsInc.:bvr2501:bd06/24/2015:svnASUS:pnAllSeries:pvrSystemVersion:rvnASUSTeKCOMPUTERINC.:rnZ97-PRO(Wi-Fiac):rvrRev1.xx:cvnToBeFilledByO.E.M.:ct3:cvrToBeFilledByO.E.M.:
dmi.product.family: ASUS MB
dmi.product.name: All Series
dmi.product.version: System Version
dmi.sys.vendor: ASUS

[eezacque (eezacque)]

I downgraded to qemu-system-x86 1:2.5+dfsg-5ubuntu10 and my virtual machine is booting again.

[Christian Ehrhardt  (paelzer)]

Hi,
what is the guest that hangs in this so one could try reproduce?

Virtual HW changes slightly with versions and implementations.
The implementation can't be swicthed (I've seen cases where e.g. vga fixes break older guests but are required for security of the host) but you can try with 1:2.10+dfsg-0ubuntu3.5 to swicth the machine type. Set -M to one of the pc-q35-* types you can see with "kvm -M ?".
Does an older one of them work (you -M q35 cmdline defaults to the latest).

[eezacque (eezacque)]

I am emulating a mac running OS X. Yes, I know Apple deems this illegal, but as long as Apple doesn't care about consumer laws, I claim the right to run applications I own a license for on a virtual Mac. The first Apple lawyer to sue me comes home in a body bag.

I will try your suggestion as soon I have time.

[eezacque (eezacque)]

I followed your suggestion to play with the -M switch: to no avail.

[eezacque (eezacque)]

I have been able to confine this problem to the Chimera boot loader used.
If I configure this bootloader to generate P-States, the boot process falls into an infinite loop, otherwise booting proceeds as usual.

[Christian Ehrhardt  (paelzer)]

Thanks eezaque to further debug this.
So If I understand you correctly the TL;DR is that newer qemu has issues with the chimera boot loader that you use.

You could give the even newer qemu a try that is in Ubuntu 18.04.
Otherwise this is more likely an upstream qemu change/issue that needs to be analyzed/fixed there to be backported into distributions.

OTOH most people (like me) won't just have a Chimera bootloader around to test.
There is no obvious follow on upstream fix yet that refers to Chimera directly.
The only thing I found was http://patchwork.ozlabs.org/patch/745713/ but that doesn't sound like your problem.

If ok for you I'd ask you to:
1. try the (much newer) qemu in 18.04
2. if affected as well, depending on you being able or not try it against a git build of qemu
   There just is v2.12.0-rc1 which would be a good candidate
3. prep a trivialized test a la "get bootloader here, run qemu with this commandline"

Once this is ready we could mirror this bug to qemu upstream for their consideration.

[eezacque (eezacque)]

I hope to switch to Ubuntu 18.04 by the end of this month, and will get back to this bug report by then.

[Robie Basak (racb)]

Please let us know if this affects 18.04, as 17.10 is now EOL.

[Launchpad Janitor (janitor)]

[Expired for qemu (Ubuntu) because there has been no activity for 60 days.]