The information is not used anywhere in libvirt.

No functional changes.

Having the functions grouped together this way will avoid further
shuffling around down the line.

No functional changes.

Use briefer checks, eg. (!model) instead of (model == NULL), and
avoid initializing to NULL a pointer that would be assigned in
the first line of the function anyway.

Also remove a pointless NULL assignment.

No functional changes.

Use the ppc64Driver prefix for all functions that are used to
fill in the cpuDriverPPC64 structure, ie. those that are going
to be called by the generic CPU code.

This makes it clear which functions are exported and which are
implementation details; it also gets rid of the ambiguity that
affected the ppc64DataFree() function which, despite what the
name suggested, was not related to ppc64DataCopy() and could
not be used to release the memory allocated for a
virCPUppc64Data* instance.

No functional changes.

Update the names of the symbols used internally by the driver.

No functional changes.

Only the symbols exported by the driver have been updated;
the driver implementation itself still uses the old names
internally.

No functional changes.

The driver only supports VIR_ARCH_PPC64 and VIR_ARCH_PPC64LE.

Just shuffling files around and updating the build system
accordingly. 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>

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>

Sorted feature list is easier to review or compare.
Signed-off-by: NJiri Denemark <jdenemar@redhat.com>

https://bugzilla.redhat.com/show_bug.cgi?id=858147Signed-off-by: NJiri 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: NJiri Denemark <jdenemar@redhat.com>

Wikipedia's list of common misspellings [1] has a machine-readable
version.  This patch fixes those misspellings mentioned in the list
which don't have multiple right variants (as e.g. "accension", which can
be both "accession" and "ascension"), such misspellings are left
untouched.  The list of changes was manually re-checked for false
positives.

[1] https://en.wikipedia.org/wiki/Wikipedia:Lists_of_common_misspellings/For_machinesSigned-off-by: NMartin Kletzander <mkletzan@redhat.com>

Assume no features block migration.

Filter out non-migratable features if
VIR_CONNECT_BASELINE_CPU_MIGRATABLE was specified.

For historical reasons data regarding NUMA configuration were split
between the CPU definition and numatune. We cannot do anything about the
XML still being split, but we certainly can at least store the relevant
data in one place.

This patch moves the NUMA stuff to the right place.

Not all files we want to find using virFileFindResource{,Full} are
generated when libvirt is built, some of them (such as RNG schemas) are
distributed with sources. The current API was not able to find source
files if libvirt was built in VPATH.

Both RNG schemas and cpu_map.xml are distributed in source tarball.
Signed-off-by: NJiri Denemark <jdenemar@redhat.com>

With this patch, Freescale ppc64 CPU modesl could be recognized.

virsh # cpu-models ppc64
POWERPC_e6500
POWERPC_e5500
power8
power8e
power7+
power7
power6
POWER8_v1.0
POWER7+_v2.1
POWER7_v2.3
POWER7_v2.1
POWER7

virsh # capabilities
<capabilities>
  <host>
    <uuid>5a54efa6-20dc-4da7-b271-0b7fb7062cb8</uuid>
    <cpu>
      <arch>ppc64</arch>
      <model>POWERPC_e6500</model>
      <vendor>Freescale</vendor>