mistranslation: 0.944
debug: 0.939
permissions: 0.934
semantic: 0.921
peripherals: 0.916
register: 0.914
user-level: 0.912
performance: 0.906
architecture: 0.903
assembly: 0.898
device: 0.896
graphic: 0.890
PID: 0.882
arm: 0.877
hypervisor: 0.871
boot: 0.864
KVM: 0.862
virtual: 0.852
files: 0.849
network: 0.837
VMM: 0.835
socket: 0.824
vnc: 0.812
risc-v: 0.803
kernel: 0.801
ppc: 0.788
x86: 0.787
TCG: 0.766
i386: 0.556

qemu-system-x86_64 takes 100% CPU after host machine resumed from suspend to ram

I have Windows XP SP3  inside qemu VM. All works fine in 12.10. But after upgraiding to 13.04 i have to restart the VM each time i resuming my host machine, because qemu process starts to take CPU cycles and OS inside VM is very slow and sluggish. However it's still controllable and could be shutdown by itself.

According to the taskmgr any active process takes 99% CPU. It's not stucked on some single process.

core i3-2120 with kvm accel used on host.

Thanks for reporting this bug.  I won't be able to test this for another
week or two (waiting on a license).  Would it be possible for you to
test with the latest upstream git?

	sudo apt-get install git
	git clone git://git.qemu.org/qemu.git
	cd qemu
	./configure x86_64-softmmu
	make
	cd x86_64-softmmu
	sudo mv /usr/bin/qemu-system-x86 /usr/bin/qemu-system-x86.orig
	sudo cp x86_64-softmmu /usr/bin/

Then re-test your guest.

If that's not possible then please let us know.

 importance: high
 status: incomplete


at least on the clone of  
git remote -v
origin	http://repo.or.cz/r/qemu.git (fetch)
origin	http://repo.or.cz/r/qemu.git (push)
i got
 ./configure x86_64-softmmu
ERROR: unknown option x86_64-softmmu

I can't clone the repo over git protocol as i'm behind the proxy.

Ok, found the corrent link for the main repo http://git.qemu.org/git/qemu.git, but ./configure still doesn't recognize this option.

Quoting Maxim Loparev (<email address hidden>):
> at least on the clone of  
> git remote -v
> origin	http://repo.or.cz/r/qemu.git (fetch)
> origin	http://repo.or.cz/r/qemu.git (push)
> i got
>  ./configure x86_64-softmmu
> ERROR: unknown option x86_64-softmmu

Sorry!  That was supposed to read

  ./configure --target-list="x86_64-softmmu"


Same issue after resume with this -softmmu VM.
At start it also has the new message 
qemu-system-x86_64: pci_add_option_rom: failed to find romfile "efi-e1000.rom"

The issue mostly gone after cold reboot via suspend to disk. I managed to reproduce it only once after reboot and it grubs CPU for only minute or two while i checking it and than returned to normal CPU usage. I've checked both distribution and the trunk version.
So suspend this bug until someone can stably reproduce it.

Quoting Maxim Loparev (<email address hidden>):
> The issue mostly gone after cold reboot via suspend to disk. I managed to reproduce it only once after reboot and it grubs CPU for only minute or two while i checking it and than returned to normal CPU usage. I've checked both distribution and the trunk version.
> So suspend this bug until someone can stably reproduce it.

Thanks, I'll mark it invalid (meaning "can't reproduce it to get more
information") for now, please do re-open if anyone can reproduce.

 status: invalid


I don't know if this will help, but I had a similar problem.

When creating a snapshot image of an XP machine, all works just fine when loading it. As time passes on the host the loadvm start to become very slow.

To reproduce:
1. Create a snapshot image (savevm)
2. leave QEMU
3. move the *HOST* clock one month in the future
4. Start QEMU with -loadvm

It turns out that the "-rtc clock=vm" made this disappear. When using the default caused the problem.

John

Hi,

I am also encountering the bug of high cpu usage for a windows guest after suspend resume of my ubuntu host. Problem was in 13.04 but it's also still there in 13.10.
The windows guest has virtio / spice  enabled.
Linux guests do not get the high cpu usage.
Are there any more logs required or is investigation going on upstream ?
I am not sure where to look or curious whether there are other workarounds.

Please try "-global mc146818rtc.lost_tick_policy=slew".

hi,

