The new name is virCPUGetModels.
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>

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>

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>

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>

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 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 ppc64GetModels to always return a
NULL-terminated list of models.
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>

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

While the check is appropriate for eg. the x86 and generic drivers,
there are some valid ppc64 guest configurations where the CPU
model is supposed to be NULL.

Moving this check from the generic code to the drivers makes it
possible to accomodate both use cases.

Resolves: https://bugzilla.redhat.com/show_bug.cgi?id=1251927

Not all combinations of host CPU models and compatibility modes
are valid, so we need to make sure we don't try to do something
that QEMU will reject.

Moreover, we need to apply a different logic to guests using
host-model and host-passthrough modes when testing them for host
compatibility.

Resolves: https://bugzilla.redhat.com/show_bug.cgi?id=1251927

If a guest CPU is defined using

  <cpu mode='host-model'/>

the <model> sub-element will contain the compatibility mode to use.
That means we can't just copy the host CPU model on cpuUpdate(),
otherwise we'll overwrite that information and migration of such
guests will fail.

Resolves: https://bugzilla.redhat.com/show_bug.cgi?id=1251927

Commit adb865df introduced some changes in ppc64DriverNodeData()
that cause libvirtd to crash on startup unless this patch is
applied as well.

Unlike what happens on x86, on ppc64 you can't mix and match CPU
features to obtain the guest CPU you want regardless of the host
CPU, so the concept of model fallback doesn't apply.

Make sure CPU definitions emitted by the driver, eg. as output of
the cpuBaseline() and cpuUpdate() calls, reflect this fact.

All previously recognized CPU models (POWER7_v2.1, POWER7_v2.3,
POWER7+_v2.1 and POWER8_v1.0) are internally converted to the
corrisponding generation name so that existing guests don't stop
working.

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.

This will allow us to perform PVR matching more broadly, eg. consider
both POWER8 and POWER8E CPUs to be the same even though they have
different PVR values.

Use a typedef instead of the plain struct and heap allocation. This
will make it easier to extend the ppc64 specific CPU data later on.

This ensures comparison of two CPU definitions will be consistent
regardless of the fact that it is performed using cpuCompare() or
cpuGuestData(). The x86 driver uses the same exact code.

Limitations of the POWER architecture mean that you can't run
eg. a POWER7 guest on a POWER8 host when using KVM. This applies
to all guests, not just those using VIR_CPU_MATCH_STRICT in the
CPU definition; in fact, exact and strict CPU matching are
basically the same on ppc64.

This means, of course, that hosts using different CPUs have to be
considered incompatible as well.

Change ppc64Compute(), called by cpuGuestData(), to reflect this
fact and update test cases accordingly.

Resolves: https://bugzilla.redhat.com/show_bug.cgi?id=1250977

ppc64Compute(), called by cpuNodeData(), is used not only to retrieve
the driver-specific data associated to a guest CPU definition, but
also to check whether said guest CPU is compatible with the host CPU.

If the user is not interested in the CPU data, it's perfectly fine
to pass a NULL pointer instead of a return location, and the
compatibility data returned should not be affected by this. One of
the checks, specifically the one on CPU model name, was however
only performed if the return location was non-NULL.

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.

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.

Commit 86a15a25 introduced a new cpu driver API 'getModels'. Public API
allow you to pass NULL for models to get only number of existing models.
However the new code will crash with segfault so we have to count with
the possibility that the user wants only the number.

There is also difference in order of the models gathered by this new API
as the old approach was inserting the elements to the end of the array
so we should use 'VIR_APPEND_ELEMENT'.
Signed-off-by: NPavel Hrdina <phrdina@redhat.com>

For Intel and PowerPC the implementation is calling a cpu driver
function across driver layers (i.e. from qemu driver directly to cpu
driver).
The correct behavior is to use libvirt API functionality to perform such
a inter-driver call.

This patch introduces a new cpu driver API function getModels() to
retrieve the cpu models. The currect implementation to process the
cpu_map XML content is transferred to the INTEL and PowerPC cpu driver
specific API functions.
Additionally processing the cpu_map XML file is not safe due to the fact
that the cpu map does not exist for all architectures. Therefore it is
better to encapsulate the processing in the architecture specific cpu
drivers.
Signed-off-by: NDaniel Hansel <daniel.hansel@linux.vnet.ibm.com>
Reviewed-by: NBoris Fiuczynski <fiuczy@linux.vnet.ibm.com>
Reviewed-by: NViktor Mihajlovski <mihajlov@linux.vnet.ibm.com>

