[Expired for QEMU because there has been no activity for 60 days.]
** Changed in: qemu
Status: Incomplete => Expired
--
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
** Bug watch removed: Linux Kernel Bug Tracker #200877
https://bugzilla.kernel.org/show_bug.cgi?id=200877
--
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
I've switched hosts so I would have to run a series of tests to compare.
There are a number of new variables:
1. Windows 10 release (I'm now on Windows 2004)
2. My host OS is now Manjaro
3. CPU is now AMD Ryzen 3900X (before it was Intel 3930k)
4. Kernel is 5.8.18-1-MANJARO
5. qemu 5.1.0
6.
The QEMU project is currently considering to move its bug tracking to another
system. For this we need to know which bugs are still valid and which could be
closed already. Thus we are setting older bugs to "Incomplete" now.
If you still think this bug report here is valid, then please switch
It doesn't surprise me too much that the time spent on the host between
exit is higher on a host dealing with spec-ctrl; but I wouldn't
really expect it to change depending on the guests settings.
--
You received this bug notification because you are a member of qemu-
devel-ml, which is
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
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
Have we got this the right way around
So you're saying the one with spec-ctrl disabled is faster, but has a lot more
kvm-exits?
--
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:
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
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-
I don't think we should see a vmexit on a guest user<->kernel switch.
You could try a kvm trace:
trace-cmd record -b 2 -e kvm
run your test, then ctrl-c
then
trace-cmd report
and you can see all the reasons for exit and see if there are any major
differences.
Yes, it would be good to
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
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.
George: Can you confirm how your graphics is setup; the original
reporter had an Nvidia card with PCI passthrough; is yours the same?
--
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:
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-
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
I won’t be able to run any tests for the next 16 days at the very least,
as I’m traveling.
> On 5 Sep 2018, at 13:21, Dr. David Alan Gilbert wrote:
>
> I don't have the nvidia for pass through to try this with; but I suggest
> that you try the following:
>
> a) Start a windows vm running an
I don't have the nvidia for pass through to try this with; but I suggest
that you try the following:
a) Start a windows vm running an older version unaffected by the bug and
start a 2d test
b) run 'perf top' on the host while the test is running and capture the
results
- make sure you
Here is another person confirming the bug, with a little more details:
https://bugzilla.kernel.org/show_bug.cgi?id=200877#c2
Sorry for reporting the bug twice, but it is unclear to me whose going
to take action.
** Bug watch added: Linux Kernel Bug Tracker #200877
I find it interesting this is a slow down with PCI passthrough - that's
pretty much the case you'd expect there to be least change; it shouldn't
be generating lots of vm exit's for example which you'd expect could
have been made slower by the recent security changes.
I suppose one thing you could
> If you disable Spectre protection in the Windows VM, then it is not
protected from Spectre. The hypervisor protects itself, and exposes the
CPU feature(s) that enable the guest to activate its own protection. The
hypervisor won't protect the guest directly - it just gives it the tools
needed to
There is always a performance differential between bare metal & VMs. The
actual amount varies depending on alot of different factors and
meltdown/spectre have had an effect here - the actual perf hit depends
on the CPU models & virtual hardware and more besides - ranging anywhere
from 0% to 40%
>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
> Whew, after some hurdles I managed to install a Linux Mint 19 guest (Ubuntu
> 18.04). After all updates, here the output:
>
> $ dmesg | grep microcode
> [ 0.036780] core: PEBS disabled due to CPU errata, please upgrade microcode
>
> So the microcode in the guest is not loaded! But see below:
Downloaded and ran the spectre-meltdown-checker.sh
$ spectre-meltdown-checker.sh
Spectre and Meltdown mitigation detection tool v0.39+
Checking for vulnerabilities on current system
Kernel is Linux 4.15.0-33-generic #36-Ubuntu SMP Wed Aug 15 16:00:05 UTC 2018
x86_64
CPU is Intel(R) Core(TM)
Whew, after some hurdles I managed to install a Linux Mint 19 guest
(Ubuntu 18.04). After all updates, here the output:
$ dmesg | grep microcode
[0.036780] core: PEBS disabled due to CPU errata, please upgrade microcode
So the microcode in the guest is not loaded! But see below:
$ cat
Thanks, I will do that tomorrow and report back.
--
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
I'm not convinced we can trust the output from cygwin wrt CPU flags. A
better test would be to install a modern Linux guest which has the
mitigations, and see if that reports the flags.
--
You received this bug notification because you are a member of qemu-
devel-ml, which is subscribed to
For comparison, here the Linux/host cat /proc/cpuinfo (partial):
processor : 11
vendor_id : GenuineIntel
cpu family : 6
model : 45
model name : Intel(R) Core(TM) i7-3930K CPU @ 3.20GHz
stepping: 7
microcode : 0x714
cpu MHz : 4200.015
cache
Daniel Berrange: ...Essentially if your guest kernel shows "pti ssbd
ibrs ibpb stibp" features as present, then thanks to your "-cpu host"
usage, the guest should see them too.
1. I changed my qemu start script and added +vmx:
-cpu
Thanks for your explanations - I thought so too.
The new Intel microcode is applied, as you can see:
dmesg | grep microcode
[ 0.00] microcode: microcode updated early to revision 0x714, date =
2018-05-08
[ 2.810683] microcode: sig=0x206d7, pf=0x4, revision=0x714
[ 2.813340] microcode:
You're mis-understanding how microcode works a little. Microcode is
loaded into physical CPUs in the host. This affects everything that runs
on these CPUs thereafter. A KVM guest is merely a process running on the
host CPUs, so it is affected by the updated microcode. There is no
notion of the
Thanks for the reply. I understand that the CPU features are exposed.
However, is the host-side Intel microcode exposed to the guest?
Here is my qemu command:
qemu-system-x86_64 \
-runas user \
-monitor stdio \
-serial none \
-parallel none \
-nodefaults \
-nodefconfig \
-name
QEMU is already capable of exposing the new CPU features to guests, so
possibly a mis-configuration. Please provide the full QEMU command line
args you are using for this guest too.
--
You received this bug notification because you are a member of qemu-
devel-ml, which is subscribed to QEMU.
34 matches
Mail list logo
