Just to be sure, I repeated it, with the same result. I have the
impression that it might be the time spent between a vmentry and a
vmexit that matters in the CPU performance of the guest. I am no expert
though.
This is what I am seeing in the graphs:
vmentryinterval A(s)vmexitinterva
I also tried to give ESXi a try. VMware lets me download only 6.7 from
their site. Although I have a workstation motherboard (Supermicro
X9SRA), it won't let me start a VM with IOMMU enabled, it complains
about failing to register the passthrough GPU.
--
You received this bug notification because
David, your suggestion seemed helpful, at least there is a difference in
the pattern of vmentries and vmexits. See the snapshot attached.
Explanation of snapshot_1:
Two windows of kernelshark with trace.dats obtained using the command from
above; the left window (trace.dat) is with spec-ctrl feat
snapshot_2 showing the pattern of vmentries/vmexits from the previous
comment ("zoom-in").
** Attachment added: "snapshot_2.png"
https://bugs.launchpad.net/qemu/+bug/1788665/+attachment/5190356/+files/snapshot_2.png
--
You received this bug notification because you are a member of qemu-
deve
It seems that this "bug" affects only 2D-performance mediated through
GDI in Windows (CPU-, not GPU-driven). There have been reports that GDI
switches a lot between user/kernel space.
Are vmexits triggered when the guest switches from user- to kernel-
space? Could this be subsequently causing IRBS
Yes, it's an Nvidia GTX 1060 6GB with PCI passthrough to a Windows 1803
KVM guest. As far as I can tell my setup is very similar to Heiko's,
only I am using libvirt, not qemu directly.
--
You received this bug notification because you are a member of qemu-
devel-ml, which is subscribed to QEMU.
h
I did a git-bisect between 4.14.18(bad) and 4.14.10(good).
Unsurprisingly, this is the first "bad" commit:
KVM/VMX: Allow direct access to MSR_IA32_SPEC_CTRL
commit d28b387fb74da95d69d2615732f50cceb38e9a4d
George
--
You received this bug notification because you are a member of qemu-
deve
Hello All,
I can reproduce this on two different systems with Ivy-Bridge CPUs:
Xeon E5 2667v2 / X9SRA running Fedora 28, with Windows 10 1803 as KVM guest
Xeon E3 1270v2 / X9SCM running Archlinux, with Windows 10 1803 as KVM guest
The performance degradation doesn't occur when the Windows 10 gues