tried your option but it does not help. (cpu usage is still high)
below my command line syntax:
qemu-system-x86_64 -global mc146818rtc.lost_tick_policy=slew -machine accel=kvm:tcg -name win7 -S -machine pc-i440fx-1.4,accel=kvm,usb=off -m 2048 -realtime mlock=off -smp 1,sockets=1,cores=1,threads=1 -uuid 813f5806-64ec-3319-452a-5e1834e753c9 -no-user-config -nodefaults -chardev socket,id=charmonitor,path=/var/lib/libvirt/qemu/win7.monitor,server,nowait -mon chardev=charmonitor,id=monitor,mode=control -rtc base=localtime -no-shutdown -device ich9-usb-ehci1,id=usb,bus=pci.0,addr=0x5.0x7 -device ich9-usb-uhci1,masterbus=usb.0,firstport=0,bus=pci.0,multifunction=on,addr=0x5 -device ich9-usb-uhci2,masterbus=usb.0,firstport=2,bus=pci.0,addr=0x5.0x1 -device ich9-usb-uhci3,masterbus=usb.0,firstport=4,bus=pci.0,addr=0x5.0x2 -device virtio-serial-pci,id=virtio-serial0,bus=pci.0,addr=0x8 -drive file=/data/vmware/win7.img,if=none,id=drive-virtio-disk0,format=qcow2 -device virtio-blk-pci,scsi=off,bus=pci.0,addr=0x6,drive=drive-virtio-disk0,id=virtio-disk0,bootindex=1 -device usb-tablet,id=input0 -device intel-hda,id=sound0,bus=pci.0,addr=0x4 -device hda-duplex,id=sound0-codec0,bus=sound0.0,cad=0 -device virtio-balloon-pci,id=balloon0,bus=pci.0,addr=0x7 -vga std

Hello Mike,

Thanks a lot for getting back on this.
Is the "cpu idle driver" a command line option I need to specify for 
qemu (the -cpu option ?)
I could not find a reference to "idle" in the man page.

regards,

Tobias.

On 18-10-13 04:33, mike wrote:
> On 10/18/2013 04:29 AM, tobias wrote:
>> hi,
>>
>> tried your option but it does not help. (cpu usage is still high)
>> below my command line syntax:
>> qemu-system-x86_64 -global mc146818rtc.lost_tick_policy=slew -machine 
>> accel=kvm:tcg -name win7 -S -machine pc-i440fx-1.4,accel=kvm,usb=off 
>> -m 2048 -realtime mlock=off -smp 1,sockets=1,cores=1,threads=1 -uuid 
>> 813f5806-64ec-3319-452a-5e1834e753c9 -no-user-config -nodefaults 
>> -chardev 
>> socket,id=charmonitor,path=/var/lib/libvirt/qemu/win7.monitor,server,nowait 
>> -mon chardev=charmonitor,id=monitor,mode=control -rtc base=localtime 
>> -no-shutdown -device ich9-usb-ehci1,id=usb,bus=pci.0,addr=0x5.0x7 
>> -device 
>> ich9-usb-uhci1,masterbus=usb.0,firstport=0,bus=pci.0,multifunction=on,addr=0x5 
>> -device 
>> ich9-usb-uhci2,masterbus=usb.0,firstport=2,bus=pci.0,addr=0x5.0x1 
>> -device 
>> ich9-usb-uhci3,masterbus=usb.0,firstport=4,bus=pci.0,addr=0x5.0x2 
>> -device virtio-serial-pci,id=virtio-serial0,bus=pci.0,addr=0x8 -drive 
>> file=/data/vmware/win7.img,if=none,id=drive-virtio-disk0,format=qcow2 
>> -device 
>> virtio-blk-pci,scsi=off,bus=pci.0,addr=0x6,drive=drive-virtio-disk0,id=virtio-disk0,bootindex=1 
>> -device usb-tablet,id=input0 -device 
>> intel-hda,id=sound0,bus=pci.0,addr=0x4 -device 
>> hda-duplex,id=sound0-codec0,bus=sound0.0,cad=0 -device 
>> virtio-balloon-pci,id=balloon0,bus=pci.0,addr=0x7 -vga std
> Hi, have you enable the kernel CPU idle driver?  especially the guest 
> kernel.
>
> Thanks
> Mike
>>
>
>



Hello MIke,

but this concerns a windows guest. you mean a kernel configuration 
within the guest (aka recompile ?) or a boot parameter within the guest ?

regards,

Tobias.