IBM Power processors differ uniquely across generations (such as power6,
power7, power8). Each generation signifies a new PowerISA version
that exhibits features unique to that generation.
The higher 16 bits of PVR for IBM Power processors encode the CPU
generation, while the CPU chip (sub)version is encoded in lower 16 bits.

For all practical purposes of launching a VM, we care about the
generation which the vCPU will belong to, and not specifically the chip
version. This patch updates the libvirt PVR check to reflect this
relationship. It allows libvirt to select the right CPU generation
in case the exact match for a a specific CPU is not found.
Hence, there will no longer be a need to add each PowerPC CPU model to
cpu_map.xml; just adding entry for the matching ISA generation will
suffice.

It also contains changes to cpu_map.xml since processor generations
as understood by QEMU compat mode go as "power6", "power7" or "power8"
[Reference : QEMU commit 8dfa3a5e85 ]
Signed-off-by: NPrerna Saxena <prerna@linux.vnet.ibm.com>
Signed-off-by: NPradipta Kr. Banerjee <bpradip@in.ibm.com>
Signed-off-by: NAnton Blanchard <anton@samba.org>
Reviewed-by: NMichal Privoznik <mprivozn@redhat.com>

PowerISA allows processors to run VMs in binary compatibility ("compat")
mode supporting an older version of ISA. QEMU has recently added support to
explicitly denote a VM running in compatibility mode through commit 6d9412ea
& 8dfa3a5e85. Now, a "compat" mode VM can be run by invoking this qemu
commandline on a POWER8 host:  -cpu host,compat=power7.

This patch allows libvirt to exploit cpu mode 'host-model' to describe this
new mode for PowerKVM guests. For example, when a user wants to request a
power7 vm to run in compatibility mode on a Power8 host, this can be
described in XML as follows :

  <cpu mode='host-model'>
    <model>power7</model>
  </cpu>
Signed-off-by: NPrerna Saxena <prerna@linux.vnet.ibm.com>
Signed-off-by: NLi Zhang <zhlcindy@linux.vnet.ibm.com>
Signed-off-by: NPradipta Kr. Banerjee <bpradip@in.ibm.com>
Acked-by: NMichal Privoznik <mprivozn@redhat.com>

This adds support for PowerPC Little Endian architecture.,
and allows libvirt to spawn VMs based on 'ppc64le' architecture.
Signed-off-by: NPradipta Kr. Banerjee <bpradip@in.ibm.com>
Signed-off-by: NPrerna Saxena <prerna@linux.vnet.ibm.com>
Reviewed-by: NMichal Privoznik <mprivozn@redhat.com>

When CPU comparison APIs return VIR_CPU_COMPARE_INCOMPATIBLE, the caller
has no clue why the CPU is considered incompatible with host CPU. And in
some cases, it would be nice to be able to get such info in a client
rather than having to look in logs.

To achieve this, the APIs can be told to return VIR_ERR_CPU_INCOMPATIBLE
error for incompatible CPUs and the reason will be described in the
associated error message.
Signed-off-by: NJiri Denemark <jdenemar@redhat.com>

In "src/cpu/" there are some enumerations (enum) declarations.
Similar to the recent cleanup to "src/util", "src/conf" and other
directories, it's better to use a typedef for variable types,
function types and other usages. Other enumeration and folders will
be changed to typedef's in the future. Specially, in files that are
in different places of "src/util" and "src/conf". Most of the files
changed in this commit are related to CPU (cpu_map.h) enums.
Signed-off-by: NJulio Faracco <jcfaracco@gmail.com>

In "src/conf/" there are many enumeration (enum) declarations.
Similar to the recent cleanup to "src/util" directory, it's
better to use a typedef for variable types, function types and
other usages. Other enumeration and folders will be changed to
typedef's in the future. Most of the files changed in this commit
are related to CPU (cpu_conf) enums.
Signed-off-by: NJulio Faracco <jcfaracco@gmail.com>
Signed-off-by: NEric Blake <eblake@redhat.com>