Win10 来宾高 KVM 主机 CPU 使用率

Question

前段时间有人注意到 Win10 1803 WM 会在主机上提供高 CPU 使用率，例如 25%，即使客户端 CPU 使用率为 0%。它是通过在您的 virt XML 文件中设置这些设置来解决的：

 <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>

但问题是新回来的。我已经从 Debian 拉伸 ( QEMU 2.8.1/ Kernel 4.9) 转移到了 Buster ( QEMU 3.1.0/ Kernel 4.19) 和 Windows 10 1809。
问题可能与我不能再<synic state='on'/>在 Buster 上使用有关，而我可以在同一硬件上的 Stretch 上使用。
当我尝试启动 VM 时出现此错误

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

当我跑步时，lscpu我根本没有任何hv*标志。但同样，它在同一 CPU 上运行 Stretch。

Answer 1

至少在QEMU 3.1.0/Kernel 4.19似乎 QEMU 机器类型 > pc-i440fx-3.0不支持 synIC，这是 Windows 10 来宾构建 >= 1803 上需要的，以免出现主机 CPU 使用率高的问题。

我测试了以下机器类型：
pc-i440fx-2.8 (OK)
pc-i440fx-3.0 (OK)
pc-i440fx-3.1 (Fail)
pc-q35-3.1 (Fail)

Virt XML 文件中的 XML 元素：

</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>

更新：
原来是我的 XML 设置有问题！
以下内容还将使您的新 QEMU 机器类型在没有高主机 CPU 使用率的情况下平稳运行：

<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>

非常感谢Vitaly Kuznetsov对我如此耐心，让我意识到配置错误。