On 18-10-13 09:26, mike wrote:
> On 10/18/2013 03:12 PM, tobias wrote:
>> Hello Mike,
>>
>> Thanks a lot for getting back on this.
>> Is the "cpu idle driver" a command line option I need to specify for
>> qemu (the -cpu option ?)
>> I could not find a reference to "idle" in the man page.
> You need to check the guest kernel config file.
>
> Thanks
> Mike
>> regards,
>>
>> Tobias.
>>
>> On 18-10-13 04:33, mike wrote:
>>> On 10/18/2013 04:29 AM, tobias wrote:
>>>> hi,
>>>>
>>>> tried your option but it does not help. (cpu usage is still high)
>>>> below my command line syntax:
>>>> qemu-system-x86_64 -global mc146818rtc.lost_tick_policy=slew -machine
>>>> accel=kvm:tcg -name win7 -S -machine pc-i440fx-1.4,accel=kvm,usb=off
>>>> -m 2048 -realtime mlock=off -smp 1,sockets=1,cores=1,threads=1 -uuid
>>>> 813f5806-64ec-3319-452a-5e1834e753c9 -no-user-config -nodefaults
>>>> -chardev
>>>> socket,id=charmonitor,path=/var/lib/libvirt/qemu/win7.monitor,server,nowait 
>>>>
>>>> -mon chardev=charmonitor,id=monitor,mode=control -rtc base=localtime
>>>> -no-shutdown -device ich9-usb-ehci1,id=usb,bus=pci.0,addr=0x5.0x7
>>>> -device
>>>> ich9-usb-uhci1,masterbus=usb.0,firstport=0,bus=pci.0,multifunction=on,addr=0x5 
>>>>
>>>> -device
>>>> ich9-usb-uhci2,masterbus=usb.0,firstport=2,bus=pci.0,addr=0x5.0x1
>>>> -device
>>>> ich9-usb-uhci3,masterbus=usb.0,firstport=4,bus=pci.0,addr=0x5.0x2
>>>> -device virtio-serial-pci,id=virtio-serial0,bus=pci.0,addr=0x8 -drive
>>>> file=/data/vmware/win7.img,if=none,id=drive-virtio-disk0,format=qcow2
>>>> -device
>>>> virtio-blk-pci,scsi=off,bus=pci.0,addr=0x6,drive=drive-virtio-disk0,id=virtio-disk0,bootindex=1 
>>>>
>>>> -device usb-tablet,id=input0 -device
>>>> intel-hda,id=sound0,bus=pci.0,addr=0x4 -device
>>>> hda-duplex,id=sound0-codec0,bus=sound0.0,cad=0 -device
>>>> virtio-balloon-pci,id=balloon0,bus=pci.0,addr=0x7 -vga std
>>> Hi, have you enable the kernel CPU idle driver?  especially the guest
>>> kernel.
>>>
>>> Thanks
>>> Mike
>>>
>



Hi,

ok confusion cleared :-)
actually i only have this issue with windows guests. linux guests do not 
show a high cpu usage after suspend resume.
so are there any recommendations you would have to work around it ?

regards,

Tobias.


On 18-10-13 09:42, mike wrote:
> On 10/18/2013 03:41 PM, tobias appelo wrote:
>> Hello MIke,
>>
>> but this concerns a windows guest. you mean a kernel configuration 
>> within the guest (aka recompile ?) or a boot parameter within the 
>> guest ?
>>
> Oh, sorry, I assume it is linux guest :)
>
> for windows, I have no idea of it :)
>
> Thanks
> Mike
>> regards,
>>
>> Tobias.
>>
>> On 18-10-13 09:26, mike wrote:
>>> On 10/18/2013 03:12 PM, tobias wrote:
>>>> Hello Mike,
>>>>
>>>> Thanks a lot for getting back on this.
>>>> Is the "cpu idle driver" a command line option I need to specify for
>>>> qemu (the -cpu option ?)
>>>> I could not find a reference to "idle" in the man page.
>>> You need to check the guest kernel config file.
>>>
>>> Thanks
>>> Mike
>>>> regards,
>>>>
>>>> Tobias.
>>>>
>>>> On 18-10-13 04:33, mike wrote:
>>>>> On 10/18/2013 04:29 AM, tobias wrote:
>>>>>> hi,
>>>>>>
>>>>>> tried your option but it does not help. (cpu usage is still high)
>>>>>> below my command line syntax:
>>>>>> qemu-system-x86_64 -global mc146818rtc.lost_tick_policy=slew 
>>>>>> -machine
>>>>>> accel=kvm:tcg -name win7 -S -machine pc-i440fx-1.4,accel=kvm,usb=off
>>>>>> -m 2048 -realtime mlock=off -smp 1,sockets=1,cores=1,threads=1 -uuid
>>>>>> 813f5806-64ec-3319-452a-5e1834e753c9 -no-user-config -nodefaults
>>>>>> -chardev
>>>>>> socket,id=charmonitor,path=/var/lib/libvirt/qemu/win7.monitor,server,nowait 
>>>>>>
>>>>>> -mon chardev=charmonitor,id=monitor,mode=control -rtc base=localtime
>>>>>> -no-shutdown -device ich9-usb-ehci1,id=usb,bus=pci.0,addr=0x5.0x7
>>>>>> -device
>>>>>> ich9-usb-uhci1,masterbus=usb.0,firstport=0,bus=pci.0,multifunction=on,addr=0x5 
>>>>>>
>>>>>> -device
>>>>>> ich9-usb-uhci2,masterbus=usb.0,firstport=2,bus=pci.0,addr=0x5.0x1
>>>>>> -device
>>>>>> ich9-usb-uhci3,masterbus=usb.0,firstport=4,bus=pci.0,addr=0x5.0x2
>>>>>> -device virtio-serial-pci,id=virtio-serial0,bus=pci.0,addr=0x8 
>>>>>> -drive
>>>>>> file=/data/vmware/win7.img,if=none,id=drive-virtio-disk0,format=qcow2 
>>>>>>
>>>>>> -device
>>>>>> virtio-blk-pci,scsi=off,bus=pci.0,addr=0x6,drive=drive-virtio-disk0,id=virtio-disk0,bootindex=1 
>>>>>>
>>>>>> -device usb-tablet,id=input0 -device
>>>>>> intel-hda,id=sound0,bus=pci.0,addr=0x4 -device
>>>>>> hda-duplex,id=sound0-codec0,bus=sound0.0,cad=0 -device
>>>>>> virtio-balloon-pci,id=balloon0,bus=pci.0,addr=0x7 -vga std
>>>>> Hi, have you enable the kernel CPU idle driver? especially the guest
>>>>> kernel.
>>>>>
>>>>> Thanks
>>>>> Mike
>>>>>
>>>
>>
>



