High host CPU load and slower guest after upgrade guest OS Windows 10 to ver 1803

Bug #1775702 reported by Giovanni Panozzo
112
This bug affects 21 people
Affects Status Importance Assigned to Milestone
QEMU
Fix Released
Undecided
Unassigned

Bug Description

After upgrading Windows 10 guest to version 1803, guests VM runs slower and there is high host CPU load even when guest is almost idle. Did not happened with windows 10 up to version 1709.

See my 1st report here:
https://askubuntu.com/questions/1033985/kvm-high-host-cpu-load-after-upgrading-vm-to-windows-10-1803

Another user report is here:
https://lime-technology.com/forums/topic/71479-windows-10-vm-cpu-usage/

Tested on: Ubuntu 16.04 with qemu 2.5.0 and i3-3217U, Arch with qemu 2.12 i5-7200U, Ubuntu 18.04 qemu 2.11.1 AMD FX-4300. All three platform showing the same slowdown and higher host cpu load with windows 10 1803 VM compared to windows 10 1709 VM.

Tags: windows10
Revision history for this message
Lemos Lemosov (lemosov) wrote :

This bug affect me

Revision history for this message
Heiko Sieger (h-sieger) wrote :

I ran into similar issues with Windows 10 (1803), with regard to 2D graphics performance.

See my bug report here: https://bugzilla.kernel.org/show_bug.cgi?id=200877

Could you test with Spectre protection (temporarily) turned off inside the Windows VM?

See my post here: https://heiko-sieger.info/low-2d-graphics-benchmark-with-windows-10-1803-kvm-vm/

Revision history for this message
Alexandre Derumier (aderumier-odiso) wrote : Re: [Qemu-devel] [Bug 1775702] Re: High host CPU load and slower guest after upgrade guest OS Windows 10 to ver 1803

Hi,
proxmox users have reported this bug
https://forum.proxmox.com/threads/high-cpu-load-for-windows-10-guests-when-idle.44531/#post-213876

hv_synic && hv_stimer hyperv enlightments fix it

(seem to be related to some hpet change in windows)

----- Mail original -----
De: "Lemos Lemosov" <email address hidden>
À: "qemu-devel" <email address hidden>
Envoyé: Mercredi 1 Août 2018 08:43:46
Objet: [Qemu-devel] [Bug 1775702] Re: High host CPU load and slower guest after upgrade guest OS Windows 10 to ver 1803

This bug affect me

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

Title:
High host CPU load and slower guest after upgrade guest OS Windows 10
to ver 1803

Status in QEMU:
New

Bug description:
After upgrading Windows 10 guest to version 1803, guests VM runs
slower and there is high host CPU load even when guest is almost idle.
Did not happened with windows 10 up to version 1709.

See my 1st report here:
https://askubuntu.com/questions/1033985/kvm-high-host-cpu-load-after-upgrading-vm-to-windows-10-1803

Another user report is here:
https://lime-technology.com/forums/topic/71479-windows-10-vm-cpu-usage/

Tested on: Ubuntu 16.04 with qemu 2.5.0 and i3-3217U, Arch with qemu
2.12 i5-7200U, Ubuntu 18.04 qemu 2.11.1 AMD FX-4300. All three
platform showing the same slowdown and higher host cpu load with
windows 10 1803 VM compared to windows 10 1709 VM.

To manage notifications about this bug go to:
https://bugs.launchpad.net/qemu/+bug/1775702/+subscriptions

Revision history for this message
costinel (costinel) wrote :

hv_synic && hv_stimer only reduces the cpu from 40-50% to 4-5%.
still expecting under 1% like linux guests.

Alex Bennée (ajbennee)
tags: added: windows10
Revision history for this message
Gannet (ken20001) wrote :

I found that C:\Program Files (x86)\SPICE Guest Tools\drivers\Balloon\w10\amd64/blnsvr.exe intensively requesting something in WMI-provider-host. And there are a lot of errors in event logs about it also.

Revision history for this message
Thomas Huth (th-huth) wrote :

Gannet, SPICE Guest Tools is certainly a different problem, you should report that to the spice project instead. And since the original problem was apparently fixed via hv_synic / hv_stimer (if I got the comments right), I'm closing this ticket now.

Changed in qemu:
status: New → Fix Released
To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.