It was used for error reporting only.

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

* src/cpu/cpu_x86.c (x86Decode): Do not dereference NULL
when "models" is NULL and nmodels is 1 or greater.

When comparing incompatible CPUs, the reason for this incompatibility is
logged as a debug message.
Signed-off-by: NJiri Denemark <jdenemar@redhat.com>

When comparing x86 CPUs, features with 'disabled' policy were mistakenly
required to be supported by the host CPU.

Likewise, features with 'force' policy which were supported by host CPU
would make CPUs incompatible if 'strict' match was used by guest CPU.

This patch fixes both issues.
Signed-off-by: NJiri Denemark <jdenemar@redhat.com>

* src/cpu/cpu_x86_data.h: Include <stdint.h>.

Current implementation of x86Decode() used for CPUID -> model+features
translation does not always select the closest CPU model. When walking
through all models from cpu_map.xml the function considers a new
candidate as a better choice than a previously selected candidate only
if the new one is a superset of the old one. In case the new candidate
is closer to host CPU but lacks some feature comparing to the old
candidate, the function does not choose well.

This patch changes the algorithm so that the closest model is always
selected. That is, the model which requires the lowest number of
additional features to describe host CPU.
Signed-off-by: NJiri Denemark <jdenemar@redhat.com>

* src/Makefile.am src/cpu/cpu_map.c: rename in Makefile and in the
  cpu map loading code

Also backup and restore the original ctxt->node value in x86FeatureLoad.

* src/cpu/cpu_map.xml: newdescription file
* src/Makefile.am: include it in dist

Each driver supporting CPU selection must fill in host CPU capabilities.
When filling them, drivers for hypervisors running on the same node as
libvirtd can use cpuNodeData() to obtain raw CPU data. Other drivers,
such as VMware, need to implement their own way of getting such data.
Raw data can be decoded into virCPUDefPtr using cpuDecode() function.

When implementing virConnectCompareCPU(), a hypervisor driver can just
call cpuCompareXML() function with host CPU capabilities.

For each guest for which a driver supports selecting CPU models, it must
set the appropriate feature in guest's capabilities:

    virCapabilitiesAddGuestFeature(guest, "cpuselection", 1, 0)

Actions needed when a domain is being created depend on whether the
hypervisor understands raw CPU data (currently CPUID for i686, x86_64
architectures) or symbolic names has to be used.

Typical use by hypervisors which prefer CPUID (such as VMware and Xen):

- convert guest CPU configuration from domain's XML into a set of raw
  data structures each representing one of the feature policies:

    cpuEncode(conn, architecture, guest_cpu_config,
              &forced_data, &required_data, &optional_data,
              &disabled_data, &forbidden_data)

- create a mask or whatever the hypervisor expects to see and pass it
  to the hypervisor

Typical use by hypervisors with symbolic model names (such as QEMU):

- get raw CPU data for a computed guest CPU:

    cpuGuestData(conn, host_cpu, guest_cpu_config, &data)

- decode raw data into virCPUDefPtr with a possible restriction on
  allowed model names:

    cpuDecode(conn, guest, data, n_allowed_models, allowed_models)

- pass guest->model and guest->features to the hypervisor

* src/cpu/cpu.c src/cpu/cpu.h src/cpu/cpu_generic.c
  src/cpu/cpu_generic.h src/cpu/cpu_map.c src/cpu/cpu_map.h
  src/cpu/cpu_x86.c src/cpu/cpu_x86.h src/cpu/cpu_x86_data.h
* configure.in: check for CPUID instruction
* src/Makefile.am: glue the new files in
* src/libvirt_private.syms: add new private symbols
* po/POTFILES.in: add new cpu files containing translatable strings