The features were added to QEMU by commit v2.4.0-1690-gf7fda28094 as
Skylake Server features.
Signed-off-by: Jiri Denemark <jdenemar@redhat.com>
Reviewed-by: Pavel Hrdina <phrdina@redhat.com>
Add a new CPU model called 'EPYC' to model processors from AMD EPYC
family (which includes EPYC 76xx,75xx,74xx, 73xx and 72xx).
The following features bits have been added/removed compare to Opteron_G5
Added: monitor, movbe, rdrand, mmxext, ffxsr, rdtscp, cr8legacy, osvw,
fsgsbase, bmi1, avx2, smep, bmi2, rdseed, adx, smap, clfshopt, sha
xsaveopt, xsavec, xgetbv1, arat
Removed: xop, fma4, tbm
The patch is depend on EPYC CPU model supported introduced in qemu [1]
[1] https://patchwork.kernel.org/patch/9902205/
Cc: Tom Lendacky <Thomas.Lendacky@amd.com>
Signed-off-by: Brijesh Singh <brijesh.singh@amd.com>
Signed-off-by: Jiri Denemark <jdenemar@redhat.com>
Reviewed-by: Pavel Hrdina <phrdina@redhat.com>
These features are included:
AVX512DQ, AVX512IFMA, AVX512BW, AVX512VL, AVX512VBMI, AVX512_4VNNIW and
AVX512_4FMAPS.
qemu commits: cc728d14 and 95ea69fb
Signed-off-by: Lin Ma <lma@suse.com>
We can't change feature names for compatibility reasons even if they
contain typos or other software uses different names for the same
features. By adding alternative spellings in our CPU map we at least
allow anyone to grep for them and find the correct libvirt's name.
Signed-off-by: Jiri Denemark <jdenemar@redhat.com>
Some Intel processor families (e.g. the Intel Xeon processor E5 v3
family) introduced some PQos (Platform Qos) features, including CMT
(Cache Monitoring technology) and MBM (Memory Bandwidth Monitoring),
to monitor or control shared resource. This patch add them into x86
part of cpu_map.xml to be used for applications based on libvirt to
get cpu capabilities. For example, Nova in OpenStack schedules guests
based on the CPU features that the host has.
Signed-off-by: Qiaowei Ren <qiaowei.ren@intel.com>
Our current detection code uses just the number of CPU features which
need to be added/removed from the CPU model to fully describe the CPUID
data. The smallest number wins. But this may sometimes generate wrong
results as one can see from the fixed test cases. This patch modifies
the algorithm to prefer the CPU model with matching signature even if
this model results in a longer list of additional features.
Signed-off-by: Jiri Denemark <jdenemar@redhat.com>
The CPU model was implemented in QEMU by commit f6f949e929.
The change to i7-5600U is wrong since it's a 5th generation CPU, i.e.,
Broadwell rather than Skylake, but that's just the result of our CPU
detection code (which is fixed by the following commit).
Signed-off-by: Jiri Denemark <jdenemar@redhat.com>
As a side effect this changes the order of CPU features in XMLs
generated by libvirt, but that's not a big deal since the order there is
insignificant.
Signed-off-by: Jiri Denemark <jdenemar@redhat.com>
For two reasons:
- 0x00000001 is very similar to 0x80000001, but 0x01 is visually
different
- 0x01 format is consistent with CPUID manual
Signed-off-by: Jiri Denemark <jdenemar@redhat.com>
CPUID instruction normally takes its parameter from EAX, but sometimes
ECX is used as an additional parameter. Let's rename 'function' to
'eax_in' in preparation for adding 'ecx_in'.
Signed-off-by: Jiri Denemark <jdenemar@redhat.com>
Use multiple PVRs per CPU model to reduce the number of models we
need to keep track of.
Remove specific CPU models (eg. POWER7+_v2.1): the corresponding
generic CPU model (eg. POWER7) should be used instead to ensure
the guest can be booted on any compatible host.
Get rid of all the entries that did not match any of the CPU
models supported by QEMU, like power8 and power8e.
Resolves: https://bugzilla.redhat.com/show_bug.cgi?id=1250977
Inheritance among CPU model is cool but it makes reviewing CPU model
definitions and comparing them to CPU models from QEMU rather hard and
unpleasant. Let's define all CPU models from scratch.
Signed-off-by: Jiri Denemark <jdenemar@redhat.com>
Inheritance among CPU model is cool but it makes reviewing CPU model
definitions and comparing them to CPU models from QEMU rather hard and
unpleasant. Let's define all CPU models from scratch.
Signed-off-by: Jiri Denemark <jdenemar@redhat.com>
Inheritance among CPU model is cool but it makes reviewing CPU model
definitions and comparing them to CPU models from QEMU rather hard and
unpleasant. Let's define all CPU models from scratch.
Signed-off-by: Jiri Denemark <jdenemar@redhat.com>
Inheritance among CPU model is cool but it makes reviewing CPU model
definitions and comparing them to CPU models from QEMU rather hard and
unpleasant. Let's define all CPU models from scratch.
Signed-off-by: Jiri Denemark <jdenemar@redhat.com>
Inheritance among CPU model is cool but it makes reviewing CPU model
definitions and comparing them to CPU models from QEMU rather hard and
unpleasant. Let's define all CPU models from scratch.
Signed-off-by: Jiri Denemark <jdenemar@redhat.com>
Inheritance among CPU model is cool but it makes reviewing CPU model
definitions and comparing them to CPU models from QEMU rather hard and
unpleasant. Let's define all CPU models from scratch.
Signed-off-by: Jiri Denemark <jdenemar@redhat.com>
Inheritance among CPU model is cool but it makes reviewing CPU model
definitions and comparing them to CPU models from QEMU rather hard and
unpleasant. Let's define all CPU models from scratch.
Signed-off-by: Jiri Denemark <jdenemar@redhat.com>
Inheritance among CPU model is cool but it makes reviewing CPU model
definitions and comparing them to CPU models from QEMU rather hard and
unpleasant. Let's define all CPU models from scratch.
Signed-off-by: Jiri Denemark <jdenemar@redhat.com>
Inheritance among CPU model is cool but it makes reviewing CPU model
definitions and comparing them to CPU models from QEMU rather hard and
unpleasant. Let's define all CPU models from scratch.
Signed-off-by: Jiri Denemark <jdenemar@redhat.com>
Inheritance among CPU model is cool but it makes reviewing CPU model
definitions and comparing them to CPU models from QEMU rather hard and
unpleasant. Let's define all CPU models from scratch.
Signed-off-by: Jiri Denemark <jdenemar@redhat.com>
Inheritance among CPU model is cool but it makes reviewing CPU model
definitions and comparing them to CPU models from QEMU rather hard and
unpleasant. Let's define all CPU models from scratch.
Signed-off-by: Jiri Denemark <jdenemar@redhat.com>
Inheritance among CPU model is cool but it makes reviewing CPU model
definitions and comparing them to CPU models from QEMU rather hard and
unpleasant. Let's define all CPU models from scratch.
Signed-off-by: Jiri Denemark <jdenemar@redhat.com>
Inheritance among CPU model is cool but it makes reviewing CPU model
definitions and comparing them to CPU models from QEMU rather hard and
unpleasant. Let's define all CPU models from scratch.
Signed-off-by: Jiri Denemark <jdenemar@redhat.com>
Inheritance among CPU model is cool but it makes reviewing CPU model
definitions and comparing them to CPU models from QEMU rather hard and
unpleasant. Let's define all CPU models from scratch.
Signed-off-by: Jiri Denemark <jdenemar@redhat.com>
Inheritance among CPU model is cool but it makes reviewing CPU model
definitions and comparing them to CPU models from QEMU rather hard and
unpleasant. Let's define all CPU models from scratch.
Signed-off-by: Jiri Denemark <jdenemar@redhat.com>
Inheritance among CPU model is cool but it makes reviewing CPU model
definitions and comparing them to CPU models from QEMU rather hard and
unpleasant. Let's define all CPU models from scratch.
Signed-off-by: Jiri Denemark <jdenemar@redhat.com>
Inheritance among CPU model is cool but it makes reviewing CPU model
definitions and comparing them to CPU models from QEMU rather hard and
unpleasant. Let's define all CPU models from scratch.
Signed-off-by: Jiri Denemark <jdenemar@redhat.com>
Inheritance among CPU model is cool but it makes reviewing CPU model
definitions and comparing them to CPU models from QEMU rather hard and
unpleasant. Let's define all CPU models from scratch.
Signed-off-by: Jiri Denemark <jdenemar@redhat.com>
Inheritance among CPU model is cool but it makes reviewing CPU model
definitions and comparing them to CPU models from QEMU rather hard and
unpleasant. Let's define all CPU models from scratch.
Signed-off-by: Jiri Denemark <jdenemar@redhat.com>
Inheritance among CPU model is cool but it makes reviewing CPU model
definitions and comparing them to CPU models from QEMU rather hard and
unpleasant. Let's define all CPU models from scratch.
Signed-off-by: Jiri Denemark <jdenemar@redhat.com>
QEMU 2.3 adds these new models to cover Haswell and Broadwell CPUs with
updated microcode. Luckily, they also reverted former the machine type
specific changes to existing models. And since these changes were never
released, we don't need to hack around them in libvirt.
Signed-off-by: Jiri Denemark <jdenemar@redhat.com>
IBM Power processors differ uniquely across generations (such as power6,
power7, power8). Each generation signifies a new PowerISA version
that exhibits features unique to that generation.
The higher 16 bits of PVR for IBM Power processors encode the CPU
generation, while the CPU chip (sub)version is encoded in lower 16 bits.
For all practical purposes of launching a VM, we care about the
generation which the vCPU will belong to, and not specifically the chip
version. This patch updates the libvirt PVR check to reflect this
relationship. It allows libvirt to select the right CPU generation
in case the exact match for a a specific CPU is not found.
Hence, there will no longer be a need to add each PowerPC CPU model to
cpu_map.xml; just adding entry for the matching ISA generation will
suffice.
It also contains changes to cpu_map.xml since processor generations
as understood by QEMU compat mode go as "power6", "power7" or "power8"
[Reference : QEMU commit 8dfa3a5e85 ]
Signed-off-by: Prerna Saxena <prerna@linux.vnet.ibm.com>
Signed-off-by: Pradipta Kr. Banerjee <bpradip@in.ibm.com>
Signed-off-by: Anton Blanchard <anton@samba.org>
Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
Commit fba6bc4 introduced support for the 'invtsc' feature,
which blocks migration. We should not include it in the
host-model CPU by default, because it's intended to be used
with migration.
https://bugzilla.redhat.com/show_bug.cgi?id=1138221