Did some testing: if one pauses the vms that run windows before suspending ubuntu no high cpu usage is there once the host and windows vms are resumed.
 for me it's workable then in ubuntu by using a suspend / resume script with power manaager. I put this in /etc/pm/sleep.d (and make it executable) :

#!/bin/bash
PS_VM=/var/run/paused_vms

is_there_virsh () {
if [[ -z `which virsh` ]]
then echo "no actions for suspend or resume required"
exit 0
fi
}
case "$1" in
    suspend)
        is_there_virsh
        echo "" > /var/run/paused_vms
        for i in $(virsh list --state-running | grep running | awk {'print $2'})
        do echo $i >> /var/run/paused_vms
           virsh suspend $i
        done
        ;;
    resume)
        is_there_virsh
        for i in $(cat $PS_VM)
        do virsh resume $i
        done
        # optionally remove the file but this seems not required?
        rm $PS_VM
        ;;
    *)
        ;;
esac


Thanks for posting your script Tobias, I'm having the same problem on Fedora 20 and the script alleviates the symptom.

Matt

I am running Ubuntu Wily (the 20150717 daily build) can reproduce this problem, whatever the guest is Linux or Windows, after host got resumed from suspend, the kvm (qemu-system-x86_64) process becomes a 100% cpu usage,

user@ubuntu-mate:~$ kvm --version
QEMU emulator version 2.3.0 (Debian 1:2.3+dfsg-5ubuntu2), Copyright (c) 2003-2008 Fabrice Bellard

I wonder can the kvm program be fixed?

Same for me here, Ubuntu wily.
I'm using vagrant-libvirt, and my hosts also very often run wild with 100% cpu usage after suspend.

I observed a similar behavior with a different application on a Windows host. The application is using the multimedia timer. In my case it seems that the timer is catching up the ticks missed during suspend to ram after resume. The timer thread performing the callbacks has high-priority on Windows and makes the host machine almost unusable for a certain time depending on the suspend duration. 
Maybe it is a similar situation here?

This sounds sort of like a problem I have with reverting to live snapshots.
What I found out is that this is related to restoring the clock in the guest. You can find out more about it there:
https://bugs.launchpad.net/qemu/+bug/1505041

The takeaway is that a workaround is to set track='guest' on the rtc timer. For instance:

    <clock offset='localtime'>
      <timer name='rtc' track='guest'/>
    </clock>

If you have track='catchup' QEMU seems to try to send millions of interrupts so the guest clock will catch up to the current time, which can take minutes during which the guest is unusable.

It is possible this no longer happens though as I have had this workaround in place for quite some time but nobody formally said this is fixed or pointed to a commit fixing this.

I was seeing this problem when my Debian laptop suspended.  The CentOS guest would begin consuming a lot of cpu and only a hard-reset would fix it.

Changing the rtc line to

      <timer name='rtc' track='guest'/>

seems to have fixed it, though I haven't done extensive testing yet.

Thanks!

The QEMU project is currently considering to move its bug tracking to another system. For this we need to know which bugs are still valid and which could be closed already. Thus we are setting older bugs to "Incomplete" now.
If you still think this bug report here is valid, then please switch the state back to "New" within the next 60 days, otherwise this report will be marked as "Expired". Or mark it as "Fix Released" if the problem has been solved with a newer version of QEMU already. Thank you and sorry for the inconvenience.


[Expired for QEMU because there has been no activity for 60 days.]