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.
Sanjay,
You can just increase the number of vcpus, such as:
64
then continue to define the vcpus:
(6x enabled=yes, then 2x
@sanjaybmd
I'm glad to read that it worked for you. In fact, since I posted the XML
I didn't have the time to do benchmarking, now my motherboard is dead
and I have to wait for repair/replacement.
Do you have any data to quantify the performance gain?
As to the number of cores, you will notice
@Jan: this coreinfo output looks good.
I finally managed to get the core /cache alignment right, I believe:
32
Thanks for clarifying, Jan.
In the meantime I tried a number of so-called solutions published on
Reddit and other places, none of which seems to work.
So if I understand it correctly, there is currently no solution to the
incorrect l3 cache layout for Zen architecture CPUs. At best a
workaround
Thanks for clarifying, Jan.
In the meantime I tried a number of so-called solutions published on
Reddit and other places, none of which seems to work.
So if I understand it correctly, there is currently no solution to the
incorrect l3 cache layout for Zen architecture CPUs. At best a
workaround
This is the CPU cache layout as shown by lscpu -a -e
CPU NODE SOCKET CORE L1d:L1i:L2:L3 ONLINEMAXMHZMINMHZ
00 00 0:0:0:0 yes 3800. 2200.
10 01 1:1:1:0 yes 3800. 2200.
20 02 2:2:2:0 yes 3800.
Jan, I tried your suggestion but it didn't make a difference. Here is my
current setup:
h/w: AMD Ryzen 9 3900X
kernel: 5.4
QEMU: 5.0.0-6
Chipset selection: Q35-5.0
Configuration: host-passthrough, cache enabled
Use CoreInfo.exe inside Windows. The problem is this:
Logical Processor to Cache
Thanks Jan. I had some new hardware/software issues combined with the
QEMU 5.0.. issues that had my Windows VM crash after some minutes.
I totally overlooked the following:
So I guess you posted to answer to this:
With regard to Jan's comment earlier and the virsh capabilities listing
the cores and siblings, also note the following lines from virsh
capabilities for a 3900X CPU:
virsh capabilities is perfectly able to identify the L3 cache structure
and associate the
"The CPUs with cpuset="0,12" are disabled once booted. The host-cache-
info=on is the part that makes sure that the cache config is passed to
the VM (but unfortunately does not take disabled cores into account,
which results in incorrect config). The qemu:commandline is added
because I need to add
I upgraded to QEMU emulator version 5.0.50
Using q35-5.1 (the latest) and the following libvirt configuration:
50331648
50331648
24
hvm
Hello Babu,
Thanks for the reply and the QEMU command line. I will try to implement
it in the XML.
So essentially what you do is to define each group of cpus and associate
them with a numa node:
-numa node,nodeid=0,cpus=0-5 -numa node,nodeid=1,cpus=6-11 -numa
node,nodeid=2,cpus=12-17 -numa
Here the vm.log with the qemu command line (shortened):
2020-05-03 18:23:38.674+: starting up libvirt version: 5.10.0, qemu
version: 5.0.50v5.0.0-154-g2ef486e76d-dirty, kernel: 5.4.36-1-MANJARO
-machine
Finally installed QEMU 5.0.0.154 - still the same. QEMU doesn't
recognize the L3 caches and still lists 3 L3 caches instead of 4 with 3
cores/6 threads.
--
You received this bug notification because you are a member of qemu-
devel-ml, which is subscribed to QEMU.
It could be an issue of how the kernel presents the CPU topology.
Hardware: AMD Ryzen 3900X 12 core 24 threads (SMT)
Host: Kernel 5.6.6, QEMU 4.2
virsh capabilities | grep "cpu id"
Same problem for Ryzen 9 3900X. There should be 4x L3 caches, but there
are only 3.
Same results with "host-passthrough" and "EPYC-IBPB". Windows doesn't
recognize the correct L3 cache layout.
>From coreinfo.exe:
Logical Processor to Cache Map:
**-- Data Cache 0,
Also affects me when running Qemu 4.0.0 with -machine pc-q35-3.1. I get
this on the command line:
"qemu-system-x86_64: vhost_region_add_section: Overlapping but not
coherent sections at 11a000".
h/w: AMD Ryzen 3900X, Gigabyte Aorus Pro X570 (latest BIOS), kernel
5.3.0.
With -machine q35 (i.e.
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
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
> 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
>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
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
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:
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
Public bug reported:
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
I ran into similar issues with Windows 10 (1803), with regard to 2D
graphics performance.
See my bug report here:
https://bugzilla.kernel.org/show_bug.cgi?id=200877
Could you test with Spectre protection (temporarily) turned off inside
the Windows VM?
See my post here:
31 matches
Mail list logo
