The new name is virCPUDataParse.
Signed-off-by: NJiri Denemark <jdenemar@redhat.com>

The new name is virCPUModelIsAllowed.
Signed-off-by: NJiri Denemark <jdenemar@redhat.com>

The new name is virCPUGetModels.
Signed-off-by: NJiri Denemark <jdenemar@redhat.com>

It really doesn't belong to the generic CPU driver.
Signed-off-by: NJiri Denemark <jdenemar@redhat.com>

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>

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>

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>

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>

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>

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, 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>

The architecture specific loaders are now called with a list of all
elements of a given type (rather than a single element at a time). This
avoids the need to reallocate the arrays in CPU maps for each element.
Signed-off-by: NJiri Denemark <jdenemar@redhat.com>

There's no reason for keeping the features in a linked list. Especially
when we know upfront the total number of features we are loading.
Signed-off-by: NJiri Denemark <jdenemar@redhat.com>

There's no reason for keeping the vendors in a linked list. Especially
when we know upfront the total number of models we are loading.
Signed-off-by: NJiri Denemark <jdenemar@redhat.com>

There's no reason for keeping the models in a linked list. Especially
when we know upfront the total number of models we are loading.

As a nice side effect, this fixes x86GetModels to always return a
NULL-terminated list of models.
Signed-off-by: NJiri Denemark <jdenemar@redhat.com>

When searching for the best CPU model for CPUID data we can easily
ignore models with non-matching vendor before spending time on CPUID
data to virCPUDef conversion.
Signed-off-by: NJiri Denemark <jdenemar@redhat.com>

CPU map XML is our internal data file, it makes no sense to tolerate any
errors in it.
Signed-off-by: NJiri Denemark <jdenemar@redhat.com>

CPU map XML is our internal data file, it makes no sense to tolerate any
errors in it.
Signed-off-by: NJiri Denemark <jdenemar@redhat.com>

CPU map XML is our internal data file, it makes no sense to tolerate any
errors in it.
Signed-off-by: NJiri Denemark <jdenemar@redhat.com>

The next pointer is initialized to NULL, overwriting to with another
NULL doesn't hurt.
Signed-off-by: NJiri Denemark <jdenemar@redhat.com>

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

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

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

Splitting the comparison into a separate function makes the code cleaner
and easier to update in the future.
Signed-off-by: NJiri Denemark <jdenemar@redhat.com>