Looks like the bug was fixed by this commit:
commit 013aabdc665e4256b38d8875a1a7b5e030ba98f1
Author: Clement Deschamps <clement.descha...@greensocs.com>
Date: Sun Oct 21 16:21:03 2018 +0200
icount: fix deadlock when all cpus are sleeping
When all cpus are sleeping (e.g in WFI), to avoid a deadlock
in the main_loop, wake it up in order to start the warp timer.
Signed-off-by: Clement Deschamps <clement.descha...@greensocs.com>
Message-Id: <20181021142103.19014-1-clement.descha...@greensocs.com>
Signed-off-by: Paolo Bonzini <pbonz...@redhat.com>
** Changed in: qemu
Status: Confirmed => Fix Committed
--
You received this bug notification because you are a member of qemu-
devel-ml, which is subscribed to QEMU.
https://bugs.launchpad.net/bugs/1774677
Title:
-icount increases boot time by >10x
Status in QEMU:
Fix Committed
Bug description:
When I specify the -icount option, some guest operations such as
booting a Linux kernel take more than 10 times longer than otherwise.
For example, the following will boot Aboriginal Linux to the login
prompt about 6 seconds on my system (using TCG, not KVM):
wget
http://landley.net/aboriginal/downloads/old/binaries/1.4.5/system-image-i686.tar.gz
gunzip <system-image-i686.tar.gz | tar xfv -
cd system-image-i686
sh run-emulator.sh
If I replace the last line with
QEMU_EXTRA="-icount shift=auto" sh run-emulator.sh
booting to the login prompt takes about 1 minute 20 seconds.
I have tried different values for "shift" other than the "auto" used
above, but have not been able to find one that gives reasonable
performance. Specifying "sleep=off" also did not help.
During the slow boots, qemu appears to spend most of its time
sleeping, not using the host CPU.
I see this with multiple versions of qemu, including current git
sources (c181ddaa176856b3cd2dfd12bbcf25fa9c884a97), and on multiple
host OSes, including Debian 9 on x86_64.
To manage notifications about this bug go to:
https://bugs.launchpad.net/qemu/+bug/1774677/+subscriptions
