From: Heiko Sieger <1788665@bugs.launchpad.net>
To: qemu-devel@nongnu.org
Subject: [Qemu-devel] [Bug 1788665] Re: Low 2D graphics performance with Windows 10 (1803) VGA passthrough VM using "Spectre" protection
Date: Thu, 30 Aug 2018 15:21:26 -0000 [thread overview]
Message-ID: <153564248684.31293.17131853207421098455.malone@soybean.canonical.com> (raw)
In-Reply-To: 153504502595.30588.13203676939349086206.malonedeb@soybean.canonical.com
>The possibilities left are that either your Windows guest is lacking
software updates that could perhaps improve its performance, or that 2D
graphics really is that awful in combination with spectre/meltdown
fixes.
Thanks Daniel. There are two problems with this explanation:
1. A native "bare metal" Windows 10 (1803) installation with all updates
applied does NOT have any 2D performance problems. See my attachment
(benchmarks) in the original post.
2. Both the Windows VM and the Linux VM do not see the microcode (version?), and therefore do not know about the Spectre vulnerability mitigation in the host kernel. However, the Microsoft document https://docs.microsoft.com/en-us/virtualization/hyper-v-on-windows/CVE-2017-5715-and-hyper-v-vms suggests that Microsoft Hyper-V can be configured to expose new processor capabilities to guest virtual machines, specifically the ones made available through the microcode updates. Here a quote from the above Microsoft website:
"Firmware updates from your OEM may contain new processor capabilities that can be used to protect against CVE-2017-5715 (IBRS, STIBP, IBPB). Once the virtualization host's firmware has been updated, the hypervisor can make these additional capabilities available to guest virtual machines after taking the following steps."
The ideal behavior of qemu/kvm would be to expose the microcode
capabilities to the guest (I suppose this happens partially as seen by
the presence of the "pti ssbd ibrs ibpb" flags), but obviously
something is missing.
But the real important question is this:
In the above scenario, are the VMs protected from Spectre vulnerabilities, simply by having the microcode installed in the host? Even when I disable the Spectre protection inside the Windows VM?
--
You received this bug notification because you are a member of qemu-
devel-ml, which is subscribed to QEMU.
https://bugs.launchpad.net/bugs/1788665
Title:
Low 2D graphics performance with Windows 10 (1803) VGA passthrough VM
using "Spectre" protection
Status in QEMU:
New
Bug description:
Windows 10 (1803) VM using VGA passthrough via qemu script.
After upgrading Windows 10 Pro VM to version 1803, or possibly after
applying the March/April security updates from Microsoft, the VM would
show low 2D graphics performance (sluggishness in 2D applications and
low Passmark results).
Turning off Spectre vulnerability protection in Windows remedies the
issue.
Expected behavior:
qemu/kvm hypervisor to expose firmware capabilities of host to guest OS - see https://docs.microsoft.com/en-us/virtualization/hyper-v-on-windows/CVE-2017-5715-and-hyper-v-vms
Background:
Starting in March or April Microsoft began to push driver updates in
their updates / security updates. See https://support.microsoft.com
/en-us/help/4073757/protect-your-windows-devices-against-spectre-
meltdown
One update concerns the Intel microcode - see
https://support.microsoft.com/en-us/help/4100347. It is activated by
default within Windows.
Once the updates are applied within the Windows guest, 2D graphics
performance drops significantly. Other performance benchmarks are not
affected.
A bare metal Windows installation does not display a performance loss
after the update. See https://heiko-sieger.info/low-2d-graphics-
benchmark-with-windows-10-1803-kvm-vm/
Similar reports can be found here:
https://www.reddit.com/r/VFIO/comments/97unx4/passmark_lousy_2d_graphics_performance_on_windows/
Hardware:
6 core Intel Core i7-3930K (-MT-MCP-)
Host OS:
Linux Mint 19/Ubuntu 18.04
Kernel: 4.15.0-32-generic x86_64
Qemu: QEMU emulator version 2.11.1
Intel microcode (host): 0x714
dmesg | grep microcode
[ 0.000000] microcode: microcode updated early to revision 0x714, date = 2018-05-08
[ 2.810683] microcode: sig=0x206d7, pf=0x4, revision=0x714
[ 2.813340] microcode: Microcode Update Driver: v2.2.
Note: I manually updated the Intel microcode on the host from 0x713 to
0x714. However, both microcode versions produce the same result in the
Windows guest.
Guest OS:
Windows 10 Pro 64 bit, release 1803
To manage notifications about this bug go to:
https://bugs.launchpad.net/qemu/+bug/1788665/+subscriptions
next prev parent reply other threads:[~2018-08-30 15:49 UTC|newest]
Thread overview: 27+ messages / expand[flat|nested] mbox.gz Atom feed top
2018-08-23 17:23 [Qemu-devel] [Bug 1788665] [NEW] Low 2D graphics performance with Windows 10 (1803) VGA passthrough VM using "Spectre" protection Heiko Sieger
2018-08-24 8:16 ` [Qemu-devel] [Bug 1788665] " Daniel Berrange
2018-08-24 16:47 ` Heiko Sieger
2018-08-24 17:11 ` Daniel Berrange
2018-08-24 21:43 ` Heiko Sieger
2018-08-25 15:20 ` Heiko Sieger
2018-08-25 15:27 ` Heiko Sieger
2018-08-28 16:07 ` Daniel Berrange
2018-08-28 17:20 ` Heiko Sieger
2018-08-30 10:40 ` Heiko Sieger
2018-08-30 11:08 ` Heiko Sieger
2018-08-30 11:53 ` Daniel Berrange
2018-08-30 15:21 ` Heiko Sieger [this message]
2018-08-30 16:11 ` Daniel Berrange
2018-08-30 20:21 ` Heiko Sieger
2018-08-31 9:45 ` Dr. David Alan Gilbert
2018-09-05 6:12 ` Heiko Sieger
2018-09-05 10:21 ` Dr. David Alan Gilbert
2018-09-05 20:01 ` Heiko Sieger
2018-09-11 18:56 ` George Amanakis
2018-09-14 17:27 ` George Amanakis
2018-09-14 17:42 ` Dr. David Alan Gilbert
2018-09-14 20:02 ` George Amanakis
2020-11-12 18:24 ` Thomas Huth
2020-11-19 20:23 ` Heiko Sieger
2021-01-21 18:18 ` Thomas Huth
2021-01-22 4:17 ` Launchpad Bug Tracker
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=153564248684.31293.17131853207421098455.malone@soybean.canonical.com \
--to=1788665@bugs.launchpad.net \
--cc=qemu-devel@nongnu.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.