Both cpuCompare* APIs are renamed to virCPUCompare*. And they should now
work for any guest CPU definition, i.e., even for host-passthrough
(trivial) and host-model CPUs. The implementation in x86 driver is
enhanced to provide a hint about -noTSX Broadwell and Haswell models
when appropriate.
Signed-off-by: NJiri Denemark <jdenemar@redhat.com>

Signed-off-by: NJiri Denemark <jdenemar@redhat.com>

The function is similar to virCPUDataCheckFeature, but it works directly
on CPU definition rather than requiring it to be transformed into CPU
data first.
Signed-off-by: NJiri Denemark <jdenemar@redhat.com>

To match our coding style and to provide better debug and error
messages.
Signed-off-by: NJiri Denemark <jdenemar@redhat.com>

Signed-off-by: NJiri Denemark <jdenemar@redhat.com>

The API is supposed to make sure the provided CPU definition does not
use a CPU model which is not supported by the hypervisor (if at all
possible, of course).
Signed-off-by: NJiri Denemark <jdenemar@redhat.com>

Keeping nfeatures_max set to 0 while nfeatures > 0 and some features are
already stored in features array is just asking for problems once we
want to add a new feature into the array.
Signed-off-by: NJiri Denemark <jdenemar@redhat.com>

The reworked API is now called virCPUUpdate and it should change the
provided CPU definition into a one which can be consumed by the QEMU
command line builder:

    - host-passthrough remains unchanged
    - host-model is turned into custom CPU with a model and features
      copied from host
    - custom CPU with minimum match is converted similarly to host-model
    - optional features are updated according to host's CPU
Signed-off-by: NJiri Denemark <jdenemar@redhat.com>

The function checks CPUID data for a given feature.
Signed-off-by: NJiri Denemark <jdenemar@redhat.com>

Signed-off-by: NJiri Denemark <jdenemar@redhat.com>

x86ModelFromCPU is used to provide CPUID data for features matching
@policy. This patch allows callers to set @policy to -1 to get combined
CPUID for all CPU features (including those implicitly provided a CPU
model) specified in CPU def.
Signed-off-by: NJiri Denemark <jdenemar@redhat.com>

Signed-off-by: NJiri Denemark <jdenemar@redhat.com>

The ARM CPU driver wrongly reported host CPU model as "host", which made
host-model to be just an alias for host-passthrough. Let's drop this
insanity.
Signed-off-by: NJiri Denemark <jdenemar@redhat.com>

cpuGetSubDriver already reports a useful error.
Signed-off-by: NJiri Denemark <jdenemar@redhat.com>

Some CPU drivers (such as arm) do not provide list of CPUs libvirt
supports and just pass any CPU model from domain XML directly to QEMU.
Such driver need to return models == NULL and success from cpuGetModels.
Signed-off-by: NJiri Denemark <jdenemar@redhat.com>

Our internal APIs mostly use virArch rather than strings. Switching
cpuGetModels to virArch will save us from unnecessary conversions in the
future.
Signed-off-by: NJiri Denemark <jdenemar@redhat.com>

When starting a guest and copying host vendor cpuid to the guest
cpu, libvirtd would crash if the host cpu contained a NULL vendor
field. Avoid the crash by checking for a valid vendor in the host
cpu before copying the cpuid to the guest cpu.

For completeness, here is a backtrace from the crash

(gdb) bt
f0  0x00007ffff739bf33 in x86DataCpuid (cpuid=0x8, cpuid=0x8,
    data=data@entry=0x7fffb800ee78) at cpu/cpu_x86.c:287
f1  virCPUx86DataAddCPUID (data=data@entry=0x7fffb800ee78, cpuid=0x8)
    at cpu/cpu_x86.c:355
f2  0x00007ffff739ef47 in x86Compute (host=<optimized out>, cpu=0x7fffb8000cc0,
    guest=0x7fffecca7348, message=<optimized out>) at cpu/cpu_x86.c:1580
