4

Some time ago it was noticed that Win10 1803 WM's would give high CPU usage on the host e.g. 25%, even though client CPU usage 0%. It was solved by having these settings in your virt XML file:

 <hyperv>
   <relaxed state='on'/>
   <vapic state='on'/>
   <spinlocks state='on' retries='8191'/>
   <synic state='on'/> 
   <stimer state='on'/>
 </hyperv>

 <clock offset='localtime'>
   <timer name='rtc' tickpolicy='catchup'/>
   <timer name='pit' tickpolicy='delay'/>
   <timer name='hpet' present='no'/>
   <timer name='hypervclock' present='yes'/>
 </clock>

But the problem is new back. I've moved from Debian stretch (QEMU 2.8.1 / Kernel 4.9) to Buster (QEMU 3.1.0 / Kernel 4.19) and Windows 10 1809.
The problem might be related to I can no longer use <synic state='on'/> on Buster which I could on Stretch on the same hardware.
When I try to start the VM i get this error

error: internal error: process exited while connecting to monitor: Hyper-V SynIC (requested by 'hv-synic' cpu flag) requires Hyper-V VP_INDEX ('hv-vpindex')
2019-08-06T13:29:14.114943Z qemu-system-x86_64: kvm_init_vcpu failed: Function not implemented

When I run lscpu I don't have any hv* flags at all. But again, it worked on Stretch on the same CPU.

1
  • Compated the XML with an old VM which support the <synic state='on'/>. The difference is machine='pc-i440fx-2.8' and machine='pc-q35-3.1'....need to do some more investigation.
    – MrCalvin
    Aug 6, 2019 at 14:47

1 Answer 1

7

At least on QEMU 3.1.0 / Kernel 4.19 it seems QEMU machine types > pc-i440fx-3.0 doesn't support synIC, which is needed on Windows 10 guest build >= 1803 to not have issues with high host CPU usage.

I've tested following machine types:
pc-i440fx-2.8 (OK)
pc-i440fx-3.0 (OK)
pc-i440fx-3.1 (Fail)
pc-q35-3.1 (Fail)

The XML element in the Virt XML file:

</features>
   ...
   <hyperv>
      <relaxed state='on'/>
      <vapic state='on'/>
      <spinlocks state='on' retries='8191'/>
      <synic state='on'/>
      <stimer state='on'/>
   </hyperv>
   ...
</features>

<clock offset='localtime'>
   <timer name='rtc' tickpolicy='catchup'/>
   <timer name='pit' tickpolicy='delay'/>
   <timer name='hpet' present='no'/>
   <timer name='hypervclock' present='yes'/>
</clock>

UPDATE:
It turned out to be my XML settings that was the issue!
The following will also make your new QEMU machine types run smoothly without high host CPU usage:

<hyperv>
   <relaxed state='on'/>
   <vpindex state='on'/>
   <synic state='on'/>
   <stimer state='on'/>
</hyperv>

<clock offset='localtime'>
   <timer name='rtc' tickpolicy='catchup'/>
   <timer name='pit' tickpolicy='delay'/>
   <timer name='hpet' present='no'/>
   <timer name='hypervclock' present='yes'/>
</clock>

A big thank you to Vitaly Kuznetsov for being so patient with me and made me realize the misconfiguration.

2
  • Thank you for the above share - it was a massive improvement to some similar problems I was experiencing.
    – Mark
    Feb 1, 2020 at 12:53
  • this is also working for machine: <type arch="x86_64" machine="pc-q35-rhel7.6.0">hvm</type>.
    – bebbo
    Oct 16, 2020 at 10:31

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.