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: NBrijesh Singh <brijesh.singh@amd.com>
Signed-off-by: NJiri Denemark <jdenemar@redhat.com>
Reviewed-by: NPavel Hrdina <phrdina@redhat.com>

CPUID leaf 7 is sub-leaf aware. Add missing attribute.
Signed-off-by: NMarek Marczykowski-Górecki <marmarek@invisiblethingslab.com>
Signed-off-by: NJiri Denemark <jdenemar@redhat.com>

As POWER9 model is not available in cpu_map.xml virsh capabilities
donot display the cpu model and vendor details. This patch
provides those details

qemu commit: f74eefe0
https://lwn.net/Articles/667156/Signed-off-by: NLin Ma <lma@suse.com>

These features are included:
AVX512DQ, AVX512IFMA, AVX512BW, AVX512VL, AVX512VBMI, AVX512_4VNNIW and
AVX512_4FMAPS.

qemu commits: cc728d14 and 95ea69fb
Signed-off-by: NLin 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: NJiri Denemark <jdenemar@redhat.com>

They didn't really help anything.
Signed-off-by: NJiri 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: NQiaowei 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: NJiri 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: NJiri Denemark <jdenemar@redhat.com>

Implemented in QEMU by commit 28b8e4d0bf93ba176b4b7be819d537383c5a9060.
Signed-off-by: NJiri Denemark <jdenemar@redhat.com>

This was implemented in QEMU by commit 0bb0b2d2fe7f645dda.
Signed-off-by: NJiri 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: NJiri 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: NJiri Denemark <jdenemar@redhat.com>

This patch makes our CPUID handling code up-to-date with the current
specification found in

Intel® 64 and IA-32 Architectures Developer's Manual: Vol. 2A
http://www.intel.com/content/www/us/en/processors/architectures-software-developer-manuals.htmlSigned-off-by: NJiri 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: NJiri Denemark <jdenemar@redhat.com>

Corresponding QEMU commits:
    clflushopt f7fda280948a5e74aeb076ef346b991ecb173c56
    tsc_adjust 7b458bfd12a71b3da6b531daedc417492c9334e0
Signed-off-by: NAlexander Burluka <aburluka@virtuozzo.com>

https://bugzilla.redhat.com/show_bug.cgi?id=1254420Signed-off-by: NJiri Denemark <jdenemar@redhat.com>

This is yet another variation of POWER8. The PVR information comes
from arch/powerpc/kernel/cputable.c in the Linux kernel tree.

Instead of relying on a hard-coded mask value, read it from the CPU
map XML and use it when looking up models by PVR.

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

The information is not used anywhere in libvirt.

No functional changes.

Corresponding QEMU commits:
    MPX     79e9ebebbf2a00c46fcedb6dc7dd5e12bbd30216
    AVX512  9aecd6f8aef653cea58932f06a2740299dbe5fd3
Signed-off-by: NJiri 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: NJiri 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: NJiri 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: NJiri 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: NJiri 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: NJiri 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: NJiri 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: NJiri 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: NJiri 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: NJiri 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: NJiri 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: NJiri 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: NJiri 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: NJiri 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: NJiri 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: NJiri 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: NJiri 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: NJiri Denemark <jdenemar@redhat.com>