f3  0x00007fffd2b38e53 in qemuBuildCpuModelArgStr (migrating=false,
    hasHwVirt=<synthetic pointer>, qemuCaps=0x7fffb8001040, buf=0x7fffecca7360,
    def=0x7fffc400ce20, driver=0x1c) at qemu/qemu_command.c:6283
f4  qemuBuildCpuCommandLine (cmd=cmd@entry=0x7fffb8002f60,
    driver=driver@entry=0x7fffc80882c0, def=def@entry=0x7fffc400ce20,
    qemuCaps=qemuCaps@entry=0x7fffb8001040, migrating=<optimized out>)
    at qemu/qemu_command.c:6445
(gdb) f2
(gdb) p *host_model
$23 = {name = 0x7fffb800ec50 "qemu64", vendor = 0x0, signature = 0, data = {
    len = 2, data = 0x7fffb800e720}}

Since the introduction of CMT features (commit v1.3.5-461-gf294b83e)
starting a domain with host-model CPU on a host which supports CMT fails
because QEMU complains about unknown 'cmt' feature:

    qemu-system-x86_64: CPU feature cmt not found

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

By removing a non-migratable feature in a for loop we would fail to drop
every second non-migratable feature if the features array contained
several of them in a row.
Signed-off-by: NJiri Denemark <jdenemar@redhat.com>

Signed-off-by: NJiri Denemark <jdenemar@redhat.com>

Signed-off-by: NJiri Denemark <jdenemar@redhat.com>

Pretending (partial) support for something we don't understand is risky.
Reporting a failure is much better.
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>

Both ARM and AArch64 drivers are exactly the same (modulo function
names). Let's use just one driver for all ARM architectures.
Signed-off-by: NJiri Denemark <jdenemar@redhat.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. This patch prepares the x86 CPU
driver code for the new 'ecx_in' CPUID parameter.
Signed-off-by: NJiri Denemark <jdenemar@redhat.com>

The internal features are only used in explicit checks with
cpuHasFeature. Loading them into the CPU map is dangerous since the
features may accidentally be reported to users when decoding CPUID data.
Signed-off-by: NJiri Denemark <jdenemar@redhat.com>

virCPUData and struct ppc64_model structures contained a pointer to
virCPUppc64Data, which was not very nice since the real data were
accessible by yet another level of pointers from virCPUppc64Data.
Signed-off-by: NJiri Denemark <jdenemar@redhat.com>

virCPUData, virCPUx86Feature, and virCPUx86Model all contained a pointer
to virCPUx86Data, which was not very nice since the real CPUID data were
accessible by yet another pointer from virCPUx86Data. Moreover, using
virCPUx86Data directly will make static definitions of internal CPU
features a bit easier.
Signed-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>

A CPU data XML file already contains the architecture, let the parser
use it to detect which CPU driver should be used to parse the rest of
the file.
Signed-off-by: NJiri Denemark <jdenemar@redhat.com>

The formatter uses /cpudata/cpuid elements and the parser should really
do the same.
Signed-off-by: NJiri Denemark <jdenemar@redhat.com>

When computing CPU data for a given guest CPU we should set CPUID vendor
bits appropriately so that we don't lose the vendor when transforming
CPU data back to XML description.
Signed-off-by: NJiri Denemark <jdenemar@redhat.com>

cpu/cpu_ppc64.c: In function 'ppc64Compute':
cpu/cpu_ppc64.c:620:27: error: potential null pointer dereference [-Werror=null-dereference]
     if (STRNEQ(guest_model->name, host_model->name)) {
                ~~~~~~~~~~~^~~
cpu/cpu_ppc64.c:620:9: note: in expansion of macro 'STRNEQ'
     if (STRNEQ(guest_model->name, host_model->name)) {
         ^~~~~~
cc1: all warnings being treated as errors
Signed-off-by: NMichal Privoznik <mprivozn@redhat.com>